Re: [bitcoin-dev] Proposal for an Informational BIP
Hi Chris, thanks for the clarification. It makes sense so far. About the "chicken - egg" problem: When you generate a BIP39 mnemonic "A" without password, you get a Seed "As" from which you derive your private key. Using the same mnemonic with a passphrase will give you a different seed "As*" with a different private and public key. Now your process must look like: - Generate mnemonic A without password (will never be used) - Generate mnemonic B* using words from A as password - Generate mnemonic A* using words from B* as password That's just an implementation detail but might have impact on the actual process, depending on the wallet you are using. Hope it's clear. Kind regards Tobias BitPLATES (Chris) schrieb am So., 9. Mai 2021, 10:29: > Hi Tobias, > > In answer to your questions... > > "Isn't your suggestion already covered by BIP39 since there is not > restriction in how you choose your passphrase?" > > - Correct, my idea is covered by BIP39, and therefore compatible with > BIP39... I see the 'quantum' passphrase as an optional 'soft fork' leading > towards a more restricted choice of characters, rather than the fuller, > less restrictive choice of characters. > > "It's up to any user to choose his password like you propose. I see your > proposal more like a way to choose my password rather than anything that > needs to be implemented somewhere." > > - Correct also, my proposal is for an Informational BIP to educate users > how to create a 'quantum' passphrase, which provides the same high degree > of protection (2048^23 combinations) as the original 1st layer mnemonic > seed words. Should their 24 seed words be compromised (or posted on the > internet), this extreme level of protection would make it impossible to > brute-force the wallet without the 'quantum' passphrase. > > "Don't I have plausible deniability already with any other password that I > keep in mind, since the seed without the password is already a valid > address?" > > - No, because an unrestricted passphrase may contain characters different > to those allowed by the 'quantum' passphrase. Memorisation of the 2nd layer > passphrase is very dangerous, whereby, an unfortunate accident could leave > your family without access to their inherence. The 'quantum' passphrase > encourages the use of multiple metal backup storage devices, but anything > more that A-Z (upper case only), would not be disguised as a 24 word seed. > Therefore, discovery of a backup device with the extra, unrestricted > characters that don't also open a (sacrificial) wallet, will be recognised > as a 2nd layer passphrase... This is when the $5 wrench is brought to the > table to extract the 1st layer seed words. > > "One issue might be, that the passphrase is part of the mnemonic. A > hardware wallet needs the passphrase to generate the complete mnemonic > (changing the password does change the resulting seed). Thus you get a > chicken-egg problem, at least for some implementations. Probably you could > use the restore feature to work around this - but it's one step more that > should be mentioned." > > - I'm not sure that I fully understand this last paragraph of your email, > but just to be clear, the 'quantum' passphrase is made from the 24 seed > words of a separate wallet. This is essentially the 2nd layer (or 2nd > signing key) to add to the 1st layer (or 1st signing key) required to > complete the full mnemonic, which then provides access to the > passphrase-protected wallet. > > eg. The 1st Bitcoin wallet is protected by a 'quantum' passphrase, > containing the seed words of the 2nd Bitcoin wallet; inversely, the 2nd > Bitcoin wallet is protected by a 'quantum' passphrase, containing the seed > words of the 1st Bitcoin wallet. > > Thank you for your thoughts. > > Regards, > > Chris > > > On Sun, 9 May 2021, 08:24 Tobias Kaupat, wrote: > >> Hello Chris, >> Isn't your suggestion already covered by BIP39 since there is not >> restriction in how you choose your passphrase? >> >> It's up to any user to choose his password like you propose. I see your >> proposal more like a way to choose my password rather than anything that >> needs to be implemented somewhere. >> >> Don't I have plausible deniability already with any other password that I >> keep in mind, since the seed without the password is already a valid >> address? >> >> One issue might be, that the passphrase is part of the mnemonic. A >> hardware wallet needs the passphrase to generate the complete mnemonic >> (changing the password does change the resulting seed). Thus you get a >> chicken-egg problem, at least for some implementations. Probably you could >> use the restore feature to work around this - but it's one step more that >> should be mentioned. >> >> >> Kind regards >> Tobias >> >> >> >> >> BitPLATES® (Chris) via bitcoin-dev >> schrieb am Sa., 8. Mai 2021, 17:21: >> >>> Hi, >>> >>> I'd like to submit an idea for review, as a potential informational BIP >>> (Bitcoin Improvement
Re: [bitcoin-dev] Opinion on proof of stake in future
Proof of stake is permissioned by coins, an internal, permissioned, and already owned resource. You cannot gain tokens without someone choosing to give up those coins - a form of permission. Permission can also be thought of as an infinite barrier to entry. PoW forces giving up control through both permissionless to enter mining via EXTERNAL permissionless resources and unforgeable costliness for the miners. Without unforgeable costliness there's no reason to ever give up control in PoS. In fact, staking quite literally incentivizes keeping control by rewarding those in control with more coins and control in perpetuity at no cost - the incentives on PoS are completely backwards from decentralizing control. Since no mechanism forces control to be permissionlessly distributed to others, parties in control cannot be considered independent parties nor can control be considered decentralized. PoS solves nothing that's relevant to permissionless decentralized networks. > In the following years we'll be seeing proof of stake being implemented It has been implemented since 2014 but it doesn't meet criteria for a permissionless network. There's nothing new about implementing permissioned networks. You could try to replace proof of work with proof of bitcoin burn (not well studied) on blockchains other than Bitcoin, but there's no known replacement for proof of work for Bitcoin right now. PoS has been considered and studied since then many times since then and dismissed repeatedly for irrelevance to decentralized permissionless technology, examples: - https://nakamotoinstitute.org/research/on-stake-and-consensus/ - https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca - https://www.truthcoin.info/blog/pow-cheapest/ - https://hugonguyen.medium.com/work-is-timeless-stake-is-not-554c4450ce18 - https://arxiv.org/abs/1809.06528 On Sat, May 8, 2021 at 10:49 AM Karl via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What is more important; >> Bitcoin mining introduces the first free-market demand for the cheapest >> energy source. > > > This is a really great idea but I think access to technologically advanced > hardware is a stronger component than energy here. > > Making open community chip fabs might change that. Then anybody could get > on the bandwagon. But right now the hardware barrier keeps the common > person out. > > If you can build a chip fab, you may also be able to build a powerplant. > Not many others can do that to compete with you. The energy economy still > has more supply than competition or renewable energy would quickly > outcompete nonrenewable as the price dropped. > > ___ > 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] Opinion on proof of stake in future
According to this paper: https://www.cs.umd.edu/projects/coinscope/coinscope.pdf PoW is also only resilient to 1/3rd of the network. On Sat, 8 May 2021 at 14:46, Eric Martindale via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Mr. Singh, > > Proof of Stake is only resilient to ⅓ of the network demonstrating a Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold. You can explore prior research here: https://download.wpsoftware.net/bitcoin/pos.pdf > > Independent of the security thresholds, Proof of Stake requires other trade-offs which are incompatible with Bitcoin's objective (to be a trustless digital cash) — specifically the famous "security vs. liveness" guarantee. Digital cash is not useful if it must be globally halted to ensure its security, and Proof of Work squarely addresses this concern. > > Above and beyond any security consideration, Proof of Stake incentivizes the accumulation of wealth within a small set of actors, which is undesirable for the long-term health of any such network. If we are to free humanity from the tyranny of the State, we must do so by protecting the rights of every individual to hold and preserve their own value, without trusting any third party. Entrusting the health of the network to the "economic elite" is the paramount evil with respect to Bitcoin's objectives, nevermind that Proof of Work relies on energy expenditure to provide its security. > > Sincerely, > > Eric Martindale, relentless maker. > Founder & CEO, Fabric, Inc. > +1 (919) 374-2020 > > > On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Hello list, >> >> I am a lurker here and like many of you I worry about the energy usage of bitcoin mining. I understand a lot mining happens with renewable resources but the impact is still high. >> >> I want to get your opinion on implementing proof of stake for bitcoin mining in future. For now, proof of stake is still untested and not battle tested like proof of work. Though someday it will be. >> >> In the following years we'll be seeing proof of stake being implemented. Smaller networks can test PoS which is a luxury bitcoin can't afford. Here's how I see this the possibilities: >> >> 1 - Proof of stake isn't a good enough security mechanism >> 2 - Proof of state is a good security mechanism and works as intended >> >> IF PoS turns out to be good after battle testing, would you consider implementing it for Bitcoin? I understand this would invoke a lot of controversies and a hard fork that no one likes. But its important enough to consider a hard fork. What are your opinions provided PoS does work? >> >> Love from India. >> ___ >> 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
On Sun, May 9, 2021, 6:21 AM R E Broadley < rebroad+linuxfoundation@gmail.com> wrote: > On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev > wrote: > > Bitcoin would get better mainstream public reputation if the block > reward were reduced to reduce mining. This would quickly and easily reduce > energy expenditure. > > You're in luck then, as the block reward is being reduced by 50%, every 4 > years. > I'm aware of that and it is why I mentioned "block reward termination" in the next paragraph... did you receive the rest of my message? Or why do you say this? > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Opinion on proof of stake in future
On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev wrote: > Bitcoin would get better mainstream public reputation if the block reward > were reduced to reduce mining. This would quickly and easily reduce energy > expenditure. You're in luck then, as the block reward is being reduced by 50%, every 4 years. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for an Informational BIP
Hi Tobias, In answer to your questions... "Isn't your suggestion already covered by BIP39 since there is not restriction in how you choose your passphrase?" - Correct, my idea is covered by BIP39, and therefore compatible with BIP39... I see the 'quantum' passphrase as an optional 'soft fork' leading towards a more restricted choice of characters, rather than the fuller, less restrictive choice of characters. "It's up to any user to choose his password like you propose. I see your proposal more like a way to choose my password rather than anything that needs to be implemented somewhere." - Correct also, my proposal is for an Informational BIP to educate users how to create a 'quantum' passphrase, which provides the same high degree of protection (2048^23 combinations) as the original 1st layer mnemonic seed words. Should their 24 seed words be compromised (or posted on the internet), this extreme level of protection would make it impossible to brute-force the wallet without the 'quantum' passphrase. "Don't I have plausible deniability already with any other password that I keep in mind, since the seed without the password is already a valid address?" - No, because an unrestricted passphrase may contain characters different to those allowed by the 'quantum' passphrase. Memorisation of the 2nd layer passphrase is very dangerous, whereby, an unfortunate accident could leave your family without access to their inherence. The 'quantum' passphrase encourages the use of multiple metal backup storage devices, but anything more that A-Z (upper case only), would not be disguised as a 24 word seed. Therefore, discovery of a backup device with the extra, unrestricted characters that don't also open a (sacrificial) wallet, will be recognised as a 2nd layer passphrase... This is when the $5 wrench is brought to the table to extract the 1st layer seed words. "One issue might be, that the passphrase is part of the mnemonic. A hardware wallet needs the passphrase to generate the complete mnemonic (changing the password does change the resulting seed). Thus you get a chicken-egg problem, at least for some implementations. Probably you could use the restore feature to work around this - but it's one step more that should be mentioned." - I'm not sure that I fully understand this last paragraph of your email, but just to be clear, the 'quantum' passphrase is made from the 24 seed words of a separate wallet. This is essentially the 2nd layer (or 2nd signing key) to add to the 1st layer (or 1st signing key) required to complete the full mnemonic, which then provides access to the passphrase-protected wallet. eg. The 1st Bitcoin wallet is protected by a 'quantum' passphrase, containing the seed words of the 2nd Bitcoin wallet; inversely, the 2nd Bitcoin wallet is protected by a 'quantum' passphrase, containing the seed words of the 1st Bitcoin wallet. Thank you for your thoughts. Regards, Chris On Sun, 9 May 2021, 08:24 Tobias Kaupat, wrote: > Hello Chris, > Isn't your suggestion already covered by BIP39 since there is not > restriction in how you choose your passphrase? > > It's up to any user to choose his password like you propose. I see your > proposal more like a way to choose my password rather than anything that > needs to be implemented somewhere. > > Don't I have plausible deniability already with any other password that I > keep in mind, since the seed without the password is already a valid > address? > > One issue might be, that the passphrase is part of the mnemonic. A > hardware wallet needs the passphrase to generate the complete mnemonic > (changing the password does change the resulting seed). Thus you get a > chicken-egg problem, at least for some implementations. Probably you could > use the restore feature to work around this - but it's one step more that > should be mentioned. > > > Kind regards > Tobias > > > > > BitPLATES® (Chris) via bitcoin-dev > schrieb am Sa., 8. Mai 2021, 17:21: > >> Hi, >> >> I'd like to submit an idea for review, as a potential informational BIP >> (Bitcoin Improvement Proposal), describing an optional method of producing >> a BIP39 passphrase, using only BIP39 'mnemonic' seed words. >> >> The idea specifically refers to a method of introducing two-factor >> authentication, to protect a Bitcoin wallet using only 24 seed words, and >> therefore, providing plausible deniability about the existence of this >> separate 2nd layer passphrase. >> >> I've suggested the name 'quantum' passphrase to be used casually as a >> unique identifier. >> >> The data stored within a 'quantum' passphrase, is simultaneously the >> minimum required data for reproducing a BIP39-compatible 24-word seed >> mnemonic... hence, the name 'quantum' seems fitting, to reflect the >> multiple simultaneous states of data. >> >> Abstract... >> >> This improvement proposal describes the use of twenty four, newly >> generated BIP39 seed words, to produce a '25th-word' BIP39-compatible >> 'quantum'
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Antoine, Thank you for the disclosure. > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly signal > RBF. For what it's worth, Revault isn't vulnerable as all transactions signal RBF and there is no way to sneak a non-signaling competing transaction (as long as the CSV isn't matured yet). Thanks, Antoine (the other one)___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for an Informational BIP
Hello Chris, Isn't your suggestion already covered by BIP39 since there is not restriction in how you choose your passphrase? It's up to any user to choose his password like you propose. I see your proposal more like a way to choose my password rather than anything that needs to be implemented somewhere. Don't I have plausible deniability already with any other password that I keep in mind, since the seed without the password is already a valid address? One issue might be, that the passphrase is part of the mnemonic. A hardware wallet needs the passphrase to generate the complete mnemonic (changing the password does change the resulting seed). Thus you get a chicken-egg problem, at least for some implementations. Probably you could use the restore feature to work around this - but it's one step more that should be mentioned. Kind regards Tobias BitPLATES® (Chris) via bitcoin-dev schrieb am Sa., 8. Mai 2021, 17:21: > Hi, > > I'd like to submit an idea for review, as a potential informational BIP > (Bitcoin Improvement Proposal), describing an optional method of producing > a BIP39 passphrase, using only BIP39 'mnemonic' seed words. > > The idea specifically refers to a method of introducing two-factor > authentication, to protect a Bitcoin wallet using only 24 seed words, and > therefore, providing plausible deniability about the existence of this > separate 2nd layer passphrase. > > I've suggested the name 'quantum' passphrase to be used casually as a > unique identifier. > > The data stored within a 'quantum' passphrase, is simultaneously the > minimum required data for reproducing a BIP39-compatible 24-word seed > mnemonic... hence, the name 'quantum' seems fitting, to reflect the > multiple simultaneous states of data. > > Abstract... > > This improvement proposal describes the use of twenty four, newly > generated BIP39 seed words, to produce a '25th-word' BIP39-compatible > 'quantum' passphrase. > > Two-factor authentication (2FA) or (2 of 2 multi-signature) can be > implemented with a two-wallet setup: > > The 1st Bitcoin wallet is protected by the seed words of the 2nd Bitcoin > wallet; inversely, the 2nd Bitcoin wallet is protected by the seed words of > the 1st Bitcoin wallet. > > The 'quantum' passphrase offers an exponential increase in the level of > protection, as that offered by the original BIP39 mnemonic seed words > (≈2048^23 possible combinations). > > ie. A Bitcoin wallet with a 2nd layer 'quantum'passphrase is protected by > 2048^23 to the power of 2048^23 possible combinations. > > With existing computer capabilities, this level of protection is far > greater than required; however, this does provide a sufficient level of > protection for each separate layer of a two-factor Bitcoin wallet, should > any one layer be accidentally exposed. > > This method of passphrase generation, consists of two parts: > > 1st - generating the BIP39 mnemonic seed words, using a BIP39-compatible > hardware wallet. > > 2nd - Converting these seed words into the 'quantum' passphrase, following > four simple rules, which most importantly, do not destroy the integrity of > the initial data. > > Motivation... > > The well established practice of preserving up to 24 seed words for the > purpose of reproduction of a Bitcoin wallet, suffers from a major flaw... > Exposure of these mnemonic seed words can cause catastrophic loss of funds > without adequate multi-factor protection. > > Whilst it is recognised that a number of multi-factor solutions are > available (including the standard BIP39 passphrase, and hardware wallet > multi-signature functionality), this proposal aims to provide an extremely > safe and secure 'low-tech' option, that requires minimal (non-destructive) > adjustments to the seed words. > > Furthermore, the 'quantum' passphrase offers a number advantages over the > existing methods of multi-factor protection: > > Firstly, this method of creating a passphrase leaves no evidence of its > existence on any backup devices, providing plausible deniability in case of > coercion. > > This is because the passphrase is easily created from a genuine 24 seed > word mnemonic; therefore, the physical backup of the passphrase can be > disguised as a simple Bitcoin wallet on a metal backup plate. > > It presents a way of discouraging user-created words or sentences (also > known as 'brain-wallets'), which often provide a drastically reduced level > of passphrase security, unbeknown to many users. > > The large amount of data required to produce a 'quantum' passphrase (up to > 96 characters long), encourages the physical backup of the passphrase. > > Furthermore, the use of BIP39-only words provides a higher degree of > standardization, which can help to avoid potential mistakes made by > creating unnecessarily complicated combinations of letters, numbers and > symbols. Increased complication (disorderly, and non-human-friendly), does > not always equal increased complexity (orderly, and more
