From: Peter Todd <pete@petertodd•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Date: Fri, 9 May 2014 14:13:53 -0400 [thread overview]
Message-ID: <20140509181353.GB27819@savin> (raw)
In-Reply-To: <CAPg+sBh-OA7xSp3=SEGS1fP-d2CDMzMy_=S_jOs1hvdaWTw0mA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]
On Fri, May 09, 2014 at 05:50:33PM +0200, Pieter Wuille wrote:
> I believe stealth addresses and the payment protocol both have their
> use cases, and that they don't overlap.
>
> If you do not want to communicate with the receiver, you typically do
> not want them to know who is paying or for what (otherwise you're
> already talking to them in some way, right?). That's perfect for
> things like anonymous donations.
>
> In pretty much every other case, communicating directly with the
> receiver has benefits. Negotiation of the transaction details,
> messages associated with the transaction, refund information, no need
> to scan the blockchain for incoming transaction... and the ability to
> cancel if either party doesn't agree.
>
> Instead of adding stealth functionality to the payment protocol as a
> last resort, I'd rather see the payment protocol improve its
> atomicity. Either you want the data channel sender->receiver, or you
> don't. If it isn't available and you want it, things should fail. If
> you don't want it, you shouldn't try to use it in the first place.
I don't think we're going to find that's practical unfortunately due to
change. Every payment I make ties up txouts, so if we try to base the
atomicity of payments on whether or not the payee decides to broadcast
the transaction the payor is stuck with txouts that they can't use until
the payee makes up their mind. That leads to lots and lots of nasty edge
cases.
OTOH if we base the atomicity of payment on whether or not a specific
txout exists everything those edge cases don't exist. Yes, that might
force us to expose transaction fees to the user, but after all it's the
user who has control over those fees.
A separate issue is IsStandard() rules, and a near-term project for me
is to write a much relaxed version of them based on soft-fork safe
whitelisting/blacklisting of opcodes, version numbers, mutability etc.
We can definitely get to the point where those rules will change very
little.
--
'peter'[:-1]@petertodd.org
00000000000000006d5945d2dddece39487c36673e56a292b619b1929ff3b40f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-05-09 18:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 12:05 Mike Hearn
2014-05-09 15:03 ` Peter Todd
2014-05-09 15:15 ` Mike Hearn
2014-05-09 15:27 ` Peter Todd
2014-05-09 15:34 ` Mike Hearn
2014-05-09 15:43 ` Peter Todd
2014-05-09 16:12 ` Mike Hearn
2014-05-09 15:50 ` Pieter Wuille
2014-05-09 18:13 ` Peter Todd [this message]
2014-05-09 18:38 ` Pieter Wuille
2014-05-12 13:07 ` Peter Todd
2014-05-12 22:40 ` Chris Pacia
2014-05-13 10:29 ` Mike Hearn
2014-05-13 9:19 ` Jeff Garzik
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=20140509181353.GB27819@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@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