<oembed><type>rich</type><version>1.0</version><author_name>npub1qf6k0f8p0h89d43l0vnx2xp5yrfgjyl8tg3hkg8jtyudrllgw2usdlfn9a</author_name><author_url>https://nostr.ae/npub1qf6k0f8p0h89d43l0vnx2xp5yrfgjyl8tg3hkg8jtyudrllgw2usdlfn9a</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-20&#xA;📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----&#xA;Hash: SHA1&#xA;&#xA;On 2015-06-20 19:19, Eric Lombrozo wrote:&#xA;&gt;&gt; On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:&#xA;&gt;&gt; &#xA;&gt;&gt; Signed PGP part&#xA;&gt;&gt; On 2015-06-20 18:20, Jorge Timón wrote:&#xA;&gt;&gt; &gt; On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo &lt;elombrozo at gmail.com&gt;&#xA;&gt;&gt; &gt; wrote:&#xA;&gt;&gt; &gt;&gt; If we want a non-repudiation mechanism in the protocol, we should&#xA;&gt;&gt; &gt;&gt; explicitly define one rather than relying on “prima facie”&#xA;&gt;&gt; &gt;&gt; assumptions. Otherwise, I would recommend not relying on the existence&#xA;&gt;&gt; &gt;&gt; of a signed transaction as proof of intent to pay…&#xA;&gt;&gt; &gt;&#xA;&gt;&gt; &gt; Non-repudiation can be built on top of the payment protocol layer.&#xA;&gt;&gt; &#xA;&gt;&gt; &#xA;&gt;&gt; Non-repudiation is an intrinsic property of the ECDSA signatures which&#xA;&gt;&gt; Bitcoin uses - it&#39;s not a feature that needs to be built.&#xA;&gt;&gt; &#xA;&gt;&gt; There&#39;s no way to accidentally sign a transaction and accidentally&#xA;&gt;&gt; announce it publicly. There is no form of third-party error that can&#xA;&gt;&gt; result in a payee receiving an erroneous contract.&#xA;&gt;&gt; &#xA;&gt;&gt; &#xA;&gt; &#xA;&gt; Justus,&#xA;&gt; &#xA;&gt; We don’t even have a concept of identity in the Bitcoin protocol, let&#xA;&gt; alone non-repudiation. What good is non-repudiation if there’s no way&#xA;&gt; to even associate a signature with a legal entity?&#xA;&gt; &#xA;&gt; Sure, we could use the ECDSA signatures in transactions as part of a&#xA;&gt; non-repudiation scheme - but the recipient would have to also have a&#xA;&gt; means to establish the identity of the sender and associate it with&#xA;&gt; the the transaction.&#xA;&gt; &#xA;&gt; &#xA;&gt; Furthermore, in light of the fact that there *are* fully legitimate&#xA;&gt; use cases for sending conflicting transactions…and the fact that&#xA;&gt; determination of intent isn’t always entirely clear…we should refrain&#xA;&gt; from attaching any further significance transaction signatures other&#xA;&gt; than that “the sender was willing to have it included in the&#xA;&gt; blockchain if a miner were to have seen it and accepted it…but perhaps&#xA;&gt; the sender would have changed their mind before it actually did get&#xA;&gt; accepted.”&#xA;&#xA;Bitcoin has no concept of identity, but in any type of commercial &#xA;transaction the parties involved must know some minimal amount of &#xA;identity information in order to transact at all.&#xA;&#xA;Except for some identifiable special cases, I think a payee is perfectly &#xA;justified in treating a double spend of a payment sent to them as part &#xA;of a commercial transaction as a fraud attempt and employing whatever &#xA;non-Bitcoin recourse mechanisms, if any, they have access to.&#xA;&#xA;- From the perspective of the network, the obviously correct action for &#xA;any node or miner is to relay the first version of any transaction they &#xA;see. The primary purpose of mining is to resolve this &#xA;otherwise-unresolvable problem of determining which transaction among a &#xA;set of conflicting transactions happened first.&#xA;&#xA;If a node or miner wants to deviate from the obviously correct &#xA;behaviour, and if they want to avoid harming the value of the network, &#xA;they should be particularly careful to make sure their deviation from &#xA;&#34;first seen&#34; doesn&#39;t introduce harmful unintended side effects, like &#xA;making fraud easier.&#xA;&#xA;-----BEGIN PGP SIGNATURE-----&#xA;Version: GnuPG v1&#xA;&#xA;iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT&#xA;LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7&#xA;FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617&#xA;APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5&#xA;WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d&#xA;5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA&#xA;fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm&#xA;gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be&#xA;646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv&#xA;hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+&#xA;GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2&#xA;po6di9uOSlLq0BJJfSrM&#xA;=HbNG&#xA;-----END PGP SIGNATURE-----</html></oembed>