Eric Lombrozo [ARCHIVE] on Nostr: đź“… Original date posted:2015-06-20 đź“ť Original message:> On Jun 20, 2015, at 4:37 ...
đź“… Original date posted:2015-06-20
đź“ť Original message:> On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:
>
> Signed PGP part
> On 2015-06-20 18:20, Jorge TimĂłn wrote:
> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo at gmail.com>
> > wrote:
> >> If we want a non-repudiation mechanism in the protocol, we should
> >> explicitly define one rather than relying on “prima facie”
> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> of a signed transaction as proof of intent to pay…
> >
> > Non-repudiation can be built on top of the payment protocol layer.
>
>
> Non-repudiation is an intrinsic property of the ECDSA signatures which
> Bitcoin uses - it's not a feature that needs to be built.
>
> There's no way to accidentally sign a transaction and accidentally
> announce it publicly. There is no form of third-party error that can
> result in a payee receiving an erroneous contract.
>
>
Justus,
We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity?
Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction.
Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.”
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/9dd48b8f/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/9dd48b8f/attachment.sig>;
đź“ť Original message:> On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:
>
> Signed PGP part
> On 2015-06-20 18:20, Jorge TimĂłn wrote:
> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo at gmail.com>
> > wrote:
> >> If we want a non-repudiation mechanism in the protocol, we should
> >> explicitly define one rather than relying on “prima facie”
> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> of a signed transaction as proof of intent to pay…
> >
> > Non-repudiation can be built on top of the payment protocol layer.
>
>
> Non-repudiation is an intrinsic property of the ECDSA signatures which
> Bitcoin uses - it's not a feature that needs to be built.
>
> There's no way to accidentally sign a transaction and accidentally
> announce it publicly. There is no form of third-party error that can
> result in a payee receiving an erroneous contract.
>
>
Justus,
We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity?
Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction.
Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.”
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/9dd48b8f/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/9dd48b8f/attachment.sig>;