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
14 matches
Mail list logo
