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*"
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
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
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
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%,
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'
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
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
