[bitcoin-dev] Base Size Increase and Segregated Witness with Discount Governors (SW-DGov) Hardfork

Evening all, The following BIP submission summarizes an idea that I've been tossing around for the last year. I understand that there may be nuances to SegWit and current consensus layer mechanisms that I may not fully understand, so please do not hesitate to shred the following text to pieces

Re: [bitcoin-dev] A different approach to define and understand softforks and hardforks

I'm not an expert to refute this classification, but would love to see those points addressed by those in the know, without resorting to ad hominem, even though I know it's really hard. thx, gm From: Johnson Lau via

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote: > BIP 9 provides a mechanism for having > miners coordinate softforks because they can make the upgrade process > smoother this way. But the same is not true of hardforks: miners are > essentially irrelevant to them, and

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wed, Apr 05, 2017 at 11:23:22PM -0400, David Vorick wrote: > I urge everybody to realize how difficult something like this is going to > be to pull off. We are literally talking about invalidating hardware (or at > least the optimized bits). It's only going to succeed if everybody is >

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote: > On that basis, I offer the following BIP draft for discussion. > This proposal does not prevent the attack in general, but only > inhibits covert forms of it which are incompatible with > improvements to the Bitcoin

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon wrote: > #bitcoin@freenode: > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > stuff. > > Are you *fucking* serious? Is this how you resolve all problems? I'm > taking you seriously and having

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

If the primary purpose of pow is to destroy value, then a masked proof of burn to an expanded address that assigns the private key holder the right to mine only in the next Nth block would be sufficient. Expanding the address space so that addresses can only be proven invalid only with the

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Thu, Apr 06, 2017 at 01:32:03AM +, Gregory Maxwell wrote: > On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon wrote: > > #bitcoin@freenode: > > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > > stuff. > > > > Are you *fucking* serious? Is

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

Just checking to see if I understand this optimization correctly. In order to find merkle roots in which the rightmost 32 bits are identical (i.e. partial hash collisions), we want to compute as many merkle root hashes as quickly as possible. The fastest way to do this is to take the top level

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > While I'm in favour of blocking covert usage of ASICBOOST, there's every > reason > to block non-covert usage of it as well. In a low margin business like > mining, > the advatange it

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wed, Apr 05, 2017 at 07:39:08PM -0700, Bram Cohen wrote: > On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev < > > While I'm in favour of blocking covert usage of ASICBOOST, there's every > > reason > > to block non-covert usage of it as well. In a low margin business like > > mining,

Re: [bitcoin-dev] Proof-of-Loss

Is this the same as proof of burn? On Apr 5, 2017 5:28 PM, "Mirelo via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > With the feedback on Proof-of-Loss (always privately to my email), I > realized the article was hard to understand for lacking: > > * A more explicit definition

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

I have a practical concern related to the amount of activation energy required to get something like this through. We are talking about implementing something that would remove tens to hundreds of millions of dollars of mining revenue for miners who have already gambled that this income would be

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

#bitcoin@freenode: 00:04gmaxwell| lol poon pretending that he isn't complicit in all this stuff. Are you *fucking* serious? Is this how you resolve all problems? I'm taking you seriously and having second thoughts and want to make public commitments to do the right thing without any

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

Ahh, sorry all for this public message. :( On Wed, Apr 05, 2017 at 05:39:00PM -0700, Joseph Poon wrote: > #bitcoin@freenode: > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > stuff. > > Are you *fucking* serious? Is this how you resolve all problems? I'm > taking

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

I personally appreciate the minimal changes, and often encourage development to be done this way - when it needs to be released quickly. But does this need to be released quickly? - maybe the proposal should be renamed segwit 8mb and be discussed solely in terms of block weights. - a high

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

> On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun wrote: > > > The concrete parameters chosen in the proposal are: each channel opening > transaction reserves 700-bytes within _each_ block in the chain until the > transaction has been closed. > > Why so? It seems you are

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

I'd appreciate the authors chiming in, but I read the PASDA differently: 1) If a transaction is mined with a certain bit set, it reserves 700 bytes for that particular block. 2) In that space, 2 transactions may happen: a) First, a transaction penalizing the "parent" transaction for fraud by

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

Hi Luke, Thank you for the review. Many of these points should definitely be addressed in the spec. Although extension blocks has working code, the spec is currently still in a draft state now and could really use all the feedback it can get. A few rules are still up in the air before we setup a

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

Hi Johnson, Really appreciate the comments. I know this idea is your baby. > so the authors don’t consider segwit as a consensus-layer solution to > increase transaction throughput, or not think segwit is safe? But > logically speaking if segwit is not safe, this BIP could only be > worse. OTOH,

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

A schism is just that: miners can't ameliorate a HF transition in the way they can censor transactions without permission. This is how miners became a convenient way to activate soft-forks. So while BIP9 can indicate the later censorship (a soft fork) in a way that nodes can follow (or not) a

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

This seems to be a serious security problem. Would it be possible to have a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger 3-6 months from release should be sufficient for enough of the economy to upgrade, given the severity of the issue. BIP 141 says that

[bitcoin-dev] Proof-of-Loss

With the feedback on Proof-of-Loss (always privately to my email), I realized the article was hard to understand for lacking: * A more explicit definition of transaction rights. * An overview of how the algorithm works. As an abstract could not contain all that, I wrote an introduction with

[bitcoin-dev] A different approach to define and understand softforks and hardforks

Softforks and hardforks are usually defined in terms of block validity (BIP99): making valid blocks invalid is a softfork, making invalid blocks valid is a hardfork, and SFs are usually considered as less disruptive as it is considered to be “opt-in”. However, as shown below this technical

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

Hi Y'all, Thanks to luke-jr and jl2012 for publishing your analysis of the xblocks proposal. I'd like to also present some analysis but instead focus on the professed LN safety enhancing scheme in the proposal. It's a bit underspecified, so I've taken the liberty of extrapolating a bit to fill in

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

Hi Greg, On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote: > Reverse engineering of a particular mining chip has demonstrated > conclusively that ASICBOOST has been implemented > in hardware. > > On that basis, I offer the following BIP draft for discussion. > This