Re: [bitcoin-dev] Modern Soft Fork Activation
On Saturday 11 January 2020 14:42:07 Anthony Towns wrote: > the UASF approach had significant potential technical problems > (potential for long reorgs, p2p network splits) that weren't > resolved by the time it became active. Long reorgs, only for old nodes, were a possibility, but not a problem. The p2p network split issues WERE resolved well before activation. (In fact, Bitcoin Knots still ships with the general p2p fixes.) > neither > BIP-148 or BIP-91 gained enough consensus to be supported in > bitcoin core though There was no measurable difference in community support between BIP148 and Segwit itself, months before BIP148's activation. (There was about 20% that indicated they would support BIP148 "only if Bitcoin Core releases it", which IMO "counts" in this context.) The only difference was in the opinions of developers. Basing the decision to exclude BIP148 as even an *option* on this basis was IMO improper and shouldn't be repeated. The community's readiness to switch to another fork/build for UASFs is also valuable, but shouldn't be necessary. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files
I am not sure that this particular task should be done with data embedded in PSBT itself, and not with some sort of container that includes PSBT and the authentication information. The benefit seems to be in reusing PSBT structure for compatibilty, and this might be a valid way, although I do not agree with some of your points. I elaborate below: > 1) In the PSBT globals section, a signature over the "source" PSBT > file. It would cover all the bytes of the original PSBT file, as > it was received by the Signer. The problem of authenticating the contents of PSBT is independent of the signing action. PSBT might be altered on the path from Creator to Signer. Therefore you cannot always say that Signer will be an authority over 'correctness' of PSBT. > - At the end of the signing process, the Finalizer should check all > the Signers have worked from the same PSBT file (assuming that's > the flow expected) If there is MitM, checking something at Finalizer is likely too late - the party that can intercept PSBTs can finalize before the legitimate Finalizer and broadcast the transaction. Participants can work from the same PSBT file if they all receive the same PSBT, and not working in chain where next particpant receives updated PSBT from the previous participant. Otherwise they will need to either pass two files (original and updated), or work out which fields (key-value blobs) to remove to get the 'source' PSBT (which might not be trivial with presense of proprietary and unknown fields). Even if you know which key-value pairs to remove, there is no requirement for ordering of the fields, and some signer can serialize them in different order after dserialize/sign/add-signatures/re-serialize operation. Introducing additional ordering or other structure requirements over simple key-value structure will add complexity to PSBT processing, and adding complexity on such a basic level should have really serious reasons, because that increases effort required for even basic implementations and increases chance of bugs. If there is some authority on the 'correctness' of 'original' PSBT (all particpants receive same PSBT at the start), particpants should check the signature by that authority. That authority might use the key used only for authentication, and not in the tx signing. If particpants send PSBT in chain after adding their signatures, then each participant can add their signature to say 'the contents of PSBT after my updates should match this hash'. The signatures of previous participants in the chain most likely do not matter because of difficulty of restoring the contents of PSBT as it was before the previous particpant, if you do not pass _all_ the PSBTs (which is excessive). > 2) In the output section, specifically, the last key/value pair of > the last output of the transaction, I want to add a similar signature, > again signed by one of the keys used in the signing process. This > signature will cover all the bytes of the resulting (signed) PSBT > up to that point. Because it is the last output of the output > section, that signature will be the last few bytes of the PSBT file. > By "appending" the signature in this way, it's easier to validate > and create the signature, without blanking the signature area during > digest step. This will introduce unnecessary higher-level structure to PSBT for the reasons that I do not find strong enough for the amount of complexity added. Also, as I said above, you likely do not need more than one signature - if this is 'fan-out' scheme, then participants need do check the sig of authority that created PSBT; if this is piggy-back chain, then only previous particpant's signature is easily verifiable. > ## Next Steps > > I'd like to get two officially-assigned BIP-174 key numbers assigned > for these two signatures, and then I will see that it gets added > into Coldcard's firmware immediately. In time, other tools are > welcome to take advantage of these checks. I will also write a BIP > for this, and/or make an addition to BIP-174. I think you do not need to wait for officially-assigned key numbers, and can just implement the scheme you envision with proprietary keys, document and promote it. Then if it shows its usefulness, it will either become de-facto standard with your proprietary keys (and everyone will want to support 'Coldard PSBT auth' or whatever the name), or the scheme will have serious grounds to be converted to standard and have non-proprietary keys assigned. // Dmitry. pgpJQNtMxYpnT.pgp Description: Цифровая подпись OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files
## Background PSBT files in transit are at risk of MiTM changes. This isn't supposed to matter, but as another layer of defence, I would like to add two signatures to PSBT files when they are processed by the PSBT Signer. These additional fields would be optional, and should pass through existing PSBT processors transparently, assuming they pass unknown key/values as BIP-174 specifies. ## Additional Key/Values 1) In the PSBT globals section, a signature over the "source" PSBT file. It would cover all the bytes of the original PSBT file, as it was received by the Signer. The key used for the signature may be any one the keys that the Signer applied during its transaction signing process. (This is flexible so that the Signer can make the signature at any point in the signing process. On the Coldcard, we would probably use the first key that we used for signing, so the first key involved in the first input.) The "key" of the global value will be pubkey value of the key which was selected by the Signer. If its BIP32 derivation is needed for some reason, that is documented in the input section already. The "value" will be 65(?) bytes of a standard Bitcoin signature. The digest (hash) of the source PSBT is not provided, so any tool that wants to verify this signature will need to have a copy of the original PSBT. (I see that as a critical feature, not a limitation). 2) In the output section, specifically, the last key/value pair of the last output of the transaction, I want to add a similar signature, again signed by one of the keys used in the signing process. This signature will cover all the bytes of the resulting (signed) PSBT up to that point. Because it is the last output of the output section, that signature will be the last few bytes of the PSBT file. By "appending" the signature in this way, it's easier to validate and create the signature, without blanking the signature area during digest step. ## Role-Based View The above additions can only be made by a PSBT processor in the Signer role. No-one else has the keys needed. As for the other PSBT roles: - Any tool that reads in a PSBT and finds a signature in the final output section can and should verify it: - check signature over a digest of the PSBT file up to the last X bytes - file must end at that point, with only the signature following it - also check the key used for signature is one of the input's keys - PSBT processors in the "combining" role, should preserve the signatures in the global section, accumulating them into the next PSBT. (Of course they should validate them, if they have the original PSBT on hand as well, but that's optional and could be done later in the flow.) The Combiner should always check a signed PSBT was not modified in transit via the signature in the final output section, and then strip it out of the combined PSBT. - At the end of the signing process, the Finalizer should check all the Signers have worked from the same PSBT file (assuming that's the flow expected), or the appropriate PSBT if it's a more complex case. If the Finalizer is working on a file directly from a Signer, then it can verify the signature in the output section as well. ## Open Questions For the message digest, I propose simple SHA256(SHA256(bytes of PSBT)). I'm not sure of the best way to serialize the signature, but to be consistent with the rest of the file, it should probably be DER-encoded and variable length. ## Next Steps I'd like to get two officially-assigned BIP-174 key numbers assigned for these two signatures, and then I will see that it gets added into Coldcard's firmware immediately. In time, other tools are welcome to take advantage of these checks. I will also write a BIP for this, and/or make an addition to BIP-174. I think with these changes, and assuming all the tools are verifying properly, we can shutdown undetectable MiTM changes to PSBT contents. --- 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] Modern Soft Fork Activation
On Fri, Jan 10, 2020 at 09:30:09PM +, Matt Corallo via bitcoin-dev wrote: > 1) a standard BIP 9 deployment with a one-year time horizon for > activation with 95% miner readiness, > 2) in the case that no activation occurs within a year, a six month > quieting period during which the community can analyze and discussion > the reasons for no activation and, > 3) in the case that it makes sense, a simple command-line/bitcoin.conf > parameter which was supported since the original deployment release > would enable users to opt into a BIP 8 deployment with a 24-month > time-horizon for flag-day activation (as well as a new Bitcoin Core > release enabling the flag universally). FWIW etc, but my perspective on this is that the way we want consensus changes in Bitcoin to work is: - decentralised: we want everyone to be able to participate, in designing/promoting/reviewing changes, without decision making power getting centralised amongst one group or another - technical: we want changes to be judged on their objective technical merits; politics and animal spirits and the like are fine, especially for working out what to prioritise, but they shouldn't be part of the final yes/no decision on consensus changes - improvements: changes might not make everyone better off, but we don't want changes to screw anyone over either -- pareto improvements in economics, "first, do no harm", etc. (if we get this right, there's no need to make compromises and bundle multiple flawed proposals so that everyone's an equal mix of happy and miserable) In particular, we don't want to misalign skills and responsibilities: it's fine for developers to judge if a proposal has bugs or technical problems, but we don't want want developers to have to decide if a proposal is "sufficiently popular" or "economically sound" and the like, for instance. Likewise we don't want to have miners or pool operators have to take responsibility for managing the whole economy, rather than just keeping their systems running. So the way I hope this will work out is: - investors, industry, people in general work out priorities for what's valuable to work on; this is an economic/policy/subjective question, that everyone can participate in, and everyone can act on -- either directly if they're developers who can work on proposals and implementations directly, or indirectly by persuading or paying other people to work on whatever's important - developers work on proposals, designing and implementing them to make (some subset of) bitcoin users better off, and to not make anyone worse off. - if someone discovers a good technical reason why a proposal does make people worse off, we don't try to keep pushing the proposal over the top of objections, but go back to the drawing board and try to fix the problems - once we've done as much development as we can, including setting up experimental testnet/signet style deployments for testing, we setup a deployment. the idea at this point is to make sure the live network upgrade works, and to retain the ability to abort if last minute problems come up. no doubt some review and testing will be left until the last minute and only done here, but *ideally* the focus should be on catching errors *well before* this point. - as a result, the activation strategy mostly needs to be about ensuring that the Bitcoin network stays in consensus, rather than checking popularity or voting -- the yes/no decisions should have mostly been made earlier already. so we have two strategies for locking in the upgrade: either 95%+ of hashpower signals that they've upgraded to software that will enforce the changes forever more, _or_ after a year of trying to deploy, we fail to find any technical problems, and then allow an additional 2.5 years to ensure all node software is upgraded to enforce the new rules before locking them in. The strategy behind the last point is that we need to establish that there's consensus amongst all of Bitcoin before we commit to a flag day, and if we've found some method to establish consensus on that, then we're done -- we've already got consensus, we don't need to put a blockchain protocol on top of that and signal that we've got consensus. (Activating via hashpower still needs signalling, because we need to coordinate on *when* sufficient hashpower has upgraded) This approach is obviously compatible with BIP-148 or BIP-91 style forced-signalling UASFs if some upgrade does need to be done urgently despite miner opposition; the forced signalling just needs to occur during the BIP-9 or BIP-8 phases, and no during the "quiet period". Probably the first period of BIP-8 after the quiet period would make the most sense. But without that, this approach seems very friendly for miners: even if they don't upgrade, they won't mine invalid blocks (unless the rules activate and someone else deliberately mine
