Is it technically possible that one can transfer grin even if the receiving party is offline?

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?

  1. Alice creates partial transaction and sends it to Bob
  2. 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

Is that shown in the chart posted above by @igno.peverell?

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

If Alice cannot prove that Bob collected his Grin, how can Alice defend herself if Bob for whatever the reason says that the payment was not made?

Example:
Alice wins Bob’s eBay auction for a bicycle, sends payment via the tx flow you outline above, never receives her bicycle, complains to eBay, and Bob says ‘I never received the money’.
-> What is Alice/eBay to do here?

This technique wouldn’t help Alice.

How does Alice prove Bob is the right Bob and not an imposter when sending a regular transaction? I assume if there is need of proof, they use a regular transaction and/or some extra protocol that proves Bob is Bob.

My proposal: A Non-Interactive Transaction Solution for Mimblewimble (https://lists.launchpad.net/mimblewimble/msg00602.html)

It looks like you managed to shoe-horn bitcoin’s model in there, with tx outputs indirectly specifying what public key can spend them. But the resulting system incurs a lot of warts, detracting from the elegance of the MW design.

1 Like