Re: [bitcoin-dev] [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts
"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. That second input's >> signature is (I assume) using SIGHASH_ALL to commit to all outpoints in >> the transaction, so it can't be arbitrarily rewritten by a third-party >> to apply to a different state outpoint > > I realized that the fee-paying input could possibly be signed with > SIGHASH_ALL|SIGHASH_ANYONECANPAY to allow anyone to arbitrarily > rewrite the other input signed with SIGHASH_NOINPUT. However, this > reminded me of the well-known DoS against transactions signed with > SIGHASH_ANYONECANPAY[1], which seems to apply generally against > SIGHASH_NOINPUT as well and may allow theft from HTLCs. Yes, RBF Rule #3 again :( It makes RBF unusable in adversarial conditions, and it's not miner incentive-compatible. The only mitigations I have been able to come up with are: 1. Reduce the RBF grouping depth to 2, not 10. This doesn't help here though, since you can still have ~infinite fan-out of txs (create 1000 outputs, spend each with a 400ksipa tx). 2. Revert #3 to a simple "greater feerate" rule, but delay propagation proportional to tx weight, say 60 seconds (fuzzed) for a 400 ksipa tx. That reduces your ability to spam the network (you can always connect directly to nodes and waste their time and bandwidth, but you can do that pretty much today). Frankly, I'd also like a similar mechanism to not reject low-fee txs (above 250 satoshi per ksipa) but simply not propagate them. Drop them after 60 seconds if there's no CPFP to increase their effective feerate. That would allow us to use CPFP on lightning commitment txs today, without having to guess what fees will be sometime in the future. Cheers, Rusty. > ## DoS against Eltoo settlements > > Alice and Mallory have a channel with some state updates. Alice tries > to initiate a cooperate close, but Mallory stalls and instead broadcasts > the trigger transaction and the first state (state 0). Notably, the > first state is bundled into a very large vsize transaction with a low > feerate. State 1 is added to another very large low-feerate > transaction, as are states 2 through 9. > > Alice could in theory RBF the state 0 transaction, but per BIP125 rule > #3, she needs to pay an absolute fee greater than all the transactions > being replaced (not just a higher feerate). That could cost a lot. > Alice could also create a transaction that binds the final state to the > state 9 transaction and attempt CPFP, but increasing the feerate for the > transaction ancestor group to a satisfactory degree would cost the same > amount as RBF. > > So Alice is stuck waiting for states 0-9 to confirm before the final > state can be confirmed. During recent periods of full mempools on > default nodes, the waiting time for 10 nBTC/vbyte transactions has been > more than two weeks. > > ## HTLC theft > > If Mallory is able to introduce significant settlement delays, HTLC > security is compromised. For example, imagine this route: > > Mallory <-> Alice <-> Bob > > Mallory orders a widget from Bob and pays via LN by sending 1 BTC to > Alice hashlocked and timelocked, which Alice forwards to Bob also > hashlocked and timelocked. Mallory releases the preimage to Bob, who > claims the funds from Alice and ships the widget, giving Alice the > preimage. > > At this point, Mallory broadcasts the transactions described in the > preceding section. > > If the low feerate of states 0-9 prevent them from confirming before the > timeout, Mallory can create a transaction containing a dishonest final > state that executes the refund branch. Like before, she can bury this > in an ancestor transaction chain that would be cost prohibitive for Alice > to RBF. > > Considered independently, this is a very expensive attack for Mallory, > and so perhaps impractical. But Mallory can join forces with someone > already creating large low-feerate consolidation transactions. Better > yet, from Mallory's perspective, she can execute the attack against > hundreds of channels at once (creating long chains of ancestor > transactions that are large in aggregate rather than individually > large), using the aggregate size of all the victims' channels against > each of the individual victims. > > Thanks, > > -Dave > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-August/006438.html > ___ > Lightning-dev mailing list > lightning-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
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 to no public discussion about them you take the risk that your work needs to be changed when other people do actually begin reviewing the work. It is incredibly demoralizing as a designer and a reviewer to have proposals that were put out for discussion show up implemented in things with these vested interests then insisting that they not be refined further. I think kind of handling is toxic to performing development in public. Although it's silly enough that it won't happen, I think our industry would be better off if there was a social norm that anytime someone insists an unfinished proposal shouldn't be changed because they already implemented it that the spec should _always_ be changed, in order to discourage further instances of that conduct. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
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 PSBT native and does work directly from PSBT. > A single stream-in of a PSBT through USB (or similar channel) will not work in > many cases since HWW come often with very restrictive RAM constraints. For the Coldcard, we expect a PSBT to be 'uploaded' over USB (can also be provided on MicroSD card) and we work in-place with it, scanning over it a few different times. If the user approves the transaction, we produce a signed PSBT or final transaction and that gets downloaded. We support 256k byte PSBT files with hundreds of inputs/outputs (IIRC, and exact limits still TBD) and are operating in a system with only 25k free RAM after startup. > Furthermore, I forget to mention in my last mail, that registering (or > defining) > a mime-type for PSBT would probably a great usability feature. > (Send PSBT by email/messanger and with dbl-click to open feature, etc.) +1 for mimetype, especially since it's a binary format. --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
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 > > suggestions, I fear that it may be too late. I know of a few other > > developers who have implemented BIP 174 already but have not yet responded > > to this email. > > We do realize that this discussion should have happened earlier, however > agreeing on a good standard should be the number one priority for all > the parties involved. > > The fact that someone already implemented this is indeed unfortunate, > but I don't think we should lower our demands on the standard just > because of a bad timing. We all want a "good" standard but we have that already, IMHO. What you are really saying is you want a "better" standard, and I would argue that's our enemy right now. It's just too easy to propose a few tweaks, with "wouldn't it be better if..." I feel strongly we are entering the "design by committee" territory with BIP174. I have personally implemented this spec on an embedded micro, as the signer and finalizer roles, and written multiple parsers for it as well. There is nothing wrong with it, and it perfectly meets my needs as a hardware wallet. So, there is a good proposal already spec'ed and implemented by multiple parties. Andrew has been very patiently shepherding the PR for over six months already. 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. --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
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 master fingerprint matches > mine, if yes, derive secret key, output pubkey, signature > 4. goto 3 (more keys per input), goto 2 (next input) > > Note that this flow works perfectly for multisig; it’s going to be the > job of a Finalizer to build the final scriptSig, but each input can have > multiple partial signatures -- and, interestingly, the naive Signer > doesn’t even need to know about multisig. Ah, you're thinking of an even simpler signer than I was imagining. I don't think this works in general, because the hash being signed depends on the structure of the script. For example, if it is P2SH, it is the redeemscript that goes into the scriptCode serialization rather than the scriptPubKey. If it is segwit, BIP143 serialization needs to be used, etc. It may work if your signing is restricted to just one of those structures, though. > A less naive Signer will want to check things, maybe derive a scriptSig > itself and check if it matches the given hash, etc., but it can do this > all in place. You go linearly through the signing flow and place a > couple strategic assertions along the way. Right - but I think anything but the simplest signer must do this, just to be able to distinguish between different kinds of signature hashing. But you're right, having per-input redeemscript/witnessscript simplifies things still - instead of needing to look a script hash in a map, you can just compare it with *the* redeemscript/witnessscript. > However, if the data is global, as is now, it gets more complicated: > 1. (in the global section) pre-serialize the transaction, prefill lookup > tables > 2. (for a given BIP32 path) check if mine, then derive public key and > store in a dictionary > 3. (for each input) find _and parse_ scriptPubKey, extract (PK or) > script hash > 4. lookup redeem script based on script-hash; if not found, goto 2; if > found, parse out public key > 5. lookup public key in the BIP32 dictionary; if not found, goto 2 > 6. output pubkey, signature I understand your point now. I hadn't considered the possibility of just signing with all BIP32 derivation paths given for which the master matches, instead of extracting pubkeys/pkhs from the script. That's a major simplification for signers indeed. I do think you need some conditions before to determine the script structure (see above), but this is a good point in favour of making the derivation paths per-input. > In general, you seem to focus a lot on the role of Combiners, esp. > simple Combiners. To me, that doesn’t look like a significant role. As I > envision it, a Combiner really doesn’t need to do anything more > complicated than merge and deduplicate records, simply based on the > uniqueness of the whole record. It's more a side-effect of focusing on forward compatibility. I expect that we will have transactions with inputs spending different kinds of outputs, and some signers may not be able to understand all of them. However, as long as the design goal of having Combiners function correctly for things they don't understand, everything should be able to work together fine. > It’s the Finalizer’s job to reconstruct and validate the result. Also > ISTM if something messes up the PSBT (such as including multiple > conflicting fields anywhere), it’s OK to leave it to Finalizer to fail. Agree. > An aside to this in particular, I’ve been thinking about the requirement > to share derivation paths and public keys with the Creator. The spec > assumes that this will happen; you’re talking about providing full > xpub+chaincode too. At least, the Creator must prefill BIP32 paths and > master key fingerprints. Possibly also prefill public keys in the redeem > scripts? > > This might not be an improvement proposal, but a point worth being > raised and maybe explained in the spec. Perhaps the original Creator > doesn’t have access to this data, and delegates this to some > “sub-Creators” - I imagine a coordinator sending a PSBT to signing > parties, each of which acts as a sub-Creator (fills out derivation paths > and public keys) and a Signer (forwarding to a HWW). Some of the > discussion even suggests some sort of generic “key derivation field” > with arbitrary contents - fingerprint + bip32 path? xpub + chain code? > derivation points? encrypted xprv? That makes sense - I think we've already touched this when discussing the requirement for UTXOs to be added. Perhaps those aren't added by the Creator, but by some index server. The same could be true for the scripts or derivations paths. And indeed, most of the information in the derivation paths is effectively opaque to the Creator - it's just some data given out by the Signer about its keys that g
Re: [bitcoin-dev] BIP 174 thoughts
>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 case it doesn’t make sense to include it in PSBT Signers are an extremely heterogeneous bunch. A signer may need to introspect on the script, such as "this is a 2-of-3, and I'm one of the keys". Even in basic p2pkh settings not adding any output information rules out things like change detection on any conceivable hardware wallet, or even simple software wallets that don't carry significant state. On Thu, Jun 21, 2018 at 10:35 AM Tomas Susanka via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > developers who have implemented BIP 174 already but have not yet responded > to this email. > > We do realize that this discussion should have happened earlier, however > agreeing on a good standard should be the number one priority for all > the parties involved. > > The fact that someone already implemented this is indeed unfortunate, > but I don't think we should lower our demands on the standard just > because of a bad timing. > > >> A question to consider is, > >> will there be more per-output data? If yes, it might make sense to have > >> an output section. > > I think it is unlikely that there would be anymore per-output data. > > 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 case it doesn’t make > sense to include it in PSBT > > We got stuck on the idea of the Creator providing future (output) > redeem/witness scripts. But that seems to be a minority use case and can > be solved efficiently via the same channels that coordinate the PSBT > creation. Sorry to change opinions so quickly on this one. > > > > >> 3) The sighash type 0x03 says the sighash is only a recommendation. That > >> seems rather ambiguous. If the field is specified shouldn't it be > binding? > > I disagree. It is up to the signer to decide what they wish to sign, not > for the creator to specify what to sign. The creator can ask the signer to > sign something in a particular way, but it is ultimately up to the signer > to decide. > > This seems very ambiguous. The Signer always has the option of not > signing. *What* to sign is a matter of coordination between the parties; > otherwise, you could make all the fields advisory and let anyone sign > anything they like? > > We don't understand the usecase for a field that is advisory but not > binding. On what basis would you choose to respect or disregard the > advisory field? Either one party has a preference, in which case they > have to coordinate with the other anyway - or they don't, in which case > they simply leave the field out. > > > Size is not really a constraint, but we do not want to be unnecessarily > large. The PSBT still has to be transmitted to other people. It will likely > be used by copy and pasting the string into a text box. Copying and pasting > very long strings of text can be annoying and cumbersome. So the goal is to > keep the format still relatively clear while avoiding the duplication of > data. > > I agree. Just to put some numbers on this: if we expect a 5-part > derivation path, and add the master key fingerprint, that is 4 + 5*4 = > 24 bytes (~32 base64 letters) per input and signer. I'd argue this is > not significant. > If we used full xpub, per Pieter's suggestion, that would grow to 32 + > 32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot. > > On the other hand, keeping the BIP32 paths per-input means that we don't > need to include the public key (as in the lookup key), so that's 32 > bytes down per path. In general, all the keys can be fully reconstructed > from their values: > > redeem script key = hash160(value) > witness script key = sha256(value) > bip32 key = derive(value) > > The one exception is a partial signature. But even in that case we > expect that a given public key will always correspond to the same > signature, so we can act as if the public key is not part of the "key". > In other words, we can move the public key to the value part of the record. > > This holds true unless there's some non-deterministic signing scheme, > *and* multiple Signers sign with the same public key, which is what > Pieter was alluding to on Twitter > (https://twitter.com/pwuille/st
Re: [bitcoin-dev] BIP 174 thoughts
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 developers > who have implemented BIP 174 already but have not yet responded to this email. We do realize that this discussion should have happened earlier, however agreeing on a good standard should be the number one priority for all the parties involved. The fact that someone already implemented this is indeed unfortunate, but I don't think we should lower our demands on the standard just because of a bad timing. >> A question to consider is, >> will there be more per-output data? If yes, it might make sense to have >> an output section. > I think it is unlikely that there would be anymore per-output data. 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 case it doesn’t make sense to include it in PSBT We got stuck on the idea of the Creator providing future (output) redeem/witness scripts. But that seems to be a minority use case and can be solved efficiently via the same channels that coordinate the PSBT creation. Sorry to change opinions so quickly on this one. > >> 3) The sighash type 0x03 says the sighash is only a recommendation. That >> seems rather ambiguous. If the field is specified shouldn't it be binding? > I disagree. It is up to the signer to decide what they wish to sign, not for > the creator to specify what to sign. The creator can ask the signer to sign > something in a particular way, but it is ultimately up to the signer to > decide. This seems very ambiguous. The Signer always has the option of not signing. *What* to sign is a matter of coordination between the parties; otherwise, you could make all the fields advisory and let anyone sign anything they like? We don't understand the usecase for a field that is advisory but not binding. On what basis would you choose to respect or disregard the advisory field? Either one party has a preference, in which case they have to coordinate with the other anyway - or they don't, in which case they simply leave the field out. > Size is not really a constraint, but we do not want to be unnecessarily > large. The PSBT still has to be transmitted to other people. It will likely > be used by copy and pasting the string into a text box. Copying and pasting > very long strings of text can be annoying and cumbersome. So the goal is to > keep the format still relatively clear while avoiding the duplication of data. I agree. Just to put some numbers on this: if we expect a 5-part derivation path, and add the master key fingerprint, that is 4 + 5*4 = 24 bytes (~32 base64 letters) per input and signer. I'd argue this is not significant. If we used full xpub, per Pieter's suggestion, that would grow to 32 + 32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot. On the other hand, keeping the BIP32 paths per-input means that we don't need to include the public key (as in the lookup key), so that's 32 bytes down per path. In general, all the keys can be fully reconstructed from their values: redeem script key = hash160(value) witness script key = sha256(value) bip32 key = derive(value) The one exception is a partial signature. But even in that case we expect that a given public key will always correspond to the same signature, so we can act as if the public key is not part of the "key". In other words, we can move the public key to the value part of the record. This holds true unless there's some non-deterministic signing scheme, *and* multiple Signers sign with the same public key, which is what Pieter was alluding to on Twitter (https://twitter.com/pwuille/status/1002627925110185984). Still, I would argue (as he also suggested) that keeping the format more complex to support this particular use case is probably not worth it. Also, we can mostly ignore deduplication of witness/redeem scripts. These still need to be included in the resulting transaction, duplicated if necessary, so I think counting their repetition against the size of PSBT isn't worth it. Best, Tomas ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
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-input (and even per-output as
> suggested below), but I don't think it gains you much. At least when a
> signer supports any kind of multisig, it needs to match up public keys
> with derivation paths. If several can be provided, looking them up
> from a global table or a per-input table shouldn't fundamentally
> change anything.
>
> However, perhaps it makes sense to get rid of the global section
> entirely, and make the whole format a transaction plus per-input and
> per-output extra fields. This would result in duplication in case of
> key reuse, but perhaps that's worth the complexity reduction.
I think having a global section with just one record (the transaction)
is just fine, in case we come up with some other fields later on which
would fit the global section. Otherwise I totally agree.
>> 2) The global items 0x01 (redeem script) and 0x02 (witness script) are
>> somewhat confusing. Let's consider only the redeem script (0x01) to make
>> it simple. The value description says: "A redeem script that will be
>> needed to sign a Pay-To-Script-Hash input or is spent to by an output.".
>> Does this mean that the record includes both input's redeem script
>> (because we need to sign it), but also a redeem script for the output
>> (to verify we are sending to a correct P2SH)? To mix those two seems
>> really confusing.
>>
>> Yet again, adding a new output section would make this more readable. We
>> would include the input’s redeem script in the input section and the
>> output’s redeem script again in the output section, because they’ll most
>> likely differ anyway.
> I think here it makes sense because there can actually only be (up to)
> one redeemscript and (up to) one witnessscript. So if we made those
> per-input and per-output, it may simplify signers as they don't need a
> table lookup to find the correct one. That would also mean we can drop
> their hashes, even if we keep a key-value model.
Yes, indeed. Just to clarify: in the first sentence you mean "per
output", right? There can actually only be (up to) one redeemscript and
(up to) one witnessscript *per output*.
>> 4) Is it a good idea to skip records which types we are unaware of? We
>> can't come up with a reasonable example, but intuitively this seems as a
>> potential security issue. We think we should consider introducing a
>> flag, which would define if the record is "optional". In case the signer
>> encounters a record it doesn't recognize and such flag is not set, it
>> aborts the procedure. If we assume the set model we could change the
>> structure to {data}. We are not keen on
>> this, but we wanted to include this idea to see what you think.
> Originally there was at least this intuition for why it shouldn't be
> necessary: the resulting signature for an input is either valid or
> invalid. Adding information to a PSBT (which is what signers do)
> either helps with that or not. The worst case is that they simply
> don't have enough information to produce a signature together. But an
> ignored unknown field being present should never result in signing the
> wrong thing (they can always see the transaction being signed), or
> failing to sign if signing was possible in the first place. Another
> way of looking at it, the operation of a signer is driven by queries:
> it looks at the scriptPubKey of the output being spent, sees it is
> P2SH, looks for the redeemscript, sees it is P2WSH, looks for the
> witnessscript, sees it is multisig, looks for other signers'
> signatures, finds enough for the threshold, and proceeds to sign and
> create a full transaction. If at any point one of those things is
> missing or not comprehensible to the signer, he simply fails and
> doesn't modify the PSBT.
The rationale behind this was, what if at some point we come up with a
PSBT record, which forbids some kind of operation or alters some
behaviour. In another words, by omitting such record the signer would
create a signature, which is valid, but actually signed something
different than the Creator intended.
> However, if the sighash request type becomes mandatory, perhaps this
> is not the case anymore, as misinterpreting something like this could
> indeed result in an incorrect signature.
I believe this use case illustrates it quite well. Let’s suppose the
sighash record is binding and the Signer does not know it. The Creator
creates a PSBT with sighash set SIGHASH_SINGLE. The Signer sings the
transaction with SIGHASH_ALL, because they are not aware of such field.
This results in a valid signature, however not what the Creator intended
it to be.
>> We’d also like to note that the “number of inputs” field should be
>> mandatory - and as such, possibly also a ca
Re: [bitcoin-dev] BIP 174 thoughts
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). > >> If our understanding is correct, the BIP-32 path is global to save space >> in case two inputs share the same BIP-32 path? How often does that >> happen? And in case it does, doesn't it mean an address reuse which is >> discouraged? > > 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-input (and even per-output as > suggested below), but I don't think it gains you much. At least when a > signer supports any kind of multisig, it needs to match up public keys > with derivation paths. If several can be provided, looking them up > from a global table or a per-input table shouldn't fundamentally > change anything. So here’s a thing I’m still confused about. Imagine two cases, for a naive Signer: - either all data is global - or most data is per input. Now, the general signing flow is this: 1. Pre-serialize the transaction 2. Prepare the current input - fill out scriptPubKey (or equivalent for segwit) 3. find a secret key 4. output public key + signature Step (3) is the main issue here. 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 master fingerprint matches mine, if yes, derive secret key, output pubkey, signature 4. goto 3 (more keys per input), goto 2 (next input) Note that this flow works perfectly for multisig; it’s going to be the job of a Finalizer to build the final scriptSig, but each input can have multiple partial signatures -- and, interestingly, the naive Signer doesn’t even need to know about multisig. A less naive Signer will want to check things, maybe derive a scriptSig itself and check if it matches the given hash, etc., but it can do this all in place. You go linearly through the signing flow and place a couple strategic assertions along the way. However, if the data is global, as is now, it gets more complicated: 1. (in the global section) pre-serialize the transaction, prefill lookup tables 2. (for a given BIP32 path) check if mine, then derive public key and store in a dictionary 3. (for each input) find _and parse_ scriptPubKey, extract (PK or) script hash 4. lookup redeem script based on script-hash; if not found, goto 2; if found, parse out public key 5. lookup public key in the BIP32 dictionary; if not found, goto 2 6. output pubkey, signature In addition to being more steps and lookups, it requires the Signer to understand the redeem script. A strict Signer will want that anyway, but in the first case, the Signer can regenerate the scripts and compare specificaly the ones it's working with; here, you need to parse them even before you know what you're comparing to. Is there something I’m missing? Because as I see it, there is literally no advantage to the more complicated flow; that’s why we assumed that the format is space-saving, because saving space was the only reason we could imagine. > If we go down this route, if a field is marked as mandatory, can you > still act as a combiner for it? Future extensions should always > maintain the invariant that a simple combiner which just merges all > the fields and deduplicates should always be correct, I think. So such > a mandatory field should only apply to signers? (...) > However, perhaps we do want to enforce at-most one UTXO per input. If > there are more potential extensions like this, perhaps a key-value > model is better, as it's much easier to enforce no duplicate keys than > it is to add field-specific logic to combiners (especially for > extensions they don't know about yet). In general, you seem to focus a lot on the role of Combiners, esp. simple Combiners. To me, that doesn’t look like a significant role. As I envision it, a Combiner really doesn’t need to do anything more complicated than merge and deduplicate records, simply based on the uniqueness of the whole record. It’s the Finalizer’s job to reconstruct and validate the result. Also ISTM if something messes up the PSBT (such as including multiple conflicting fields anywhere), it’s OK to leave it to Finalizer to fail. Are the Combiners supposed to be separate from Finalizers? (Is there a risk of a Combiner passing along a bad PSBT, Finalizer rejecting it, and the other parties not finding out?) > If we go with the "not put signatures/witnesses inside the transaction > until all of them are finalized" suggestion, perhaps the number of > inputs field can be dropped. There would be always
Re: [bitcoin-dev] Should Graftroot be optional?
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 same `P` public key. > > If it isn't possible to make a graftroot signature independent of the > > outpoint then the functionality is greatly reduced to the point of > > largely mooting it-- because you could no longer prepare the grafts > > before the coins to be spent existed, and meaning you must stay online > > and sign new grafts as coins show up. In my view graft's two main > > gains are being able to delegate before coins exist and making the > > conditional transfer atomic (e.g. compared to just pre-signing a > > transaction). Making outpoint binding optional, so that you could > > choose to either sign for particular outputs or in a blanket way would > > be a lot more useful. > Perhaps `SIGHASH_NOINPUT` can do this? One can argue that the option to not commit a signature to refer to a specific outpoint is orthogonal to the option to Graftroot, so having a separate flag for that makes sense. The proposal could then be: 1. Define a transaction `nVersion` reserved for Graftroot. Transactions with that `nVersion` are disallowed in blocks. 2. If a next-SegWit-version P2WPKH (or P2WPK) is spent, and the top witness stack item is a signature with `SIGHASH_GRAFTROOT` flag, then this is a Graftroot spend. 3. The signature signs an imaginary 1-input 1-output tx, with the input copied from the spending tx, the output value being the entire output being spent, and the output `scriptPubKey` being the Graftroot script (second to top witness stack). The imaginary tx has the Graftroot-reserved `nVersion`. 4. The Graftroot signature has its other flags `SIGHASH_NOINPUT` evaluated also when verifying it signs the imaginary tx. 5. The Graftroot signature and the Graftroot script are popped and the script executed in the context of the original Graftroot-spending tx. This lets users select whether committing to a specific outpoint is needed or not, independently of Graftroot. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
