From: justusranvier@riseup•net
To: Eric Lombrozo <elombrozo@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Date: Sat, 20 Jun 2015 19:27:40 -0500 [thread overview]
Message-ID: <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net> (raw)
In-Reply-To: <B4B8DB86-C03A-4C79-BD94-3E073D5E7003@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2015-06-20 19:19, Eric Lombrozo wrote:
>> On Jun 20, 2015, at 4:37 PM, justusranvier@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@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.”
Bitcoin has no concept of identity, but in any type of commercial
transaction the parties involved must know some minimal amount of
identity information in order to transact at all.
Except for some identifiable special cases, I think a payee is perfectly
justified in treating a double spend of a payment sent to them as part
of a commercial transaction as a fraud attempt and employing whatever
non-Bitcoin recourse mechanisms, if any, they have access to.
- From the perspective of the network, the obviously correct action for
any node or miner is to relay the first version of any transaction they
see. The primary purpose of mining is to resolve this
otherwise-unresolvable problem of determining which transaction among a
set of conflicting transactions happened first.
If a node or miner wants to deviate from the obviously correct
behaviour, and if they want to avoid harming the value of the network,
they should be particularly careful to make sure their deviation from
"first seen" doesn't introduce harmful unintended side effects, like
making fraud easier.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT
LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7
FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617
APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5
WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d
5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA
fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm
gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be
646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv
hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+
GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2
po6di9uOSlLq0BJJfSrM
=HbNG
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-06-21 0:27 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 10:39 Peter Todd
2015-06-19 13:33 ` Gavin Andresen
2015-06-19 13:52 ` Peter Todd
2015-06-19 14:00 ` Adrian Macneil
2015-06-19 14:08 ` Peter Todd
2015-06-19 14:30 ` Adrian Macneil
2015-06-19 14:59 ` Peter Todd
2015-06-19 15:20 ` Adrian Macneil
2015-06-19 15:40 ` Peter Todd
2015-06-19 16:18 ` Adrian Macneil
2015-06-19 16:37 ` Peter Todd
2015-06-19 20:39 ` Matt Whitlock
2015-06-19 21:05 ` Frank Flores
2015-06-19 21:15 ` Jeff Garzik
2015-06-20 0:47 ` Andreas Petersson
2015-06-20 1:09 ` Mark Friedenbach
2015-06-20 1:23 ` Aaron Voisine
2015-06-20 3:07 ` Eric Lombrozo
2015-06-20 3:48 ` Luke Dashjr
2015-06-20 4:02 ` Eric Lombrozo
2015-06-20 16:43 ` Ivan Brightly
2015-06-20 17:38 ` Cameron Hejazi
2015-06-19 14:40 ` Chun Wang
2015-06-19 15:22 ` Adrian Macneil
2015-06-19 13:33 ` Stephen Morse
2015-06-19 13:37 ` Chun Wang
2015-06-19 13:48 ` Peter Todd
2015-06-19 14:16 ` Lawrence Nahum
2015-06-19 13:40 ` Adrian Macneil
2015-06-19 13:44 ` Peter Todd
2015-06-19 13:52 ` Chun Wang
2015-06-19 15:43 ` Jeff Garzik
2015-06-19 19:49 ` Jeffrey Paul
2015-06-19 15:42 ` Jeff Garzik
2015-06-19 16:15 ` Peter Todd
2015-06-19 15:00 ` justusranvier
2015-06-19 15:11 ` Peter Todd
2015-06-19 15:37 ` Eric Lombrozo
2015-06-19 15:53 ` justusranvier
2015-06-19 16:36 ` Matt Whitlock
2015-06-19 16:42 ` Eric Lombrozo
2015-06-19 16:46 ` Matt Whitlock
2015-06-19 16:53 ` Peter Todd
2015-06-19 16:54 ` justusranvier
2015-06-19 17:00 ` Tier Nolan
2015-06-20 23:20 ` Jorge Timón
2015-06-20 23:37 ` justusranvier
2015-06-21 0:19 ` Eric Lombrozo
2015-06-21 0:27 ` justusranvier [this message]
2015-06-21 0:36 ` Eric Lombrozo
2015-06-21 0:54 ` Eric Lombrozo
2015-06-21 5:56 ` Tom Harding
2015-06-21 6:45 ` Jeff Garzik
2015-06-21 7:42 ` Eric Lombrozo
2015-06-21 8:35 ` Eric Lombrozo
2015-06-21 8:41 ` Btc Drak
2015-06-21 8:51 ` Eric Lombrozo
2015-06-21 19:49 ` Jeff Garzik
2015-06-21 18:23 ` Aaron Voisine
2015-06-19 16:44 ` justusranvier
2015-06-19 17:40 ` Jeff Garzik
2015-06-19 17:48 ` justusranvier
2015-06-19 17:50 ` Jeff Garzik
2015-06-19 18:00 ` justusranvier
2015-06-19 16:50 ` Milly Bitcoin
2015-06-19 16:41 ` [Bitcoin-development] Remove Us Please Gigas Gaming Inc.
2015-06-19 18:34 ` Jameson Lopp
2015-06-19 19:55 ` John Bodeen
2015-06-19 20:01 ` Brian Hoffman
2015-06-19 20:27 ` Jameson Lopp
2015-06-20 23:16 ` [Bitcoin-development] F2Pool has enabled full replace-by-fee Jorge Timón
2015-06-20 23:47 ` Eric Lombrozo
2015-06-20 23:52 ` Eric Lombrozo
2015-06-20 23:56 ` Eric Lombrozo
2015-06-19 15:39 ` justusranvier
2015-06-19 15:39 ` Jeff Garzik
2015-06-20 20:04 ` odinn
2015-06-21 2:11 ` Dario Sneidermanis
2015-06-21 2:23 ` Dario Sneidermanis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d025db96e7aec4e6e47a76883a9a1e3@riseup.net \
--to=justusranvier@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=elombrozo@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox