* [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
@ 2011-09-23 16:21 Pieter Wuille
2011-09-23 17:38 ` kjj
0 siblings, 1 reply; 5+ messages in thread
From: Pieter Wuille @ 2011-09-23 16:21 UTC (permalink / raw)
To: Bitcoin Dev
Hello everyone,
here is an idea i've bean writing up: https://gist.github.com/1237788
I hope it can start some discussion about moving away from static bitcoin addresses
as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/...,
but as things don't seem to have been decided completely about those, I put it in a
Gist.
Please, comment.
--
Pieter
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
2011-09-23 16:21 [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol Pieter Wuille
@ 2011-09-23 17:38 ` kjj
2011-09-23 23:15 ` Pieter Wuille
0 siblings, 1 reply; 5+ messages in thread
From: kjj @ 2011-09-23 17:38 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
Pieter Wuille wrote:
> Hello everyone,
>
> here is an idea i've bean writing up: https://gist.github.com/1237788
>
> I hope it can start some discussion about moving away from static bitcoin addresses
> as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/...,
> but as things don't seem to have been decided completely about those, I put it in a
> Gist.
>
> Please, comment.
>
This may just be me, but this really looks like an incredibly convoluted
way to solve a bunch of problems that aren't really problems. The
central issue that I see, is that you assume that there is no out of
band channel, as if people were just sending transactions to addresses
that came to them in a dream.
I think that this assumption is only true when it doesn't matter. For
example, I have a donation link in my sig on the forums. I don't care
much who sends to it, or why, and I certainly don't need annotations or
a refund address. The rest of the time, payments are sent to addresses
that already have sufficient context.
Only one of the advantages listed is actually an advantage. That is
that payments to stale addresses can be stopped. This isn't much of an
advantage though, as someone blindly sending payments (donations,
really) to addresses found on backup tapes and web archives without
verifying that they are still current kinda deserve what they get. So
it really only stops payments to services that go defunct the same day
(more or less).
In the end, I just don't see the value in giving a URL so that I can go
ask a server for information that could just as easily have been encoded
in the URL directly.
Then again, I'm cynical, and didn't sleep very well last night. Maybe
the next person will think better of it.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
2011-09-23 17:38 ` kjj
@ 2011-09-23 23:15 ` Pieter Wuille
2011-09-23 23:21 ` Luke-Jr
0 siblings, 1 reply; 5+ messages in thread
From: Pieter Wuille @ 2011-09-23 23:15 UTC (permalink / raw)
To: Bitcoin Dev
On Fri, Sep 23, 2011 at 12:38:48PM -0500, kjj wrote:
> Pieter Wuille wrote:
> >Hello everyone,
> >
> >here is an idea i've bean writing up: https://gist.github.com/1237788
> >
> >I hope it can start some discussion about moving away from static bitcoin addresses
> >as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/...,
> >but as things don't seem to have been decided completely about those, I put it in a
> >Gist.
> >
> >Please, comment.
> >
> This may just be me, but this really looks like an incredibly
> convoluted way to solve a bunch of problems that aren't really
> problems. The central issue that I see, is that you assume that
> there is no out of band channel, as if people were just sending
> transactions to addresses that came to them in a dream.
>
> I think that this assumption is only true when it doesn't matter.
> For example, I have a donation link in my sig on the forums. I
> don't care much who sends to it, or why, and I certainly don't need
> annotations or a refund address. The rest of the time, payments are
> sent to addresses that already have sufficient context.
Well, I agree, this scheme is not (primarily) intended to be a solution
for people who want to accept anonymous donations; static addresses
work very well for that application (unless you want unlinkability
between different payments).
Let me try to explain what I do want to accomplish.
What current addresses are, is a reference to a public key. The way they
are used is as a template for a transaction. If you do not need complex
transactions, this suffices indeed, given that all other negotiation about
the payment occurs out-of-band already (e.g., a webshop interface that
after clicking 'pay' gives you a freshly generated bitcoin address and
stores it so it can track your payment).
What I want to do is to standardize part of that out-of-band communication
inside a protocol. The first observation is that if you want a freshly
negotiated key each time, some form of bidirectional communication is
necessary anyway, and a static txout template does not suffice anymore.
If you're doing bidirectional communication, you are no longer limited
by the space constraints of something by-human-copy-pastable, and you can
just negotiate the txout directly, which transparently adds support for
anything that is possible through bitcoin scripts.
So far, the creation of transactions is "solved". However, by asking nodes
not to broadcast their transaction, but instead just send it back (we're
communicating with some other party already anyway, and this other party
is the one who cares about the tx being accepted), the receiver can track
it as well. Furthermore, by passing tags along, identification of
transactions becomes a lot easier. As a extra advantage, this makes the
requirements for a client easier as well (it doesn't need to be a p2p
node).
The third step is adding signatures to authenticate the whole process.
They are necessary to make sure the client is communicating with who he
thinks he is, but by using them for the submission of the transaction as
well, it gives the client a proof of payment acceptance too.
Summarized: addresses are a limited method for defining payments, and as
soon as you move to a protocol instead of a static template, a lot of
possibilities open up.
--
Pieter
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
2011-09-23 23:15 ` Pieter Wuille
@ 2011-09-23 23:21 ` Luke-Jr
2011-09-24 3:05 ` Pieter Wuille
0 siblings, 1 reply; 5+ messages in thread
From: Luke-Jr @ 2011-09-23 23:21 UTC (permalink / raw)
To: bitcoin-development
On Friday, September 23, 2011 7:15:48 PM Pieter Wuille wrote:
> What I want to do is to standardize part of that out-of-band communication
> inside a protocol.
Email and XMPP are suitable. Just sign the message with the "from" key.
> The first observation is that if you want a freshly negotiated key each
> time, some form of bidirectional communication is necessary anyway, and a
> static txout template does not suffice anymore.
False. Deterministic keypairs remove the necessity of bidirectional
communication. A standard for a "public key root" "address" could be
worthwhile.
Both of these combined retain pseudonomity, while providing stateless
transactions with out-of-band data.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
2011-09-23 23:21 ` Luke-Jr
@ 2011-09-24 3:05 ` Pieter Wuille
0 siblings, 0 replies; 5+ messages in thread
From: Pieter Wuille @ 2011-09-24 3:05 UTC (permalink / raw)
To: bitcoin-development
On Fri, Sep 23, 2011 at 07:21:58PM -0400, Luke-Jr wrote:
> On Friday, September 23, 2011 7:15:48 PM Pieter Wuille wrote:
> > What I want to do is to standardize part of that out-of-band communication
> > inside a protocol.
>
> Email and XMPP are suitable. Just sign the message with the "from" key.
I don't want to send a mail to you or chat with you when I'm buying something
in your webshop. Or do you mean my client does that automatically? Why not
through an HTTP connection like the one I'm already using anyway to view
the static address on your website?
> > The first observation is that if you want a freshly negotiated key each
> > time, some form of bidirectional communication is necessary anyway, and a
> > static txout template does not suffice anymore.
>
> False. Deterministic keypairs remove the necessity of bidirectional
> communication. A standard for a "public key root" "address" could be
> worthwhile.
They still require you to give me your public key root, and me to give
you the ephemeral private key I generated, optionally together with what
I'm paying you for. That's bidirectional communication to me. Agreed, your
scheme requires a few steps less, but I believe mine is far more flexible
and user-friendly.
--
Pieter
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-09-24 3:05 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-23 16:21 [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol Pieter Wuille
2011-09-23 17:38 ` kjj
2011-09-23 23:15 ` Pieter Wuille
2011-09-23 23:21 ` Luke-Jr
2011-09-24 3:05 ` Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox