Re: [bitcoin-dev] Transcripts from coredev.tech Amsterdam 2019 meeting
A belated thanks (as always) for the great notes, Bryan. This is so valuable! Cory On Fri, Jun 7, 2019 at 11:07 AM Bryan Bishop via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > The following are some notes from the coredev.tech Amsterdam 2019 meeting. > Any mistakes are my probably my own. > > Here is a conversation about the code review process in Bitcoin Core: > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-code-review/ > > Here is a conversation with some of the maintainers about what problems > they are seeing: > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-maintainers/ > > Wallet re-architecture discussion > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-wallet-architecture/ > > Great consensus cleanup > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-great-consensus-cleanup/ > > SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY, > OP_SECURETHEBAG > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/ > > Taproot discussion > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-taproot/ > > Utreexo > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-utreexo/ > > assumeutxo > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-assumeutxo/ > > Hardware wallets and HWI > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-hardware-wallets/ > > bip151, p2p encryption and v2 message format > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-p2p-encryption/ > > Signet for bitcoin test networks > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/ > > Statechains overview > > http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/ > > Thanks, > - Bryan > https://heybryan.org/ > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: > So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason to > complicate the spec to ensure the digest is precommitted as part of the > opcode." Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if it's been spelled out anywhere); ie instead of constructing X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in ) and having the script be " OP_SECURETHEBAG" you calculate an ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL: Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0, amount, sequence) and calculate a signature sig = Schnorr(P,m) for some pubkey P, and make your script be " CHECKSIG". That loses the ability to commit to the number of inputs or restrict the nsequence of other inputs, and requires a bigger script (sig and P are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the same as far as I can tell. Both scripts are automatically satisfied when revealed (with the correct set of outputs), and don't need any additional witness data. If you wanted to construct "X" via script instead of hardcoding a value because it got you generalised covenants or whatever; I think you could get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much the same way you construct X, but you'd then need to turn that into a signature. You could do so by using pubkey P=G and nonce R=G, which means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash part is easy, multiplying it by 1 is easy, and to add 1 you can probably do something along the lines of: OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT (ie, take the last 4 bytes, increment it using 4-byte arithmetic, then cat the first 28 bytes and the result. There's overflow issues, but I think they can be worked around either by allowing you to choose different locktimes, or by more complicated script) Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
