Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Andrew Chow via bitcoin-dev]

I like this idea.

In terms of actual parameters, I propose that we base this Speedy Trial
off of BIP 8 with the following parameters:
* start height = 681408
* timeout height = 695520
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)

For the extended lockin period, I propose 14112 blocks, which is 7
retarget periods. Thus the earliest activation height will be 697536 and
the latest activation height will be 709632.

This will give us an approximate start time of May 1st 2021 and an
approximate timeout time of August 7th 2021, for a total activation
period of just over 3 months. The extended lockin period is the same
number of blocks as the activation period so that will also be just over
3 months, giving us the latest activation time of November 13th, 2021.
If miners activated as soon as possible, the earliest activation time
would be August 21st 2021.

Additionally, this timeline assumes a mid-April release of Bitcoin Core
0.21.1 containing these parameters. They could be changed to move up if
the expected release date were sooner.


Andrew Chow

On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> On the ##taproot-activation IRC channel, Russell O'Connor recently
> proposed a modification of the "Let's see what happens" activation
> proposal.[1] The idea received significant discussion and seemed
> acceptable to several people who could not previously agree on a
> proposal (although this doesn't necessarily make it their first
> choice).  The following is my attempt at a description.
>
> 1. Start soon: shortly after the release of software containing this
> proposed activation logic, nodes will begin counting blocks towards
> the 90% threshold required to lock in taproot.[2]
>
> 2. Stop soon: if the lockin threshold isn't reached within approximately
> three months, the activation attempt fails.  There is no mandatory
> activation and everyone is encouraged to try again using different
> activation parameters.
>
> 2. Delayed activation: in the happy occasion where the lockin threshold
> is reached, taproot is guaranteed to eventually activate---but not
> until approximately six months after signal tracking started.
>
> ## Example timeline
>
> (All dates approximate; see the section below about BIP9 vs BIP8.)
>
> - T+0: release of one or more full nodes with activation code
> - T+14: signal tracking begins
> - T+28: earliest possible lock in
> - T+104: locked in by this date or need to try a different activation process
> - T+194: activation (if lockin occurred)
>
> ## Analysis
>
> The goal of Speedy Trial is to allow a taproot activation attempt to
> either quickly succeed or quickly fail---without compromising safety in
> either case.  Details below:
>
> ### Mitigating the problems of early success
>
> New rules added in a soft fork need to be enforced by a large part of
> the economy or there's a risk that a long chain of blocks breaking the
> rules will be accepted by some users and rejected by others, causing a
> chain split that can result in large direct losses to transaction
> receivers and potentially even larger indirect losses to holders due to
> reduced confidence in the safety of the Bitcoin system.
>
> One step developers have taken in the past to ensure widespread adoption
> of new consensus rules is programming in a delay between the time software
> with those rules is expected to be released and when the software starts
> tracking which blocks signal for activation.  For example:
>
>  Soft fork| Release| Start  | Delta
>  -+++--
>  BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days
>  BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
>
>  Sources: BitcoinCore.org, 
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
>
> Speedy Trial replaces most of that upfront delay with a backend delay.
> No matter how fast taproot's activation threshold is reached by miners,
> there will be six months between the time signal tracking starts and when
> nodes will begin enforcing taproot's rules.  This gives the userbase even
> more time to upgrade than if we had used the most recently proposed start
> date for a BIP8 activation (~July 23rd).[2]
>
> ### Succeed, or fail fast
>
> The earlier version of this proposal was documented over 200 days ago[3]
> and taproot's underlying code was merged into Bitcoin Core over 140 days
> ago.[4]  If we had started Speedy Trial at the time taproot
> was merged (which is a bit unrealistic), we would've either be less than
> two months away from having taproot or we would have moved on to the
> next activation attempt over a month ago.
>
> Instead, we've debated at length and don't appear to be any closer to
> what I think is a widely acceptable solution than when the mailing list
> began discussing post-segwit activation schemes over a year ago.[5]  I
> think Speedy Trial is a way to generate 

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Jeremy via bitcoin-dev]

Thank you for resurfacing and collating this concept.

At this time I don't see major issues with this course of action and think
it represents not only a reasonable compromise between all different
perspectives, but also gives us an opportunity to learn more about less
'slow' yet safe consensus upgrades. In particular, I am very happy to see
the earliest activation concept included.

Best,

Jeremy
--
@JeremyRubin 



On Fri, Mar 5, 2021 at 7:44 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On the ##taproot-activation IRC channel, Russell O'Connor recently
> proposed a modification of the "Let's see what happens" activation
> proposal.[1] The idea received significant discussion and seemed
> acceptable to several people who could not previously agree on a
> proposal (although this doesn't necessarily make it their first
> choice).  The following is my attempt at a description.
>
> 1. Start soon: shortly after the release of software containing this
>proposed activation logic, nodes will begin counting blocks towards
>the 90% threshold required to lock in taproot.[2]
>
> 2. Stop soon: if the lockin threshold isn't reached within approximately
>three months, the activation attempt fails.  There is no mandatory
>activation and everyone is encouraged to try again using different
>activation parameters.
>
> 2. Delayed activation: in the happy occasion where the lockin threshold
>is reached, taproot is guaranteed to eventually activate---but not
>until approximately six months after signal tracking started.
>
> ## Example timeline
>
> (All dates approximate; see the section below about BIP9 vs BIP8.)
>
> - T+0: release of one or more full nodes with activation code
> - T+14: signal tracking begins
> - T+28: earliest possible lock in
> - T+104: locked in by this date or need to try a different activation
> process
> - T+194: activation (if lockin occurred)
>
> ## Analysis
>
> The goal of Speedy Trial is to allow a taproot activation attempt to
> either quickly succeed or quickly fail---without compromising safety in
> either case.  Details below:
>
> ### Mitigating the problems of early success
>
> New rules added in a soft fork need to be enforced by a large part of
> the economy or there's a risk that a long chain of blocks breaking the
> rules will be accepted by some users and rejected by others, causing a
> chain split that can result in large direct losses to transaction
> receivers and potentially even larger indirect losses to holders due to
> reduced confidence in the safety of the Bitcoin system.
>
> One step developers have taken in the past to ensure widespread adoption
> of new consensus rules is programming in a delay between the time software
> with those rules is expected to be released and when the software starts
> tracking which blocks signal for activation.  For example:
>
> Soft fork| Release| Start  | Delta
> -+++--
> BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days
> BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
>
> Sources: BitcoinCore.org,
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
>
> Speedy Trial replaces most of that upfront delay with a backend delay.
> No matter how fast taproot's activation threshold is reached by miners,
> there will be six months between the time signal tracking starts and when
> nodes will begin enforcing taproot's rules.  This gives the userbase even
> more time to upgrade than if we had used the most recently proposed start
> date for a BIP8 activation (~July 23rd).[2]
>
> ### Succeed, or fail fast
>
> The earlier version of this proposal was documented over 200 days ago[3]
> and taproot's underlying code was merged into Bitcoin Core over 140 days
> ago.[4]  If we had started Speedy Trial at the time taproot
> was merged (which is a bit unrealistic), we would've either be less than
> two months away from having taproot or we would have moved on to the
> next activation attempt over a month ago.
>
> Instead, we've debated at length and don't appear to be any closer to
> what I think is a widely acceptable solution than when the mailing list
> began discussing post-segwit activation schemes over a year ago.[5]  I
> think Speedy Trial is a way to generate fast progress that will either
> end the debate (for now, if activation is successful) or give us some
> actual data upon which to base future taproot activation proposals.
>
> Of course, for those who enjoy the debate, discussion can continue while
> waiting for the results of Speedy Trial.
>
> ### Base activation protocol
>
> The idea can be implemented on top of either Bitcoin Core's existing
> BIP9 code or its proposed BIP8 patchset.[6]
>
> - BIP9 uses two time-based[7] parameters, starttime and timeout.  Using
>   these values plus a time-based parameter for 

[bitcoin-dev] Taproot activation proposal "Speedy Trial"

[David A. Harding via bitcoin-dev]

On the ##taproot-activation IRC channel, Russell O'Connor recently
proposed a modification of the "Let's see what happens" activation
proposal.[1] The idea received significant discussion and seemed
acceptable to several people who could not previously agree on a
proposal (although this doesn't necessarily make it their first
choice).  The following is my attempt at a description.

1. Start soon: shortly after the release of software containing this
   proposed activation logic, nodes will begin counting blocks towards
   the 90% threshold required to lock in taproot.[2]

2. Stop soon: if the lockin threshold isn't reached within approximately
   three months, the activation attempt fails.  There is no mandatory
   activation and everyone is encouraged to try again using different
   activation parameters.
   
2. Delayed activation: in the happy occasion where the lockin threshold
   is reached, taproot is guaranteed to eventually activate---but not
   until approximately six months after signal tracking started.

## Example timeline

(All dates approximate; see the section below about BIP9 vs BIP8.)

- T+0: release of one or more full nodes with activation code
- T+14: signal tracking begins
- T+28: earliest possible lock in
- T+104: locked in by this date or need to try a different activation process
- T+194: activation (if lockin occurred)

## Analysis

The goal of Speedy Trial is to allow a taproot activation attempt to
either quickly succeed or quickly fail---without compromising safety in
either case.  Details below:

### Mitigating the problems of early success

New rules added in a soft fork need to be enforced by a large part of
the economy or there's a risk that a long chain of blocks breaking the
rules will be accepted by some users and rejected by others, causing a
chain split that can result in large direct losses to transaction
receivers and potentially even larger indirect losses to holders due to
reduced confidence in the safety of the Bitcoin system.

One step developers have taken in the past to ensure widespread adoption
of new consensus rules is programming in a delay between the time software
with those rules is expected to be released and when the software starts
tracking which blocks signal for activation.  For example:

Soft fork| Release| Start  | Delta 
-+++--
BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days 
BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days

Sources: BitcoinCore.org, 
https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc

Speedy Trial replaces most of that upfront delay with a backend delay.
No matter how fast taproot's activation threshold is reached by miners,
there will be six months between the time signal tracking starts and when
nodes will begin enforcing taproot's rules.  This gives the userbase even
more time to upgrade than if we had used the most recently proposed start
date for a BIP8 activation (~July 23rd).[2] 

### Succeed, or fail fast

The earlier version of this proposal was documented over 200 days ago[3]
and taproot's underlying code was merged into Bitcoin Core over 140 days
ago.[4]  If we had started Speedy Trial at the time taproot
was merged (which is a bit unrealistic), we would've either be less than
two months away from having taproot or we would have moved on to the
next activation attempt over a month ago.

Instead, we've debated at length and don't appear to be any closer to
what I think is a widely acceptable solution than when the mailing list
began discussing post-segwit activation schemes over a year ago.[5]  I
think Speedy Trial is a way to generate fast progress that will either
end the debate (for now, if activation is successful) or give us some
actual data upon which to base future taproot activation proposals.

Of course, for those who enjoy the debate, discussion can continue while
waiting for the results of Speedy Trial.

### Base activation protocol

The idea can be implemented on top of either Bitcoin Core's existing
BIP9 code or its proposed BIP8 patchset.[6]

- BIP9 uses two time-based[7] parameters, starttime and timeout.  Using
  these values plus a time-based parameter for the minimum activation
  delay would give three months for miners to activate taproot, but some
  of that time near the start or the end might not be usable due to
  signals only being measured in full retarget periods.  However, the
  six month time for users to upgrade their node would be not be
  affected by either slow or fast block production.
  
BIP9 is already part of Bitcoin Core and I think the changes being
proposed would be relatively small, resulting in a small patch that
could be easy to review.

- BIP8 uses two height-based parameters, startheight and timeoutheight.
  Using height values would ensure miners had a certain number of
  retarget periods (6) to lock in taproot and that there'd be a certain
  number of blocks 

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Eric Voskuil via bitcoin-dev]

FYI it’s generally considered bad form repost a private thread, especially one 
you initiate.

...

It’s typically more effective to generate some community support before 
actually submitting a BIP. Otherwise the process gets easily overwhelmed. This 
is likely why you aren’t getting a response. You can draft the BIP in your own 
repo and collect feedback from interested parties.

Posting a link to your research/code is a good start. I’d be happy to look at 
an overview of the central principles. I’m not a cryptographer. I write code, 
but I look at these things from economic principles. So far all I have to go on 
is that you go “much beyond” Chia. That’s not really anything.

e

> On Mar 5, 2021, at 14:03, Lonero Foundation  
> wrote:
> 
> 
> Hi, Eric. Chia's network is a bad example. They go after energy consumption 
> in the wrong way entirely. True, it requires a comparable cost of hardware. I 
> am trying to tackle cryptography in a way that goes much beyond that. Part of 
> what I am doing includes lowering invalided proofs while trying to get the 
> best of both worlds in regards to PoW and PoC. It is an efficiency issue to 
> the core. In regards to the mechanisms of how I will do that, I suggest you 
> look at the entire proposal which is why I am hoping the BIP team would be so 
> gracious as to allow me to draft it out on GitHub.
> 
> Best regards, Andrew
> 
>> On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil  wrote:
>> How is the argument against PoM only partially true?
>> 
>> I wrote this as soon as I saw Chia. Had two debates on Twitter with Brahm, 
>> before he blocked me. Two years later, after they finally realized I was 
>> correct, one of their PhDs contacted me and told me. Better to flesh this 
>> out early. They had already raised $20 and done their research, so he wasn’t 
>> exactly in a listening mode.
>> 
>> e
>> 
 On Mar 5, 2021, at 13:20, Lonero Foundation  
 wrote:
 
>>> 
>>> Actually I mentioned a proof of space and time hybrid which is much 
>>> different than staking. Sorry to draw for the confusion as PoC is more 
>>> commonly used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Work as 
>>> it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of being 
>>> both CPU compatible and memory-hard compatible. There are lots of benefits 
>>> outside of the realm of efficiency, and I already looked into numerous 
>>> fault tolerant designs as well and what others in the cryptography 
>>> community attempted to propose. The actual argument you have only against 
>>> this is the Proof of Memory fallacy, which is only partially true. Given 
>>> how the current hashing algorithm works, hard memory allocation wouldn't be 
>>> of much benefit given it is more optimized for CPU/ASIC specific mining. 
>>> I'm working towards a hybrid mechanism that fixes that. BTW: The way 
>>> Bitcoin currently stands in its cryptography still needs updating 
>>> regardless. If someone figures out NP hardness or the halting problem the 
>>> traditional rule of millions of years to break all of Bitcoin's 
>>> cryptography now comes down to minutes. Bitcoin is going to have to 
>>> eventually radically upgrade their cryptography and hashing algo in the 
>>> future regardless. I want to integrate some form of NP complexity in 
>>> regards to the hybrid cryptography I'm aiming to provide which includes a 
>>> polynomial time algorithm in the cryptography. More than likely the first 
>>> version of my BTC hard fork will be coded in a way where integrating such 
>>> complexity in the future only requires a soft fork or minor upgrade to its 
>>> chain.
>>> 
>>> In regards to the argument, "As a separate issue, proposing a hard fork in 
>>> the hashing algorithm will invalidate the enormous amount of capital 
>>> expenditure by mining entities and disincentivize future capital 
>>> expenditure into mining hardware that may compute these more "useful" 
>>> proofs of work."
>>> 
>>> A large portion of BTC is already mined through AWS servers and non-asic 
>>> specific hardware anyways. A majority of them would benefit from a hybrid 
>>> proof, and the fact that it is hybrid in that manner wouldn't 
>>> disenfranchise currently optimized mining entities as well.
>>> 
>>> There are other reasons why a cryptography upgrade like this is beneficial. 
>>> Theoretically one can argue BItcoin isn't fully decentralized. It is few 
>>> unsolved mathematical proofs away from being entirely broken. My goal 
>>> outside of efficiency is to build cryptography in a way that prevents such 
>>> an event from happening in the future, if it was to ever happen. I have 
>>> various research in regards to this area and work alot with distributed 
>>> computing. I believe if the BTC community likes such a proposal, I would 
>>> single handedly be able to build the cryptographic proof myself (though 
>>> would 

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Lonero Foundation via bitcoin-dev]

Hi, Eric. Chia's network is a bad example. They go after energy consumption
in the wrong way entirely. True, it requires a comparable cost of hardware.
I am trying to tackle cryptography in a way that goes much beyond that.
Part of what I am doing includes lowering invalided proofs while trying to
get the best of both worlds in regards to PoW and PoC. It is an efficiency
issue to the core. In regards to the mechanisms of how I will do that, I
suggest you look at the entire proposal which is why I am hoping the BIP
team would be so gracious as to allow me to draft it out on GitHub.

Best regards, Andrew

On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil  wrote:

> How is the argument against PoM only partially true?
>
> I wrote this as soon as I saw Chia. Had two debates on Twitter with Brahm,
> before he blocked me. Two years later, after they finally realized I was
> correct, one of their PhDs contacted me and told me. Better to flesh this
> out early. They had already raised $20 and done their research, so he
> wasn’t exactly in a listening mode.
>
> e
>
> On Mar 5, 2021, at 13:20, Lonero Foundation 
> wrote:
>
> 
> Actually I mentioned a proof of space and time hybrid which is much
> different than staking. Sorry to draw for the confusion as PoC is more
> commonly used then PoST.
> There is a way to make PoC cryptographically compatible w/ Proof of Work
> as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
> It has rarely been done though given the technological complexity of being
> both CPU compatible and memory-hard compatible. There are lots of benefits
> outside of the realm of efficiency, and I already looked into numerous
> fault tolerant designs as well and what others in the cryptography
> community attempted to propose. The actual argument you have only against
> this is the Proof of Memory fallacy, which is only partially true. Given
> how the current hashing algorithm works, hard memory allocation wouldn't be
> of much benefit given it is more optimized for CPU/ASIC specific mining.
> I'm working towards a hybrid mechanism that fixes that. BTW: The way
> Bitcoin currently stands in its cryptography still needs updating
> regardless. If someone figures out NP hardness or the halting problem the
> traditional rule of millions of years to break all of Bitcoin's
> cryptography now comes down to minutes. Bitcoin is going to have to
> eventually radically upgrade their cryptography and hashing algo in the
> future regardless. I want to integrate some form of NP complexity in
> regards to the hybrid cryptography I'm aiming to provide which includes a
> polynomial time algorithm in the cryptography. More than likely the first
> version of my BTC hard fork will be coded in a way where integrating such
> complexity in the future only requires a soft fork or minor upgrade to its
> chain.
>
> In regards to the argument, "As a separate issue, proposing a hard fork in
> the hashing algorithm will invalidate the enormous amount of capital
> expenditure by mining entities and disincentivize future capital
> expenditure into mining hardware that may compute these more "useful"
> proofs of work."
>
> A large portion of BTC is already mined through AWS servers and non-asic
> specific hardware anyways. A majority of them would benefit from a hybrid
> proof, and the fact that it is hybrid in that manner wouldn't
> disenfranchise currently optimized mining entities as well.
>
> There are other reasons why a cryptography upgrade like this is
> beneficial. Theoretically one can argue BItcoin isn't fully decentralized.
> It is few unsolved mathematical proofs away from being entirely broken. My
> goal outside of efficiency is to build cryptography in a way that prevents
> such an event from happening in the future, if it was to ever happen. I
> have various research in regards to this area and work alot with
> distributed computing. I believe if the BTC community likes such a
> proposal, I would single handedly be able to build the cryptographic proof
> myself (though would like as many open source contributors as I can get :)
>
> Anyways just something to consider. We are in the same space in regards to
> what warrants a shitcoin or the whole argument against staking.
>
> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl
>
> Best regards,  Andrew
>
> On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil  wrote:
>
>> Hi Andrew,
>>
>> Do you mean that you can reduce the cost of executing the cryptography at
>> a comparable level of security? If so this will only have the effect of
>> increasing the amount of it that is required to consume the same cost.
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
>>
>> You mentioned a staking hybrid in your original post.
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy
>>
>> This would be a change to dynamics - the economic forces at work. Staking
>> is not 

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Lonero Foundation via bitcoin-dev]

Actually I mentioned a proof of space and time hybrid which is much
different than staking. Sorry to draw for the confusion as PoC is more
commonly used then PoST.
There is a way to make PoC cryptographically compatible w/ Proof of Work as
it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
It has rarely been done though given the technological complexity of being
both CPU compatible and memory-hard compatible. There are lots of benefits
outside of the realm of efficiency, and I already looked into numerous
fault tolerant designs as well and what others in the cryptography
community attempted to propose. The actual argument you have only against
this is the Proof of Memory fallacy, which is only partially true. Given
how the current hashing algorithm works, hard memory allocation wouldn't be
of much benefit given it is more optimized for CPU/ASIC specific mining.
I'm working towards a hybrid mechanism that fixes that. BTW: The way
Bitcoin currently stands in its cryptography still needs updating
regardless. If someone figures out NP hardness or the halting problem the
traditional rule of millions of years to break all of Bitcoin's
cryptography now comes down to minutes. Bitcoin is going to have to
eventually radically upgrade their cryptography and hashing algo in the
future regardless. I want to integrate some form of NP complexity in
regards to the hybrid cryptography I'm aiming to provide which includes a
polynomial time algorithm in the cryptography. More than likely the first
version of my BTC hard fork will be coded in a way where integrating such
complexity in the future only requires a soft fork or minor upgrade to its
chain.

In regards to the argument, "As a separate issue, proposing a hard fork in
the hashing algorithm will invalidate the enormous amount of capital
expenditure by mining entities and disincentivize future capital
expenditure into mining hardware that may compute these more "useful"
proofs of work."

A large portion of BTC is already mined through AWS servers and non-asic
specific hardware anyways. A majority of them would benefit from a hybrid
proof, and the fact that it is hybrid in that manner wouldn't
disenfranchise currently optimized mining entities as well.

There are other reasons why a cryptography upgrade like this is beneficial.
Theoretically one can argue BItcoin isn't fully decentralized. It is few
unsolved mathematical proofs away from being entirely broken. My goal
outside of efficiency is to build cryptography in a way that prevents such
an event from happening in the future, if it was to ever happen. I have
various research in regards to this area and work alot with distributed
computing. I believe if the BTC community likes such a proposal, I would
single handedly be able to build the cryptographic proof myself (though
would like as many open source contributors as I can get :)

Anyways just something to consider. We are in the same space in regards to
what warrants a shitcoin or the whole argument against staking.
https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl

Best regards,  Andrew

On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <
keagan.mcclell...@gmail.com> wrote:

> It is important to understand that it is critical for the work to be
> "useless" in order for the security model to be the same. If the work was
> useful it provides an avenue for actors to have nothing at stake when
> submitting a proof of work, since the marginal cost of block construction
> will be lessened by the fact that the work was useful in a different
> context and therefore would have been done anyway. This actually degrades
> the security of the network in the process.
>
> As a separate issue, proposing a hard fork in the hashing algorithm will
> invalidate the enormous amount of capital expenditure by mining entities
> and disincentivize future capital expenditure into mining hardware that may
> compute these more "useful" proofs of work. This is because any change in
> the POW algorithm will be considered unstable and subject to change in the
> future. This puts the entire network at even more risk meaning that no
> entity is tying their own interests to that of the bitcoin network at
> large. It also puts the developers in a position where they can be bribed
> by entities with a vested interest in deciding what the new "useful" proof
> of work should be.
>
> All of these things make the Bitcoin network worse off.
>
> Keagan
>
> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Also in regards to my other email, I forgot to iterate that my
>> cryptography proposal helps behind the efficiency category but also tackles
>> problems such as NP-Completeness or Halting which is something the BTC
>> network could be vulnerable to in the future. For sake of simplicity, I do
>> want to do this BIP because it tackles lots of the issues in regards 

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Keagan McClelland via bitcoin-dev]

It is important to understand that it is critical for the work to be
"useless" in order for the security model to be the same. If the work was
useful it provides an avenue for actors to have nothing at stake when
submitting a proof of work, since the marginal cost of block construction
will be lessened by the fact that the work was useful in a different
context and therefore would have been done anyway. This actually degrades
the security of the network in the process.

As a separate issue, proposing a hard fork in the hashing algorithm will
invalidate the enormous amount of capital expenditure by mining entities
and disincentivize future capital expenditure into mining hardware that may
compute these more "useful" proofs of work. This is because any change in
the POW algorithm will be considered unstable and subject to change in the
future. This puts the entire network at even more risk meaning that no
entity is tying their own interests to that of the bitcoin network at
large. It also puts the developers in a position where they can be bribed
by entities with a vested interest in deciding what the new "useful" proof
of work should be.

All of these things make the Bitcoin network worse off.

Keagan

On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Also in regards to my other email, I forgot to iterate that my
> cryptography proposal helps behind the efficiency category but also tackles
> problems such as NP-Completeness or Halting which is something the BTC
> network could be vulnerable to in the future. For sake of simplicity, I do
> want to do this BIP because it tackles lots of the issues in regards to
> this manner and can provide useful insight to the community. If things such
> as bigger block height have been proposed as hard forks, I feel at the very
> least an upgrade regarding the hashing algorithm and cryptography does at
> least warrant some discussion. Anyways I hope I can send you my BIP, just
> let me know on the preferred format?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <
> loneroassociat...@gmail.com> wrote:
>
>> Hi, this isn't about the energy efficient argument in regards to
>> renewables or mining devices but a better cryptography layer to get the
>> most out of your hashing for validation. I do understand the arbitrariness
>> of it, but do want to still propose a document. Do I use the Media Wiki
>> format on GitHub and just attach it as my proposal?
>>
>> Best regards, Andrew
>>
>> On Fri, Mar 5, 2021, 10:07 AM Devrandom 
>> wrote:
>>
>>> Hi Ryan and Andrew,
>>>
>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>

   https://www.truthcoin.info/blog/pow-cheapest/
 "Nothing is Cheaper than Proof of Work"
 on | 04 Aug 2015


>>> Just to belabor this a bit, the paper demonstrates that the mining
>>> market will tend to expend resources equivalent to miner reward.  It does
>>> not prove that mining work has to expend *energy* as a primary cost.
>>>
>>> Some might argue that energy expenditure has negative externalities and
>>> that we should move to other resources.  I would argue that the negative
>>> externalities will go away soon because of the move to renewables, so the
>>> point is likely moot.
>>>
>>> ___
> 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] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Eric Voskuil via bitcoin-dev]

Hi Andrew,

Do you mean that you can reduce the cost of executing the cryptography at a 
comparable level of security? If so this will only have the effect of 
increasing the amount of it that is required to consume the same cost.

https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox

You mentioned a staking hybrid in your original post.

https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy

This would be a change to dynamics - the economic forces at work. Staking is 
not censorship resistant

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy

and is therefore what I refer to as cryptodynamically insecure.

https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles

As such it wouldn’t likely be considered as a contribution to Bitcoin. It might 
of course be useful in some other context.

https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition

But BIPs are proposals aimed at Bitcoin improvement.

https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP

Non-staking attempts to improve energy efficiency are either proof of work in 
disguise, such as proof of memory:

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy

or attempts to repurpose “wasteful” computing, such as by finding prime 
numbers, which does not imply a reduction in dedicated energy consumption.

https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle

Finally, waste and renewable energy approaches at “carbon” (vs energy) 
reduction must still consume the same in cost as the reward. In other words, 
the apparent benefit represents a temporary market shift, with advantage to 
first movers. The market will still consume what it consumes. If the hashing 
energy was free all reward consumption would shift to operations.

https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallacy

The motivation behind these attempts is naively understandable, but based on a 
false premise.

https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy

The one thing that reduces Bitcoin energy consumption is an increase in energy 
cost relative to block reward.

https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy

e

> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev 
>  wrote:
> 
> Hi, this isn't about the energy efficient argument in regards to renewables 
> or mining devices but a better cryptography layer to get the most out of your 
> hashing for validation. I do understand the arbitrariness of it, but do want 
> to still propose a document. Do I use the Media Wiki format on GitHub and 
> just attach it as my proposal?
> 
> Best regards, Andrew
> 
> On Fri, Mar 5, 2021, 10:07 AM Devrandom  wrote:
>> Hi Ryan and Andrew,
>> 
>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev 
>>  wrote:
>>> 
>>>   https://www.truthcoin.info/blog/pow-cheapest/
>>> "Nothing is Cheaper than Proof of Work"
>>> on | 04 Aug 2015
>> 
>> Just to belabor this a bit, the paper demonstrates that the mining market 
>> will tend to expend resources equivalent to miner reward.  It does not prove 
>> that mining work has to expend *energy* as a primary cost.
>> 
>> Some might argue that energy expenditure has negative externalities and that 
>> we should move to other resources.  I would argue that the negative 
>> externalities will go away soon because of the move to renewables, so the 
>> point is likely moot. 
> ___
> 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] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Lonero Foundation via bitcoin-dev]

Also in regards to my other email, I forgot to iterate that my cryptography
proposal helps behind the efficiency category but also tackles problems
such as NP-Completeness or Halting which is something the BTC network could
be vulnerable to in the future. For sake of simplicity, I do want to do
this BIP because it tackles lots of the issues in regards to this manner
and can provide useful insight to the community. If things such as bigger
block height have been proposed as hard forks, I feel at the very least an
upgrade regarding the hashing algorithm and cryptography does at least
warrant some discussion. Anyways I hope I can send you my BIP, just let me
know on the preferred format?

Best regards, Andrew

On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation 
wrote:

> Hi, this isn't about the energy efficient argument in regards to
> renewables or mining devices but a better cryptography layer to get the
> most out of your hashing for validation. I do understand the arbitrariness
> of it, but do want to still propose a document. Do I use the Media Wiki
> format on GitHub and just attach it as my proposal?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:07 AM Devrandom  wrote:
>
>> Hi Ryan and Andrew,
>>
>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>>   https://www.truthcoin.info/blog/pow-cheapest/
>>> "Nothing is Cheaper than Proof of Work"
>>> on | 04 Aug 2015
>>>
>>>
>> Just to belabor this a bit, the paper demonstrates that the mining market
>> will tend to expend resources equivalent to miner reward.  It does not
>> prove that mining work has to expend *energy* as a primary cost.
>>
>> Some might argue that energy expenditure has negative externalities and
>> that we should move to other resources.  I would argue that the negative
>> externalities will go away soon because of the move to renewables, so the
>> point is likely moot.
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Luke Dashjr via bitcoin-dev]

On Friday 05 March 2021 14:51:12 Ryan Grant via bitcoin-dev wrote:
> On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
>
>  wrote:
> > So that leads me to believe here that the folks who oppose LOT=true
> > primarily have an issue with forced signaling, which personally I
> > don't care about as much, not the idea of committing to a UASF from
> > the get go.
>
> The biggest disconnect is between two goals: modern soft-fork
> activation's "Don't (needlessly) lose hashpower to un-upgraded
> miners"; and UASF's must-signal strategy to prevent inaction.
>
>  
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547
>.html
>
> This question dives to the heart of Bitcoin's far-out future.
> Of two important principles, which principle is more important:
>
>   - to allow everyone (even miners) to operate on the contract they
> accepted when entering the system; or

There was never any such a contract. Even full nodes must upgrade in a 
softfork, or they lose their security and become comparable to light wallets.

>   - to protect against protocol sclerosis for the project as a whole?

What?

> Do miners have a higher obligation to evaluate upgrades than economic
> nodes implementing cold storage and infrequent spends?  If they do,
> then so far it has been implicit.  LOT=true would make that obligation
> explicit.

Miners either make valid blocks or they don't.
The only thing they "need" to evaluate is the market for their work.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Lonero Foundation via bitcoin-dev]

Hi, this isn't about the energy efficient argument in regards to renewables
or mining devices but a better cryptography layer to get the most out of
your hashing for validation. I do understand the arbitrariness of it, but
do want to still propose a document. Do I use the Media Wiki format on
GitHub and just attach it as my proposal?

Best regards, Andrew

On Fri, Mar 5, 2021, 10:07 AM Devrandom  wrote:

> Hi Ryan and Andrew,
>
> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>   https://www.truthcoin.info/blog/pow-cheapest/
>> "Nothing is Cheaper than Proof of Work"
>> on | 04 Aug 2015
>>
>>
> Just to belabor this a bit, the paper demonstrates that the mining market
> will tend to expend resources equivalent to miner reward.  It does not
> prove that mining work has to expend *energy* as a primary cost.
>
> Some might argue that energy expenditure has negative externalities and
> that we should move to other resources.  I would argue that the negative
> externalities will go away soon because of the move to renewables, so the
> point is likely moot.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Ryan Grant via bitcoin-dev]

On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
 wrote:
> So that leads me to believe here that the folks who oppose LOT=true
> primarily have an issue with forced signaling, which personally I
> don't care about as much, not the idea of committing to a UASF from
> the get go.

The biggest disconnect is between two goals: modern soft-fork
activation's "Don't (needlessly) lose hashpower to un-upgraded
miners"; and UASF's must-signal strategy to prevent inaction.

  
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html

This question dives to the heart of Bitcoin's far-out future.
Of two important principles, which principle is more important:

  - to allow everyone (even miners) to operate on the contract they
accepted when entering the system; or

  - to protect against protocol sclerosis for the project as a whole?

Do miners have a higher obligation to evaluate upgrades than economic
nodes implementing cold storage and infrequent spends?  If they do,
then so far it has been implicit.  LOT=true would make that obligation
explicit.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Ryan Grant via bitcoin-dev]

On Thu, Mar 4, 2021 at 8:48 PM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev  wrote:
> My concern was that the more complex scripts allow obfuscation of the Pay To 
> address

This is no different from options available in P2SH, or from the
obfuscation achieved by generating a new address for a payment.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Ryan Grant via bitcoin-dev]

On Fri, Mar 5, 2021 at 9:39 AM Lonero Foundation via bitcoin-dev
 wrote:
> Hello, I want to start a new BIP proposal aiming to tackle some of
> the energy efficiency issues w/ Bitcoin mining. Excuse my ignorance
> given this is my first time making a BIP proposal, but is there a
> specific format I need to follow?

Hi Andrew,

I would like to discourage you from writing a BIP on this topic, as
any such proposal is guaranteed to be rejected based on prior
discussions in the community.

Please update your priors with the following:

  https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
BIP: 2
Title: BIP process, revised

  https://www.truthcoin.info/blog/pow-cheapest/
"Nothing is Cheaper than Proof of Work"
on | 04 Aug 2015

Your topic brings up an interesting edge case, which is whether the
BIP repository is an open forum for all possible arguments that are
technically well constructed.  Obviously: no; but by what
non-arbitrary process do we decide?

I propose that the BIP Editor's role should include preserving signal
in the table of contents generated from our proposal repository, by
unilaterally rejecting - without any fuhrer comment - technically well
constructed proposals which are guaranteed to be rejected based on
prior discussions in the community, as spam.  I think this is already
how it works, but we haven't actually written down this part of the
norms.

Since censorship is always a concern, it would be appropriate to
maintain a moderation log of spam BIPs, so that observers could judge
whether the BIP Editor is misusing the BIP assignment process to
censor proposals with some merit.  Since one of the requirements for
submitting a BIP is to notify bitcoin-dev, the log is already
maintained.  Since bitcoin-dev is moderated, the moderators take on a
low level of responsibility for gauging spam proposals (and they are
pretty relaxed about it, since it is better to err on the side of
inclusion for new developers, except for obvious patent bombing).
Since the bitcoin-dev moderation log is public and anyone can
subscribe to it, protective transparency is again achieved.

  https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Lonero Foundation via bitcoin-dev]

Hello, I want to start a new BIP proposal aiming to tackle some of the
energy efficiency issues w/ Bitcoin mining. Excuse my ignorance given this
is my first time making a BIP proposal, but is there a specific format I
need to follow? Do I just make a draft on my personal GitHub or need to
attach the README?

Anyways my idea is centered around a hybrid mining integration w/ POW/PoST
for BTC's SHA-256 hash algorithm. The integration is actually a
cryptography proof. While I would prefer a soft fork integration, a vastly
different cryptography proof without affecting the current node integration
is less than feasible.

Anyways, I do want to submit my document explaining everything and how all
this would work. I am mostly a Quantum Engineer and Bioinformatics
consultant for a living, so I think what I can propose to an extent may be
of interest to some.

Best regards,
Andrew M. K. Nassief
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev