Re: [bitcoin-dev] Opinion on proof of stake in future

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

Good Afternoon,

Proof-of-stake sounds like an altcoin fork. There is no consideration that 
proof-of-work is insufficient or that it can be improved upon, only that it 
should be regulated. Imagine, you are a gold miner with larger hands so you 
start a mining race and mine plenty more than everyone. Pretty soon everybody 
is employing all their available resources just to keep up in the mining race 
since there are only so many carts instead of just to leisurely utilise surplus 
resources for an opportune find. Each block is a new gold mine. It is enough 
for everybody to use leisurely resources.

I have initiated conversation previously regarding a method to regulate mining, 
and believe whole heartedly it should happen. That is necessary for the future 
stability of Bitcoin as it is clear the rate of work cannot be allowed to 
increase at such a rate. If you search the bitcoin-dev archives you will find 
discussion there under my email as we search for a solution.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
and other projects

earn.com/willtech
linkedin.com/in/damianwilliamson


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this email if 
misdelivered.

From: bitcoin-dev  on behalf of 
Keagan McClelland via bitcoin-dev 
Sent: Tuesday, 11 May 2021 1:01 AM
To: Bitcoin Protocol Discussion ; Erik 
Aronesty 
Cc: SatoshiSingh 
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future

To reiterate some of the points here. My problem with proof of stake is twofold.

1. It requires permission of coin holders to enter into the system. This is not 
true of proof of work. You may even attempt (though not successfully) a proof 
of work with pencil and paper and submit the block from a regular laptop if you 
so choose. Whether this level of permissionlessness is necessary is up to 
individual risk tolerance etc. but it is definitely the default preference of 
Bitcoin.

2. Proof of stake must have a trusted means of timestamping to regulate 
overproduction of blocks. This introduction of trust is generally considered to 
be a nonstarter in Bitcoin. Proof of Work regulates this by making blocks 
fundamentally difficult to produce in the first place.

Like Jeremy, I’m always interested to learn about new attempts in consensus 
algorithms, but the bar to clear is very high and proof of stake to date has 
not proposed much less demonstrated a set of properties that is consistent with 
Bitcoins objectives.

Keagan

On Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:
personally, not speaking for anyone else, i think that proof-of-burn
has a much higher likelihood of being a) good enough security and b)
solving the nothing-at-stake problem

 the only issue i see with a quality PoB implementation is a robust
solution to the block-timing problem.

https://grisha.org/blog/2018/01/23/explaining-proof-of-work/

i do think there *could* be other low-energy solutions to verifiable
timing, just haven't seen one


On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
mailto: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

Re: [bitcoin-dev] Opinion on proof of stake in future

[Jeremy via bitcoin-dev]

re: 2, there's been some promising developments with Verifiable Delay
Functions that make me think that the block regulation problems are
solvable without requiring brute-force search proof of work. Are those
inapplicable for some reason?
___
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

[BitPLATES (Chris) via bitcoin-dev]

Thank you for your reply Tobias,

I don't think that the chicken-egg scenario is relevant, but please let me
explain why:

Wallet A = seed words (A) - add minimal funds as a canary/sacrificial wallet

Wallet B = seed words (B) - add minimal funds as a canary/sacrificial wallet

Wallet AB = seed words (A) + 'quantum' passphrase using seed words (B) -
add 1/2 of main funds

Wallet BA = seed words (B) + 'quantum' passphrase using seed words (A) -
add 1/2 of main funds

If the backup plate containing seed words (A) is compromised, then minimal
funds are taken.

If the backup plate containing seed words (B) is compromised, then minimal
funds are taken.

Both backup plates must remain geographically separated.

Furthermore, backup plate (A) could be held by a 1st party, whilst backup
plate (B) could be held by a 2nd party, as part of a 2 of 2 multi-factor
(or multi-sig) setup.

I hope this clarifies everything.

Regards,

Chris

On Sun, 9 May 2021, 23:54 Tobias Kaupat,  wrote:

> 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 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

personally, not speaking for anyone else, i think that proof-of-burn
has a much higher likelihood of being a) good enough security and b)
solving the nothing-at-stake problem

 the only issue i see with a quality PoB implementation is a robust
solution to the block-timing problem.

https://grisha.org/blog/2018/01/23/explaining-proof-of-work/

i do think there *could* be other low-energy solutions to verifiable
timing, just haven't seen one


On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
 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

Re: [bitcoin-dev] Opinion on proof of stake in future

[Keagan McClelland via bitcoin-dev]

To reiterate some of the points here. My problem with proof of stake is
twofold.

1. It requires permission of coin holders to enter into the system. This is
not true of proof of work. You may even attempt (though not successfully) a
proof of work with pencil and paper and submit the block from a regular
laptop if you so choose. Whether this level of permissionlessness is
necessary is up to individual risk tolerance etc. but it is definitely the
default preference of Bitcoin.

2. Proof of stake must have a trusted means of timestamping to regulate
overproduction of blocks. This introduction of trust is generally
considered to be a nonstarter in Bitcoin. Proof of Work regulates this by
making blocks fundamentally difficult to produce in the first place.

Like Jeremy, I’m always interested to learn about new attempts in consensus
algorithms, but the bar to clear is very high and proof of stake to date
has not proposed much less demonstrated a set of properties that is
consistent with Bitcoins objectives.

Keagan

On Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> personally, not speaking for anyone else, i think that proof-of-burn
> has a much higher likelihood of being a) good enough security and b)
> solving the nothing-at-stake problem
>
>  the only issue i see with a quality PoB implementation is a robust
> solution to the block-timing problem.
>
> https://grisha.org/blog/2018/01/23/explaining-proof-of-work/
>
> i do think there *could* be other low-energy solutions to verifiable
> timing, just haven't seen one
>
>
> On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
>  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