Provable Interactive Transaction #75
Comments
|
In general I am definitely in favor of some kind of PKI to be added to slates. However I do have some comments:
|
|
@jaspervdm thanks for your review :-)
|
So in your proposal you sign the whole slate (inputs, outputs, kernels). How does one validate this proof if all this information is no longer on-chain?
Yeah, we could combine the |
Sign the whole slate (more accurately, not real whole but indeed including the whole tx body: inputs, outputs, kernels) is also for the integrity checking of this whole slate. By signing the whole slate, when the sender show / publish his/her saved finalized slate for a transaction, anybody can easily verify whether it is a true whole slate without any modification. Also, we need check the aggregated Schnorr signature (from the partial sigs) indeed get the final excess_sig in the kernel.
No, the (inputs, outputs) could be no longer on-chain. But the kernel definitely can be found on archive nodes which keep all past blocks data for ever, even when we start throwing old kernels in the future just like the spent outputs. And on lower security level, we can use multiple GRIN explorers to check kernel existence. So, to summarize, the idea for validating this proof is:
Also, the sender prove the
👍 will modify the proposal to take this :-) |
|
I like the idea! For this to work the parties involved would need to only use public declared, undeniable wallet addresses. Which is a difficult task if it's not stored on the chain. |
That's a common "problem" in life. Same in Bitcoin, Bob can deny that he is the owner of the Bitcoin address which he just told Alice before. This Provable Interactive Tx solution is not for that. And I think no blockchain solution can solve the problem you mentioned above. But a simple paper contract can solve it :-) just write down the Bob's Bitcoin address on the contract, then both Bob and Alice write a handwriting signature on the contract 😄 but surely it's not related to this "Provable" Tx discussion. [updated] |
|
I think that this is a great idea. In addition to the signed slate is should also be checked that the slate has actually made it into the chain. Or am I missing any reason why the signed slate on its own is sufficient. Proving transaction existence on the chain could be difficult when the UTXO in question is already spent again, potentially requiring Merkle proofs. Please also have a look at mimblewimble/grin#2631 where I integrate the 'address' off the receiver directly into the transaction and thereby in the chain. This is however suboptimal as it potentially leaks the amounts sent. But maybe there still is some merit to this? |
|
@GandalfThePink thanks for your review.
As said in https://github.com/mimblewimble/grin/issues/2652#issuecomment-469948016,
Yes, that's why we need check the kernel instead of the output.
Okay, will look into #2631 and could leave comments there.
You can't say it And the payer always keep this signed slate, but it doesn't mean he/she always need to publish / send this to anyone. This is for the exception case when the receiver denied 😄 which should be very low ratio but indeed very very important! |
|
@garyyu Therefore I think that my older issue can be closed and we should move ahead with this idea. |
|
I don't think this belongs at the core transaction layer, nor do I think it's desirable to allow a recipient to collect irrefutable proof of who sent them what without the sender's explicit consent. As far as the proposed changes, the basic problem here is that this solution is trying to come up with a homebrew method of proving that somebody is who they say they are. This is a very complex task, and there is a multitude of solutions that already attempt do this. If I'm a merchant and I want to prove who I am, I likely already have something in place. I have some signing cert that validates up the chain to the usual root certs, and the public key is prominent on my website. If I'm interested in proving a transaction was definitely me I can sign a combination of the kernel offset and amount with that cert, put it in the existing message field, and anyone can verify using existing infrastructure. Similarly, if I'm a keybase user or have any other system in place that I like to use for verifying myself, I can do the same thing. My point here is the concept of 'address' should not be enforced or encoded into the transaction exchange protocol level. Also, if I send Bob 10 Grins and I later want to deny that I did so, that is absolutely my right. Imagine an Ashley Madison takes payment in Grin, then its db gets hacked and all of a sudden the attacker has a handy list of addresses along with irrefutable proof where each payment came from. If all parties in a transaction want to prove who they are and trust the others to keep the information appropriately, then by all means they should be allowed to do so, and indeed there already are ways they can. I'm okay with providing lightweight and non-prescriptive helpers to facilitate this, (like provide a particular message with a combination of fields to sign to prove ownership and amounts, as well as a verify function,) but it's going to take a lot of convincing to make me think we should be embedding addresses in any format directly in the transaction by default. |
|
I think what we aim to implement is that when Alice pays Bob, she can later prove that to Carol, where Carol was not involved in transaction building. To do so, Bob needs to identify and this can be done via a public key. Bob actively signs the slate and could refuse to do so when he does not want to be linked in any way to the payment. Therefore Bob voluntarily opts in to having this transaction verifiable. Alice can now prove to Carol that she has payed an entity with possession of the private key to Bobs public key. This proof is initiated by Alice and she could still choose to not verify and have plausible deniability. Therefore I do not see any privacy flaws in this implementation. In particular anyone that does not want sender-verifiable transactions can simply continue to receive non-verifiable transactions. Furthermore it does only modify the wallet functionality and leave the base chain level unaffected. I think it does make sense to implement such a feature at the wallet level since Bob has to commit to the transaction before it is finalised. It is not sufficient to let Bob sign something afterwards since Bob could simply refuse to do so and then deny payment from Alice. The implementation needs to be 'atomic' and this is best achieved at the transaction building level. |
Absolutely 😄
Same as above! this Ashley Madison is receiver, Ashley Madison can't deny received user's payment, but the user / payer CAN deny, with this "Provable" Tx solution. |
|
+1 This would be another great feature for us! |
|
To start with, I think we can state a few things to simplify the setup a bit, with Alice sending to Bob and Carol being some sort of arbitrator or external observer:
So with that in mind, what's wrong with Alice providing:
That should be enough to convince Carol without any change or complication. Or am I missing something? |
|
@ignopeverell In this case Alice could simply pay the amount to herself and claim that this was the payment for the Alpaca socks. Instead when the merchant of the socks provides a public key and signs the slate with the corresponding private key, Alice can prove that she has actually paid the merchant (and not only made a fake payment). This is proof that the owner of said public key was involved in the transaction and Bob can no longer deny that. When we have merchants operating on Grin, I think this is a feature that most customers will want to have. After all they are taking the risk and to mitigate that risk they should have proof of the Merchant having received the money. |
|
I am torn; not a big fan of PKI because to use it securely, vendors really need to be using one-time pairs, otherwise they risk being charged for products they never sold in the event their key gets leaked. I like the simplicity of doing away with this proposal in favor of reusing a serving cert but its leakage is even worse for vendors than a normal serving cert. Also, vendors can still deny they didn't receive a transaction by claiming their key was leaked, right? |
|
@Kargakis Yes vendors can still claim their key was leaked. But that would be their own fault and they probably should take responsibility for this. Also just leaking the key is not enough. The potential attacker must also convince Alice to pay to them and not to the original vendor. If anything, the added signature improves the security for the vendor. EDIT: Of course there is another attack possible where the buyer that has the key claims they made payments, but the vender was never involved. I am thinking how Grin payments would fit into a legal framework (not necessarily a national one, also something like bisq or smart contracts). In the current case without any proof, all risk is sitting at the buyer. The buyer is committing money, then the merchant may deliver or not. And in case the merchant does not deliver no third party can objectively settle the conflict. But we can add functionality for proof of payment and in case the merchant has some mechanism for proof of delivery (which is not our problem) a third party can settle. This third party might be a smart contract, funded by the merchant that simply releases money to the buyer in case of conflict. |
|
@GandalfThePink I thought the main reason behind this proposal was to protect buyers against malicious vendors. From @garyyu's initial post:
It is not perfect and it is also questionable whether it can help in most cases a dispute will arise where a vendor denies they received a payment. If a vendor really wants to dispute a transaction, why wouldn't they go the extra step and claim their key was leaked? Any evidence a sender gives to an observer can be claimed to be fake at that point? |
|
I would hope that a third party will refund the buyer even when the vendor claims that keys were leaked. Not leaking keys is the responsibility of the vendor. But that is not our job to decide. I think that the current Grin architecture allows these proofs and that there are use-cases for them. (See for example bisq). Over the long run they will get built. |
|
Here we're all assuming some sort of pubkey that's been widely share, similarly to a SSL cert or address. In which case I have to agree with @yeastplume it doesn't seem to fit in the core wallet exchange protocol and maybe should be specified separately, by relying on a structured use of the comment field, for merchant wallets. AFAIK, most merchants already need specific wallet infrastructures for their specific needs. So I'd suggest moving forward by:
|
|
I agree, specifying a protocol is a good idea and merchants can then choose to implement that. But also on the clients side there should be a check signature before the finalised transaction is broadcasted. The transaction could be build completely and we add this verification before publishing the transaction to the chain. In addition the wallet should also store the proof. Do you think it is reasonable to integrate this functionality into the base wallet, or should that be left for third-party wallets? |
|
BIP70 is related to this discussion. |
|
I believe this has been covered by recent payment proofs discussion and work, so going to close this thread. |
RECENT CHANGES:
Table of Contents
1. Use case
1.1 In Bitcoin
In the Bitcoin transaction scenario, Bob tell Alice his Bitcoin address, for example: 3ChVP627..., and Alice do a Bitcoin transaction to pay to this address, for example: 3169d1b5..., and the HASH160 form of this address is directly put on the public chain database (as the Output Scripts):
HASH160 PUSHDATA(20)[78c04dda49b06260020a106f8e279b1bfbadcb71] EQUAL.This is a perfect provable transaction, since there's no way for Bob to deny he received this payment.
1.2 In Grin
In the Grin transaction scenario, Bob tell Alice his Grin wallet address, for example:
https://bob.grinwallet.me:3415, and Alice do a Grin transaction to pay to Bob's said wallet. Once the transaction is done and confirmed on the chain, Bob has his UTXO on the chain, for example: 0861105a....But the practical problem is: there's no any public indicator on the chain which can prove this output belongs to Bob. ONLY Bob can prove this output belongs to himself, nobody else without Bob's private key!
So, in case Bob deny he received Alice's payment, it will be very complex for Alice to prove she paid, and even impossible if she can't force Bob to provide related evidence.
2. Provable Interactive Transaction solution
## 2.1 Recap of Grin current slate structure in the Interactive TransactionLet's take a look at an example of a finalized slate (of a wallet transaction):
For the detail meaning of this structure, please refer to https://github.com/mimblewimble/grin/blob/391e311f4c05619bd4b7b0d599a5071ce7753b90/wallet/src/libwallet/slate.rs#L104:L127
2.2 Enhance Grin transaction as a provable transaction
The basic idea is to import the exact same "address" concept as Bitcoin, but only use it on the Grin transaction, not on the chain.
Still with above example slate, but with the enhanced fields:
{ "num_participants": 2, "id": "8ba033b6-3e05-4cad-81ec-937f3056b1e8", "tx": { "offset": [...], "body": { (exact same as the original format) } }, "amount": 110000000, "fee": 8000000, "height": 18187, "lock_height": 18187, "participant_data": [ { "id": 0, "public_blind_excess": [...], "public_nonce": [...], "part_sig": [...], "message": null, "message_sig": null, + "p2pkh_dest": null, + "p2pkh_public_key": null, + "p2pkh_msg": [...], + "p2pkh_sig": [...] }, { "id": 1, "public_blind_excess": [...], "public_nonce": [...], "part_sig": [...], "message": null, "message_sig": null, + "p2pkh_dest": [https://addr@hostname:port], + "p2pkh_public_key": [...], + "p2pkh_msg": [...], + "p2pkh_sig": [...] } ] }Note:
p2pkh_destcan behttps://addr@hostname:port, orkeybase://addr@username, or other transport method/s.Here is the proposal for this provable Grin transaction procedure.
2.2.1 Wallet URL with the receiver's "address"
For example, when Bob tell Alice his Grin wallet address, he give both his wallet URL and his "address":
https://3ChVP627KU5w4zu2rieFPF3wGXWQgmhvrs@bob.grinwallet.me:3415.This "address" has exact same format as Bitcoin's legacy address.
2.2.2 Step 1: Alice send Bob a slate
{ "num_participants": 2, "id": "8ba033b6-3e05-4cad-81ec-937f3056b1e8", "tx": { "offset": [...], "body": { (exact same as the original format and content) } }, "amount": 110000000, "fee": 8000000, "height": 18187, "lock_height": 18187, "participant_data": [ { "id": 0, "public_blind_excess": [...], "public_nonce": [...], "part_sig": null, "message": null, "message_sig": null, + "p2pkh_dest": null, + "p2pkh_public_key": null, + "p2pkh_msg": [...], + "p2pkh_sig": [...] } ] }As the sender / payer, Alice:
p2pkh_public_keyandp2pkh_destasnullp2pkh_msgas the HASH of this slate data (excludep2pkh_*and all otherparticipant_dataarray elements, and excludeid)p2pkh_sigas the signature of thisp2pkh_msgwith the private key related topublic_blind_excess.Note: Alice must keep the told Bob's
p2pkh_destat somewhere, and need to use them in the 3rd step.2.2.3 Step 2: Bob receive above slate and send back the processed slate to Alice
Note: for security, Bob need check the received payment request whether his own "address" is there. If no, giving warning at this moment for compatibility of old version, and in the future we close the connection or ban the sender's IP in this case.
{ "num_participants": 2, "id": "8ba033b6-3e05-4cad-81ec-937f3056b1e8", "tx": { "offset": [...], "body": { (exact same as the original format and content) } }, "amount": 110000000, "fee": 8000000, "height": 18187, "lock_height": 18187, "participant_data": [ { "id": 0, (same data as above received slate) }, { "id": 1, "public_blind_excess": [...], "public_nonce": [...], "part_sig": [...], "message": null, "message_sig": null, + "p2pkh_dest": [3ChVP627KU5w4zu2rieFPF3wGXWQgmhvrs@https://bob.grinwallet.me:3415], + "p2pkh_public_key": [...], + "p2pkh_msg": [...], + "p2pkh_sig": [...] } ] }As the receiver / payee, Bob:
p2pkh_destwhich must be exact same as what he told Alice for this payment, andaddressas the 1st part of thisp2pkh_destp2pkh_public_keyas the one which match theaddressp2pkh_msgas the HASH of this slate data (excludep2pkh_*and all otherparticipant_dataarray elements, and excludeid)p2pkh_sigas the signature of thisp2pkh_msgwith the private key related top2pkh_public_key.2.2.4 Step 3: Alice receive above slate and generate a finalized slate
{ "num_participants": 2, "id": "8ba033b6-3e05-4cad-81ec-937f3056b1e8", "tx": { "offset": [...], "body": { (exact same as the original format and content) } }, "amount": 110000000, "fee": 8000000, "height": 18187, "lock_height": 18187, "participant_data": [ { "id": 0, "public_blind_excess": [...], "public_nonce": [...], + "part_sig": [...], "message": null, "message_sig": null, "p2pkh_dest": null, "p2pkh_public_key": null, + "p2pkh_msg": [...], + "p2pkh_sig": [...] }, { "id": 1, (same data as above received slate) } ] }As the sender / payer, Alice:
p2pkh_dest, which must be exact same as what she was told by Bob for this paymentaddressis indeed generated byp2pkh_public_keytx bodyp2pkh_msgandp2pkh_sig2.2.5 Finish
Alice post this transaction to the chain and this transaction will be confirmed at a few minutes.
2.3 Alice prove she did this transaction
For example, Bob deny and say he never receive this transaction from Alice.
Alice show / publish her saved finalized slate for this transaction, to Bob or any other 3rd party, anyone can validate this data and confirm Bob's lying, since this slate include Bob's address and Bob's signature, and the integrity checking.
3.Grin "address" generation
Since we already have BIP-32 HD wallet feature, it should be an easy point to have this / these "address"/es.
Btw, to support the new "address"/es, Grin wallet need to store all published / used "address", to enable the checking of any receiving payment requests, either on current "address" or on any previous "address".
4.Other use cases
I'm thinking it seems possible to share the wallet database with the auditor/s, without telling the wallet seed / private key. The auditor/s still can get the logs which can be easily validated. To be discussed with a separated issue / topic.
5.Validation API
We need some new API to enable an easy validation on this "provable" slate.
Welcome your review and any comments :-)
Especially for the security level with this solution. Please feel free to correct me if any mistakes
The text was updated successfully, but these errors were encountered: