[bitcoin-dev] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes
Hello everyone, We are currently writing a new specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme. We would be interested in getting your feedback with regard to the high-level design of the new spec: https://github.com/satoshilabs/slips/blob/master/slip-0039.md Please focus your attention on the section entitled "Master secret derivation functions", which proposes several different solutions. Note that there is a Design Rationale section at the very end of the document, which should answer some of the questions you may have. The document is a work in progress and we are aware that some technical details have not been fully specified. These will be completed once the high level design has been settled. Thanks, Andrew Kozlik TREZOR Team ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
It would be helpful to add the intermediate 'e' values computed to the first four test vectors. On Fri, Jul 6, 2018 at 2:08 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello everyone, > > Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures, > over the same curve as is currently used in ECDSA: > https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki > > It is simply a draft specification of the signature scheme itself. It > does not concern consensus rules, aggregation, or any other > integration into Bitcoin - those things are left for other proposals, > which can refer to this scheme if desirable. Standardizing the > signature scheme is a first step towards that, and as it may be useful > in other contexts to have a common Schnorr scheme available, it is its > own informational BIP. > > If accepted, we'll work on more production-ready reference > implementations and tests. > > This is joint work with several people listed in the document. > > Cheers, > > -- > Pieter > ___ > 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] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes
On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We are currently writing a new specification for splitting BIP-32 master > seeds into multiple mnemonics using Shamir's secret sharing scheme. We > would be interested in getting your feedback with regard to the > high-level design of the new spec: > https://github.com/satoshilabs/slips/blob/master/slip-0039.md > Please focus your attention on the section entitled "Master secret > derivation functions", which proposes several different solutions. Note > that there is a Design Rationale section at the very end of the > document, which should answer some of the questions you may have. The > document is a work in progress and we are aware that some technical > details have not been fully specified. These will be completed once the > high level design has been settled. > I and a number of companies & communities I am involved with are very interested in this. A challenge is that Shamir Secret Sharing has subtleties. To quote Greg Maxwell: > I think Shamir Secret Sharing (and a number of other things, RNGs for example), suffer from a property where they are just complex enough that people are excited to implement them often for little good reason, and then they are complex enough (or have few enough reasons to invest significant time) they implement them poorly”. Some questions for you: * What other teams or communities besides Trezor are committed to standardizing a Shamir Secret Sharing Scheme? I can say that the #RebootingWebOfTrust community (meeting again for the 7th time next week in Toronto https://rwot7.eventbrite.com) are very interested. * Where do you want to hold discussions on this? Do people object to having this discussion on this mailing list? Or should it be issues in SLIPS repo or on some other mailing list? * Presuming a successful split of secrets, I don’t know all the adversarial problems that are associated with recovery of a SSS. As this would be an interactive event, I presume an attacker can DOS a request to reassemble keys (so maybe some the of integrity of each share vs all is required). And of course there are the biggest problems: impersonation of a reassembly request and a MitM of a reassembly request. Are there other attacks? Are you trying to mitigate any of these? Two comments: * The Lightning Network community has added to their BIP32 mnemonics the ability to have a birthday in the seed, to make it easier to scan the blockchain for keys, as well as a byte with some way to know how to derive keys paths for it. I don’t seee a BOLT for this (it was mentioned in https://bitcoin.stackexchange.com/questions/74805/what-is-birthday-in-the-context-of-bip39-lightning-seed-generation) I would suggest that you also get some of their latest thoughts and incorporate them. * I worked with Chris Vickery while at Blockstrham on various possible ways to improve mnemonic word lists. I’m not suggesting that you necessarily go as far as we did to try to create a mnemonic that is iambic pentameter poetry (inspired by https://www.isi.edu/natural-language/mt/memorize-random-60.pdf), however, we did find sources for words that are concrete (for example table is more concrete than truth http://crr.ugent.be/papers/Brysbaert_Warriner_Kuperman_BRM_Concreteness_ratings.pdf ) or have strong emotional valence attachment (truth is more emotional than table), both of which make can words more memorable. I also found lists of words that are hard to pronounce unless you are English native, and eliminated them from my own list. Among the results of this was a new BIP-39 2048 word compatible word list filtered for memorability (concreteness & emotional valence) and suitability for iambic pentameter, which is located: https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/iambic-wordlist.json …which was created from the repo at https://github.com/ChristopherA/password_poem You can a number of other word lists that I’ve collected here https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/ If you want to replicate what we did with your own criteria, you may want to incorporate information from the CMU dictitionary http://www.speech.cs.cmu.edu/cgi-bin/cmudict, the top 5000 words https://github.com/ChristopherA/password_poem/blob/master/top5000.json, concrete word lists http://crr.ugent.be/papers/Concreteness_ratings_Brysbaert_et_al_BRM.txt and emotional words (valence) http://crr.ugent.be/archives/1003 — Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [bitcoin-core-dev] Bitcoin Core update notice
If the bugfix can be backported to earlier versions why is the hype/hysteria about "everybody" must immediately upgrade to 0.16.3 currently being spread on the forums/reddit? https://bitcointalk.org/index.php?topic=5034070.0 https://old.reddit.com/r/Bitcoin/comments/9hp90p/1775_nodes_out_of_9616_185_are_currently_on/ I don't see any effort to correct this misinformation either. Regards. On Tue, 2018-09-18 at 17:06 -0700, Pieter Wuille via bitcoin-core-dev wrote: > Hello all, > > Bitcoin Core 0.16.3 was just released with a fix for > CVE-2018-17144: > https://bitcoincore.org/en/2018/09/18/release-0.16.3/ > > We urge all network participants to upgrade to 0.16.3[*] as soon > as possible. > > [*] For those who build from source, the 0.14, 0.15, 0.16, 0.17, > and master branches on GitHub (https://github.com/bitcoin/bitcoin) > are fixed as well. > > -- > Pieter > ___ > bitcoin-core-dev mailing list > bitcoin-core-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal to replace full blockchain with recent history plus UTXO Set
I've been working on an idea that relieves full nodes of storing the entire blockchain. Open source software generally relies on the fact that "enough" people agree that it's secure. Bitcoin software works that way too. So if you understand enough to see that a UTXO set is valid at a certain block height, and there are enough other people who agree and that set is recognizable by humans, then we can use that UTXO set and ditch the blockchain that existed up to that point. It would save a lot of storage and make it a lot easier to run a full node. Have you reviewed the source code from which your wallets were compiled? At some point, we all trust third parties, but generally (at least among people who understand Bitcoin) they are large composite groups so that no small group or individual can profit from cheating. I look forward to answering any concerns and also to any offers of help. I used block 542324 of the Bitcoin blockchain to make a memorable experience using the game of life. I wrote a script for the open-source Game-of-Life software Golly and shared it in the paste at https://pastebin.com/k5Ssc0qk. It produces the image at https://imgur.com/a/rwIQuVz. If someone can tell me how to get a UTXO Set from the bitcoin client, I'll send them $50 of bitcoin. Then I could get the SHA256 hash of that set and try to make a recognizable checkpoint for the Bitcoin blockchain. If someone runs Golly and shares a video of the game playing out (into the apron-shaped image), I'll send them $50 of bitcoin too. In a few decades when the blockchain has grown to a few terabytes and the UTXO Set is still just a few gigabytes, I'd like to see more people start running full nodes without the hassle of a long wait and loads of storage space. That's what stops me from running one. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes
I see one benefit which i am looking for. I may not need to use all public keys in p2sh script instead i can use p2pkh and retrieve funds by using threshold number of keys..so in case i loose a public key along with private key i still may have other public key private key pairs to retrieve. For me it sounds interesting. I need to understand how it is going to get implemented in more detail. On Sat 22 Sep, 2018, 9:53 AM Christopher Allen via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> We are currently writing a new specification for splitting BIP-32 master >> seeds into multiple mnemonics using Shamir's secret sharing scheme. We >> would be interested in getting your feedback with regard to the >> high-level design of the new spec: >> https://github.com/satoshilabs/slips/blob/master/slip-0039.md >> Please focus your attention on the section entitled "Master secret >> derivation functions", which proposes several different solutions. Note >> that there is a Design Rationale section at the very end of the >> document, which should answer some of the questions you may have. The >> document is a work in progress and we are aware that some technical >> details have not been fully specified. These will be completed once the >> high level design has been settled. >> > > I and a number of companies & communities I am involved with are very > interested in this. > > A challenge is that Shamir Secret Sharing has subtleties. To quote Greg > Maxwell: > > > I think Shamir Secret Sharing (and a number of other things, RNGs for > example), suffer from a property where they are just complex enough that > people are excited to implement them often for little good reason, and then > they are complex enough (or have few enough reasons to invest significant > time) they implement them poorly”. > > Some questions for you: > > * What other teams or communities besides Trezor are committed to > standardizing a Shamir Secret Sharing Scheme? I can say that the > #RebootingWebOfTrust community (meeting again for the 7th time next week in > Toronto https://rwot7.eventbrite.com) are very interested. > > * Where do you want to hold discussions on this? Do people object to > having this discussion on this mailing list? Or should it be issues in > SLIPS repo or on some other mailing list? > > * Presuming a successful split of secrets, I don’t know all the > adversarial problems that are associated with recovery of a SSS. As this > would be an interactive event, I presume an attacker can DOS a request to > reassemble keys (so maybe some the of integrity of each share vs all is > required). And of course there are the biggest problems: impersonation of > a reassembly request and a MitM of a reassembly request. Are there other > attacks? Are you trying to mitigate any of these? > > Two comments: > > * The Lightning Network community has added to their BIP32 mnemonics the > ability to have a birthday in the seed, to make it easier to scan the > blockchain for keys, as well as a byte with some way to know how to derive > keys paths for it. I don’t seee a BOLT for this (it was mentioned in > https://bitcoin.stackexchange.com/questions/74805/what-is-birthday-in-the-context-of-bip39-lightning-seed-generation) > I would suggest that you also get some of their latest thoughts and > incorporate them. > > * I worked with Chris Vickery while at Blockstrham on various possible > ways to improve mnemonic word lists. I’m not suggesting that you > necessarily go as far as we did to try to create a mnemonic that is iambic > pentameter poetry (inspired by > https://www.isi.edu/natural-language/mt/memorize-random-60.pdf), however, > we did find sources for words that are concrete (for example table is more > concrete than truth > http://crr.ugent.be/papers/Brysbaert_Warriner_Kuperman_BRM_Concreteness_ratings.pdf > ) or have strong emotional valence attachment (truth is more emotional than > table), both of which make can words more memorable. I also found lists of > words that are hard to pronounce unless you are English native, and > eliminated them from my own list. > > Among the results of this was a new BIP-39 2048 word compatible word list > filtered for memorability (concreteness & emotional valence) and > suitability for iambic pentameter, which is located: > > > https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/iambic-wordlist.json > > > …which was created from the repo at > > https://github.com/ChristopherA/password_poem > > You can a number of other word lists that I’ve collected here > https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/ > > If you want to replicate what we did with your own criteria, you may want > to incorporate information from the CMU dictitionary > http://www.speech.cs.cmu.edu/cgi-bin/cmudict, the top 5000 words > https://github.com/Christop
Re: [bitcoin-dev] [bitcoin-core-dev] Bitcoin Core update notice
The backported versions have not been released yet. They are still going through the gitian build process. 0.16.3 was the first one to be released so that is the one that everyone is being recommended to upgrade to. Regardless, you should upgrade to a patched version, whether that is 0.14.3, 0.15.2, or 0.16.3. It is not misinformation that everybody must upgrade. On 09/21/2018 06:39 PM, gb via bitcoin-dev wrote: > If the bugfix can be backported to earlier versions why is the > hype/hysteria about "everybody" must immediately upgrade to 0.16.3 > currently being spread on the forums/reddit? > > https://bitcointalk.org/index.php?topic=5034070.0 > https://old.reddit.com/r/Bitcoin/comments/9hp90p/1775_nodes_out_of_9616_185_are_currently_on/ > > I don't see any effort to correct this misinformation either. > > Regards. > > On Tue, 2018-09-18 at 17:06 -0700, Pieter Wuille via bitcoin-core-dev > wrote: >> Hello all, >> >> Bitcoin Core 0.16.3 was just released with a fix for >> CVE-2018-17144: >> https://bitcoincore.org/en/2018/09/18/release-0.16.3/ >> >> We urge all network participants to upgrade to 0.16.3[*] as soon >> as possible. >> >> [*] For those who build from source, the 0.14, 0.15, 0.16, 0.17, >> and master branches on GitHub (https://github.com/bitcoin/bitcoin) >> are fixed as well. >> >> -- >> Pieter >> ___ >> bitcoin-core-dev mailing list >> bitcoin-core-...@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev > > ___ > 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] [bitcoin-core-dev] Bitcoin Core update notice
On Sat, Sep 22, 2018 at 4:25 AM gb via bitcoin-dev wrote: > > If the bugfix can be backported to earlier versions why is the Have been backported, not merely can be. > hype/hysteria about "everybody" must immediately upgrade to 0.16.3 > currently being spread on the forums/reddit? For instructions to be effective they need to be concise. Presenting people with a complex decision tree is not a way to maximize wellfare. The few parties that would be better off on some other version already know that they have some reason to not run the latest stable, and can do more research to find out their other options. The announcement posted on the bitcoin core site, I think is adequately clear but if you see an opportunity to improve it, please make suggestions. > I don't see any effort to correct this misinformation either. It's decent advice, not misinformation. You can run the fixed earlier versions but they have other issues, I wouldn't recommend anyone run older versions generally. Reasoning about risk is complicated. For example, when people were talking about only the crash component of the issue there were some people stating "I don't care if I go down, an unlikely delay in processing payments would not be a problem." But, in fact, a network exploitable crash is pretty dangerous: an attacker can carve up the network into partitions that will produce long valid forks and reorg against each other, enabling double-spends. The best one sentence advice available is to upgrade to the latest version. You'd probably have to get up to two page explanations discussing trade-offs before it makes sense to talk about running a fixed 0.14 or what not. Theymos' language is stronger than I would have chosen, but I think it's language that errors on the side of protecting people from harm. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
