Re: [bitcoin-dev] [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-06-21 Thread Rusty Russell via bitcoin-dev
"David A. Harding" writes: > On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote: >> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual >> transaction containing the settlement is expected to have (at least) two >> inputs, with the second one originating the fees.

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Gregory Maxwell via bitcoin-dev
On Thu, Jun 21, 2018 at 7:56 PM, Peter D. Gray via bitcoin-dev wrote: > PSBT is something we need, and has been missing from the ecosystem > for a long time. Let's push this out and start talking about future > versions after we learn from this one. When you implement proposals that have little t

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Peter D. Gray via bitcoin-dev
On Tue, Jun 19, 2018 at 05:20:34PM +0200, Jonas Schnelli wrote: ... > > I don’t see any reasons why space would be an issue. > > HWWs probably can’t handle PBST natively since it is not optimised for > presenting various informations in a signing-verification. The Coldcard hardware wallet is PSB

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Peter D. Gray via bitcoin-dev
On Thu, Jun 21, 2018 at 04:32:07PM +0200, Tomas Susanka wrote: ... > First of all, let me thank you for all the hard work you and others have > put into this. > > On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote: > > While I agree that the BIP itself should be revised to reflect these > > sugge

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Pieter Wuille via bitcoin-dev
On Thu, Jun 21, 2018 at 4:29 AM, matejcik wrote: > In the case of everything per-input, the naive Signer can do this: > 1. (in the global section) pre-serialize the transaction > 2. (in each input) find and fill out scriptPubKey from the provided UTXO > 3. (for a given BIP32 path) check if the mas

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Greg Sanders via bitcoin-dev
>Hmm, upon further reflection, maybe it's not even worth including *any* per-output data, aside from what the original transaction contains. >The output redeem script is either: - unknown, because we have received only an address from the receiver - or it is known, because it is ours and in that c

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Tomas Susanka via bitcoin-dev
Hello, First of all, let me thank you for all the hard work you and others have put into this. On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote: > While I agree that the BIP itself should be revised to reflect these > suggestions, I fear that it may be too late. I know of a few other develope

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Tomas Susanka via bitcoin-dev
Hi, On 19.6.2018 19:16, Pieter Wuille via bitcoin-dev wrote: > Yes, the reason is address reuse. It may be discouraged, but it still > happens in practice (and unfortunately it's very hard to prevent > people from sending to the same address twice). > > It's certainly possible to make them per-inp

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread matejcik via bitcoin-dev
On 19.6.2018 19:16, Pieter Wuille wrote: >> 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we >> know, which BIP-32 path goes to which input? The only idea that comes to >> my mind is that we should match the input's scriptPubKey's pubkey to >> this 0x03's key (the public key). >

Re: [bitcoin-dev] Should Graftroot be optional?

2018-06-21 Thread ZmnSCPxj via bitcoin-dev
Good morning Greg, > On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > This has the advantage that the Graftroot signature commits to a single > > outpoint and cannot be used to spend all outpoints that happen to pay to > > the s