I wrote an article about an ECDH extension for BIP 70:
https://medium.com/p/cb2f81962c1b
The article is meant for people who don't follow bitcoin-development so
I'll summarise it here:
- The notion of being able to publish a piece of data once and use it to
receive lots of payments with
On Fri, May 09, 2014 at 02:05:24PM +0200, Mike Hearn wrote:
It's always interesting to see the reinvention cycle happen in the
Bitcoin space as ideas get proposed over and over again; I'm sure Amir
Taaki will be pleased to read this as it is a slightly less
sophisticated version of what he origina
>
> Of course we quickly rejected the idea of depending solely on a
> communications backchannel to retrieve funds. Any communications medium
> that isn't the blockchain makes the payment non-atomic
Yes, I know you rejected this design, which is why I'm now proposing it
instead. I think you made
On Fri, May 09, 2014 at 05:15:52PM +0200, Mike Hearn wrote:
> >
> > Of course we quickly rejected the idea of depending solely on a
> > communications backchannel to retrieve funds. Any communications medium
> > that isn't the blockchain makes the payment non-atomic
>
>
> Yes, I know you rejected
>
> Ah, you're still misunderstanding my point: You can get atomicity in the
> worst-case where the communications medium fails *and* stealth payments
> that use up no extra space in the blockchain. This gives you the best of
> both worlds.
Sounds great! How does a lightweight client identify suc
On Fri, May 09, 2014 at 05:34:07PM +0200, Mike Hearn wrote:
> >
> > Ah, you're still misunderstanding my point: You can get atomicity in the
> > worst-case where the communications medium fails *and* stealth payments
> > that use up no extra space in the blockchain. This gives you the best of
> > b
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
>
> The exact same way you're proposing: via the payment protocol.
>
Ah, I see, that's what I was missing. So rather than have an explicit
repeated field for nonces, have an algorithm for extracting randomness from
one of the scriptSigs. I guess that makes sense.
--
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 wha
On Fri, May 9, 2014 at 8:13 PM, Peter Todd wrote:
> 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 i
10 matches
Mail list logo
