{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-20\n📝 Original message:\u003e On Jun 20, 2015, at 5:27 PM, justusranvier at riseup.net wrote:\n\u003e \n\u003e Signed PGP part\n\u003e On 2015-06-20 19:19, Eric Lombrozo wrote:\n\u003e \u003e\u003e On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e Signed PGP part\n\u003e \u003e\u003e On 2015-06-20 18:20, Jorge Timón wrote:\n\u003e \u003e\u003e \u003e On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e\n\u003e \u003e\u003e \u003e wrote:\n\u003e \u003e\u003e \u003e\u003e If we want a non-repudiation mechanism in the protocol, we should\n\u003e \u003e\u003e \u003e\u003e explicitly define one rather than relying on “prima facie”\n\u003e \u003e\u003e \u003e\u003e assumptions. Otherwise, I would recommend not relying on the existence\n\u003e \u003e\u003e \u003e\u003e of a signed transaction as proof of intent to pay…\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Non-repudiation can be built on top of the payment protocol layer.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e Non-repudiation is an intrinsic property of the ECDSA signatures which\n\u003e \u003e\u003e Bitcoin uses - it's not a feature that needs to be built.\n\u003e \u003e\u003e\n\u003e \u003e\u003e There's no way to accidentally sign a transaction and accidentally\n\u003e \u003e\u003e announce it publicly. There is no form of third-party error that can\n\u003e \u003e\u003e result in a payee receiving an erroneous contract.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e Justus,\n\u003e \u003e\n\u003e \u003e We don’t even have a concept of identity in the Bitcoin protocol, let\n\u003e \u003e alone non-repudiation. What good is non-repudiation if there’s no way\n\u003e \u003e to even associate a signature with a legal entity?\n\u003e \u003e\n\u003e \u003e Sure, we could use the ECDSA signatures in transactions as part of a\n\u003e \u003e non-repudiation scheme - but the recipient would have to also have a\n\u003e \u003e means to establish the identity of the sender and associate it with\n\u003e \u003e the the transaction.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Furthermore, in light of the fact that there *are* fully legitimate\n\u003e \u003e use cases for sending conflicting transactions…and the fact that\n\u003e \u003e determination of intent isn’t always entirely clear…we should refrain\n\u003e \u003e from attaching any further significance transaction signatures other\n\u003e \u003e than that “the sender was willing to have it included in the\n\u003e \u003e blockchain if a miner were to have seen it and accepted it…but perhaps\n\u003e \u003e the sender would have changed their mind before it actually did get\n\u003e \u003e accepted.”\n\u003e \n\u003e Bitcoin has no concept of identity, but in any type of commercial\n\u003e transaction the parties involved must know some minimal amount of\n\u003e identity information in order to transact at all.\n\u003e \n\u003e Except for some identifiable special cases, I think a payee is perfectly\n\u003e justified in treating a double spend of a payment sent to them as part\n\u003e of a commercial transaction as a fraud attempt and employing whatever\n\u003e non-Bitcoin recourse mechanisms, if any, they have access to.\n\u003e \n\u003e From the perspective of the network, the obviously correct action for\n\u003e any node or miner is to relay the first version of any transaction they\n\u003e see. The primary purpose of mining is to resolve this\n\u003e otherwise-unresolvable problem of determining which transaction among a\n\u003e set of conflicting transactions happened first.\n\u003e \n\u003e If a node or miner wants to deviate from the obviously correct\n\u003e behaviour, and if they want to avoid harming the value of the network,\n\u003e they should be particularly careful to make sure their deviation from\n\u003e \"first seen\" doesn't introduce harmful unintended side effects, like\n\u003e making fraud easier.\n\u003e \n\nThe contract between the buyer and seller is actually outside the Bitcoin network. Yes, a merchant that gets cheated could seek some other recourse in such an event…but the behavior you’re claiming as “obviously correct” is NOT obviously correct.  In fact, there are arguments against this “obviously correct” way even if we were to accept the premise that the signature implies a promise to pay (which I think many reasonable individuals would also dispute). For instance, by relaying conflicting transactions it makes it potentially easier for others to discover the double-spend attempt (of course, this requires wallets to not be lazy about this…perhaps such relays could be flagged or placed in a special message type).\n\n- Eric Lombrozo\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/ccb0176e/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/ccb0176e/attachment.sig\u003e"}