[bitcoin-dev] Taproot updates
Hi all, I wanted to give an update on some of the changes we've made to the bip-schnorr/taproot/tapscript drafts following discussions on this list: * The original post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html and follow-ups * Using 2 or 4 byte indexes: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017046.html * 32-byte public keys: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html * Resource limits: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017306.html * P2SH support or not: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017297.html). We've made the following semantical changes to the proposal: * 32-byte public keys everywhere instead of 33-byte ones: dropping one byte that provably does not contribute to security, while remaining compatible with existing BIP32 and other key generation algorithms. * No more P2SH support: more efficient chain usage, no gratuitous fungibility loss from having 2 versions, no mode limited to 80-bit security for non-interactive multiuser constructs; however senders will need bech32 support to send to Taproot outputs. * 32-bit txin position and codesep position indexes instead of 16-bits ones. * Tagged hashes also in bip-schnorr: the signature and nonce generation now also use tagged hashes, rather than direct SHA256 (previously tagged hashes were only used in bip-taproot and bip-tapscript) * Dropping the 1 byte script limit and 201 non-push opcode limit: as no operations remain whose validation performance depends on the size of scripts or number of executed opcodes, these limits serve no purpose, but complicate creation of Scripts. * Increased the limit on the depth of Merkle trees from 32 to 128: a limit of 32 would necessitate suboptimal trees in some cases, but more than 128 levels are only necessary when dealing with leaves that have a chance of ~1/2^128 of being executed, which our security level treats as impossible anyway. See the updated documents: * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki In addition, a lot of clarifications and rationales were added. The reference implementation on https://github.com/sipa/bitcoin/commits/taproot was also updated to reflect these changes, has a cleaner commit history now, and improved tests (though those can still use a lot of work). Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
This is an excellent idea and I hope something like this happens. I've had the idea of using an intermediate name to make the transition easier, for example "Bitcoin address" becomes "Bitcoin invoice address" which after 10 years becomes "Bitcoin invoice" (or "Bitcoin invoice"). "Invoice" would also work well because Lightning uses the name invoice for the object which is used to receive payments. So it's easy to imagine that the GUI text input presented to users can be called "invoice" and users can put both kinds of invoices there leaving the wallet to easily figure out whether it makes an on-chain transaction or a Lightning Network transaction. Changing a commonly-used name like this could be very hard, but the gains in terms of privacy are immense. On 05/10/2019 22:57, Emil Engler via bitcoin-dev wrote: > Hello dear mailing list subscribers. > Before I'll explain my idea here, I need to define a term first > > 'address': > When I use the terms address, pubkey, etc., I mean the same: The Base58 > string > > Ok now let's get into it: > As you should know, sending bitcoins to an address more than once is a > very bad approach. > In my opinion the problem why so many people are still doing this is > because of the term 'address' which is used in lots of wallets, > implementations, BIP 21 and so on. It is a design issue. > With the term 'address' most people identify things that are fixed and > don't change really often (e.g postal address, IP address [depends on > provider], Domain, E-Mail address, ...). > Because of this most people compare bitcoin addresses with e-mail > addresses and use this address to send the recipient money multiple times. > > My suggestion would be to change the term address in wallets, the URI > scheme and so on to something of the following options by a > Informational/Process BIP: > > * Payment Password > * Transaction Password > * ... > > The guideline for the term should indicate that it is: > * temporary > * Something that identifies the recipient > > I've chosen 'password' because they can be used as a pseudonym to > identify a person. > This is already used in stuff like bank transfers where something like > the transaction id should be used as the purpose or at universities > there are student numbers. > The first is probably a better example because student numbers aren't > temporary. > > What do you think? Should I write a BIP for this or use another term? > Feedback is most welcome :) > > Greetings, > Emil Engler > > > ___ > 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] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout
On Thu, Oct 03, 2019 at 11:05:52AM -0400, Ethan Heilman wrote: > To avoid derailing the NO_INPUT conversation, I have changed the > subject to OP_CAT. > > Responding to: > """ > * `SIGHASH` flags attached to signatures are a misdesign, sadly > retained from the original BitCoin 0.1.0 Alpha for Windows design, on > par with: > [..] > * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends > [..] > """ > > OP_CAT is an extremely valuable op code. I understand why it was > removed as the situation at the time with scripts was dire. However > most of the protocols I've wanted to build on Bitcoin run into the > limitation that stack values can not be concatenated. For instance > TumbleBit would have far smaller transaction sizes if OP_CAT was > supported in Bitcoin. If it happens to me as a researcher it is > probably holding other people back as well. If I could wave a magic > wand and turn on one of the disabled op codes it would be OP_CAT. Of > course with the change that size of each concatenated value must be 64 > Bytes or less. > Just throwing my two cents in here - as others have noted, OP_CAT lets you create Merkle trees (allowing e.g. log-sized accountable threshold sigs, at least in a post-Schnorr future). It also allows manipulating signatures - e.g. forcing the revelation of discrete logs by requiring the user use the (1/2) point as a nonce (this starts with 11 zero bytes, which no other computationally accessible point does), or by requiring two sigs with the same nonce. It also lets you do proof-of-work-like computations on hashes or curvepoints; or enforce that EC points come from a hash and have no known discrete log. You can also switch on hashes, something currently impossible because of the 4-byte limitation on numeric opcodes. I don't have specific application of these in mind but definitely have cut off many lines of inquiry because they were impossible. You could build a crappy Lamport signature, though the key would be so big that you'd never do this pre-MAST :P. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-core-dev] Bitcoin Core 0.19.0 release candidate 1 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Binaries for bitcoin Core version 0.19.0rc1 are available from: https://bitcoincore.org/bin/bitcoin-core-0.19.0/test.rc1/ Source code can be found in git under the signed tag https://github.com/bitcoin/bitcoin/tree/v0.19.0rc1 This is a release candidate for a new major version release. Preliminary release notes for the release can be found here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.19.0-Release-Notes-Draft Release candidates are test versions for releases. When no critical problems are found, this release candidate will be tagged as 0.19.0. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAl2donUACgkQHkrtYphs 0l0bFQf/SDrPQa4uwlFXLUAsGXsyClhhtBfQHhV0F/4+c/3NSDlKs3zKeleFJb7K VHbpFE2QBtH7PO/r5CK7jZPfciqZDexs4KPvBFTthsVpIKKBS05Itb5leoILHq0R ykZbHYasPzN2+zG02izJ2CVB+ioWLpRXQ6RuDItVr3RS2qSwZvHdrX7vUMpsiV/H VboxPGjhTQY10C/Izra3ihbTc9UYp1BhkBtnIKk8152Wqew3rA5+jV5JxEjgywbt nFpL7kg5/Z6fv+viABplwf11dP6G3GReZspTxZ+NNgiVkJaEfJrW1dTwnkWFPKzL kbHl6qZ1uG6qAy4Vda6ZkCxl+O36GA== =duTj -END PGP SIGNATURE- ___ bitcoin-core-dev mailing list bitcoin-core-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev
