If not at the moment, is it being worked on to enable this feature in the future?
It’s appears technically impossible:
To transfer grin from inputs with total blinding factor i to a recipient output with blinding factor r, one needs to be able to sign the excess r - i, which requires knowledge of r. But anyone knowing r can spend the recipient output at will…
Addendum: technically, signing the excess requires only knowing r-i. So if one doesn’t know i, one can still sign the excess for transferring to an output i+k. But then one wouldn’t be able to construct a rangeproof for that output. So it’s the rangeproof that requires knowledge of the output’s blinding factor…
Thanks for clarifying. So how will grin be able to keep up with competitors if the receiving party has to be online. To me this sounds like an essential disadvantage…
1 Like
I am also interested in how to mitigate this issue.
what is the latest thinking?
From what i understand it seems to be the only significant disadvantage to mimble wimble.
Mmmh while this isn’t implemented at the moment, it’s definitely technically possible. I had started down this path but got sidetracked in a big way by testnet2. Every message sent over http by the wallet right now could be sent in a variery of other ways, including email or carrier pigeon.
@tromp did you mean interactive instead of online? Most people are worried about the online part, we can solve interactivity in a variety of ways.
Indeed, interaction of the receiver is required to construct a rangeproof of an output that only she can spend. This doesn’t mean sender and receiver have to be online at the same time, but does require some back and forth communication, whether it be directly wallet-to-wallet, or with chats, emails, snail-mail, carrier pigeon, or what have you.
I’m confused why this is seen as such a big issue; in what situation does a payment need to be confirmed trustlessly that doesn’t have high volume like a merchant to justify always on server or atomicly like a drug deal in which case you have time to debug communication channels?
If the situation is that you trust someone to eventually send you money when they get around to it, you already trusting them. It may be perfectly acceptable to just have a side network that declares someone wants to pay you money and says: “next time your online check with them mmmmmk?” without even starting the protocall until both people are online
Could the receiver generate their half of the transaction first, if the amount is known, and send that to the payer? This could be seen as a kind of payment request.
No, they can’t. The receiver’s signature depends on a nonce to be chosen by the sender.
If the sender generates their half of the transaction, and sends it to an attacker by mistake, can the attacker steal the funds? Alternatively, if the attacker listens to the sender and receiver, can they step in quickly to steal the funds if the receiver acts too slowly?
no, an attacker intercepting all wallet-to-wallet communication cannot steal anything.
I’m trying to understand the transaction creation process. Does it run like this?
- Alice creates partial transaction and sends it to Bob
- Bob completes and broadcasts this transaction
What exactly prevents an eavesdropping attacker from acting quicker than Bob and taking the funds?
Poelstra seems to indicate this theft might be possible here: https://bitcoin.stackexchange.com/questions/51125/transaction-creation-process-is-not-non-interactivemimblewimble
Nol it doesn’t run like that. Some back and forth communication is required.
See the mailing list discussion for how to transact properly. Specifically https://lists.launchpad.net/mimblewimble/msg00087.html and the later https://lists.launchpad.net/mimblewimble/msg00091.html
1 Like
This might help as well:
https://github.com/mimblewimble/grin/blob/master/doc/transaction/grin-transaction.png
It looks like the communication is:
Alice → Bob → Alice → Bob → Broadcast Final Transaction
This could be made more pleasant with an intermediary always-online server that delivers the payloads when the transactors come back online. Any ideas for improvement beyond this?
It seems that the attacker could perhaps steal by replying to Alice, spoofing their originating IP/port to pretend to be Bob. Then Alice would pay the attacker by mistake. Is this correct?
I don’t think any identity system post 2000 uses ip.
qr code of a public key should be fine
Nah, different context. That chart is just assuming a communication channel, the details of how that’s made while important are not really what its about.
I posted this in another thread but I wanted to repeat it here.
A Non-Interactive Transaction is easily accomplished if Alice and Bob are ok with the following state of affairs:
Temporarily both Bob and Alice can spend the resulting transaction. This ends when Bob comes online.
No one else can spend it while Bob is still gone.
When Bob comes online, he must immediately spend the transaction to a secure blinding factor of his own choosing and only then is the transfer between the two of them considered concluded.
This is accomplished by Alice directly generating a blinding factor for Bob that only both Alice and Bob can use.
x = Hash(m,aB)
Where B is Bob’s well known public key and m is unique to this transaction. Also, a is an Alice-secret-key corresponding to the A used as the curve point corresponding to the blinding factor the sender, Alice, was using on the input coins. Bob’s wallet can retrieve A from input side of the transaction. Also, m is selected as the Hash of unique parts of the input (TBD). Bob’s wallet must be able to generate that.
Note x is now a shared secret between Alice and Bob since Bob can recover it using bA which is equal to aB, and m. This is used as Bob’s blinding factor.
Now Alice can directly sign the verification sum, xG + 0H, because she knows the new blinding factor, x. She can also participate in generating the range proof required by the transaction.
The job of Bob’s wallet is a little more complicated unless we add an anonymous bit to the protocol to indicate this is a shared transaction between Alice and Bob.
Bob must have a wallet that checks all new outputs. If the wallet can calculate Bob’s blinding factor, x, it can move the funds again using a new unique blinding factor and add the balance to the total Bob has in his wallet.
No online simultaneous interaction between Bob and Alice required and no extraneous side channel such as email or pigeons required.
Regards,
Farid
Footnote: Of course there is no way that Alice can prove to anyone else that Bob collected his grin.
1 Like