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

Great catch, and a good proposal for a fix. Pushing the activation height out to allow existing hardware to enter obsolescence prior to activation may help reduce miner resistance. It may also avoid legal threats from those currently abusing. If miners still resist, the threat of an earlier a

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

> > One of the things going for us here is that Bitmain has been keeping ASICBOOST > > from their own customers - as far as we know they haven't been sharing it, and > > thus they're the only ones you can actually use it. > > > > So while we're pissing off Bitmain in disabling it, we wouldn't be af

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 > conclusiv

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

On Wed, Apr 05, 2017 at 11:11:53PM -0400, Erik Aronesty wrote: > 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 You're talking about proof-of-stake here. At best it's very difficult for such a "

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 av

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 private

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 of

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 giv

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] 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 consens

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 o

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 this how you resolve all p

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 second thoughts and want to ma

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 yo

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 evidence

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

On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev wrote: > 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

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: > The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while > incriminating a 32-bit nonce That should probably be "incrementing"... Cheers, aj ___ bitc

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

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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which is exploited by ASICBOOST and the various steps which could be used to block it in the network if it became a problem. While most discussion of ASICBOOST has focused on the overt method of implementing it, there also exists a

[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 exa

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] 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 describing it as a soft

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 p

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

On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote: > 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 ma

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 spend

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] 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] 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 bitcoin-dev

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 cann

[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 defin

[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 (I