On Tue, Jan 29, 2019 at 6:46 PM wrote:
>
> If the sender refuses to sign the final transaction, the receiver just
> propagates the template transaction which pays the receiver! So it's a
> pretty weak attack.
>
> The only real attack is that the sender could double-spend the
>
Good morning Adam,
> And I'm reminded that a related point is made by belcher in the gist
> comment thread iirc (after we discussed it on IRC): over time a
> "PayJoin-only" merchant doing the simplest thing - using a single utxo
> over and over again, will concentrate more and more funds into it,
On Tuesday, January 29, 2019 6:06 PM, James MacWhyte
wrote:
> I'm not convinced this is a valid concern, at least not valid enough to add
> extra complications to the process.
Signing a transaction is something a wallet needs to be able to do anyway AND
at the final-step. And actually a
James
On Sun, Jan 27, 2019 at 2:11 PM wrote:
>
> It isn't passed "back and forth so many times".
>
You are right, I got the wrong impression the first time I read it.
> This is an important anti-DoS/anti-spy tactic, as it proves the sender
> actually owns those inputs and if the protocol is
ZmnSCPxj, thanks, responses inline.
On 28. 01. 19 5:14, ZmnSCPxj wrote:
> Good morning Ryan and Adam,
>
>> [UIH2 snipped]
>
> Perhaps I am being naive, but I seem, the B2EP and similar do not need to
> worry about UIH2.
>
> From the github discussion:
>
>> "UIH2": one input is larger than
Good morning Ryan and Adam,
> [UIH2 snipped]
Perhaps I am being naive, but I seem, the B2EP and similar do not need to worry
about UIH2.
>From the github discussion:
> "UIH2": one input is larger than any output.
.
I.e. there exists an input, for all outputs, input > output
To avoid this, we
> Why does the template transaction need to be signed in step one and passed
> back and forth so many times? What is wrong with:
It isn't passed "back and forth so many times". It works exactly as you
proposed, with the only difference is in "Step 1" the sender uses a *signed*
transaction
Why does the template transaction need to be signed in step one and passed
back and forth so many times? What is wrong with:
1. Sender creates unsigned tx with their relevant inputs and outputs. This
tx is passed to receiver.
2. Receiver adds their relevant inputs and outputs and signs their
> Is there a missing word. "by giving a person.."? Not actually sure what
> you're getting at here but I suspect it's again tangential to this BIP
> discussion.
Correct on both points. I meant to say "giving a (txid:vout:privkey)" to a
person as means of payment.
> So I think the limiting
On 27. 01. 19 8:36, rha...@protonmail.com wrote:
> Thanks Adam,
>
> I have fixed the mistakes you have pointed out:
> https://github.com/bitcoin/bips/pull/754
>
> Thanks for the detailed look!
>
>> but its virtue of steganographic hiding means only minimal uptake
>> is still enormously
Thanks Adam,
I have fixed the mistakes you have pointed out:
https://github.com/bitcoin/bips/pull/754
Thanks for the detailed look!
> but its virtue of steganographic hiding means only minimal uptake
> is still enormously interesting and worth pursuing; that's my current feeling.
I very much
Ryan and list,
I want to add some commentary to this (BIP79) to see if we can get
further in standardizing this idea.
When I first mulled it over I thought it too impractical, but its virtue
of steganographic hiding means only minimal uptake is still enormously
interesting and worth pursuing;
Thanks Sjors,
It's nice to get hear feedback like that, it'll help make me clear some stuff
up. Right now I've been working on getting a reference client for both sending
and receiving, while juggling some stuff in real life.
But here is the evolving document:
> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev
> het volgende geschreven:
>
> ==Motivation==
>
> One of the most powerful heuristic's employed by those whose goal is to
> undermine
> bitcoin's fungiblity has been to assume all inputs of a transaction are
> signed by
> a single
I've just finished writing an implementing of this, and extremely happy with
how it turned out. So I'd like to go and try go down the path of more formally
describing it and getting some comments and ultimately encourage its
wide-spread use.
==Abstract==
The way bitcoin transactions are
15 matches
Mail list logo
