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

It is *not proof of stake.* when: a) burn happens regardless of whether you successfully mine. b) miner cannot know which tx are burns c) the majority of burns cannot be used for mining and are simply lost (poisson discovery distribution) d) burn involves real risk: *every bit as much at stake *

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

On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Ethically, this situation has some similarities to the DAO fork. > > > Much better analogy: > > 1. An ISV make software which makes use of an undocumented OS feature. > 2. That feature is no

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

Daniele Pinna, Can you please not forget to supply us more details on the claims made regarding the reverse engineering of the Asic chip? gmaxwell told me that back even in S7 chips its possible to set the SHA256 midstate/IV instead of just resetting it to the standard SHA256 IV. This

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

> Can you please not forget to supply us more details on the claims made > regarding the reverse engineering of the Asic chip? > > It is absolutely crucial that we get these independently verified ASAP. > Bitmain confirmed that their chips support ASICBOOST and it can be used for mining:

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

crucial that we get these independently verified ASAP. Daniele Message: 2 Date: Thu, 6 Apr 2017 21:38:31 + From: Gregory Maxwell <g...@xiph.org> To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] BIP proposal: Inhibit

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

@xiph.org> > To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> > Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on > the Bitcoin POW function > Message-ID: >

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

On Wed, Apr 5, 2017 at 9:37 PM, Gregory Maxwell wrote: > each block MUST either contain a BIP-141 segwit commitment or a > correct WTXID commitment with ID 0xaa21a9ef. It was just pointed out to me that the proposed ID (which I just selected to be above the segwit one) collides

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

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

On Thu, Apr 6, 2017 at 4:39 AM, Bram Cohen via bitcoin-dev wrote: > > Asicboost also has the problem that it isn't treating the hashing as a black > box, and thus has impacts on what gets mined. In particular it creates an > incentive to make blocks smaller.

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

Bryan, Interesting argument, but I think it is not an accurate comparison. People usually mean that, for example, say 2^80 of the original operations are needed rather than the intended 2^128 to find a collision. This could be the case in a broken algorithms such as a toy SHA variant with too

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

To me, all of these miss the main objection. If a miner found an optimization and kept it for themselves, that's their prerogative. But if that optimization also happens to directly discourage the growth and improvement of the protocol in many unforseen ways, and it also encourages the miner to

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

> We are not going to invalidate covert asicboost without a fight. And we are > working with a system that actively (and is demonstrably very effective at > doing it) resists changes which are contentious. This is definitely a > contentious change, because an important part of the community

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

> Ethically, this situation has some similarities to the DAO fork. Much better analogy: 1. An ISV make software which makes use of an undocumented OS feature. 2. That feature is no longer present in the next OS release. 3. ISV suffers losses because its software cannot work under new OS, and

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

> Ethically, this situation has some similarities to the DAO fork. There are no similarities. The DAO fork was against the principles of cryptocurrencies: a change of the ledger done in violation of pre-agreed rules. The whole point of cryptocurrency is to avoid shit like that. (E.g. a central

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

On 04/06/2017 03:24 AM, Jonathan Toomim via bitcoin-dev wrote: > Ethically, this situation has some similarities to the DAO fork. We have an > entity who closely examined the code, found an unintended characteristic of > that code, and made use of that characteristic in order to gain tens of >

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

On 04/05/2017 11:37 PM, Gregory Maxwell via bitcoin-dev wrote: > Reverse engineering of a particular mining chip has demonstrated > conclusively that ASICBOOST has been implemented in hardware. Do you plan to release details about this, or is it already documented somewhere?

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

I think you're misreading Luv. He's defending the idea of blocking covert ASICBOOST, not defending ASICBOOST. On Thu, Apr 6, 2017 at 11:16 AM Jorge Timón via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Apr 6, 2017 at 2:30 PM, Luv Khemani via bitcoin-dev >

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

> Agreed! There's no benefit to Bitcoin for having it - one way or the other > miners are going to destroy ~12BTC/block worth of energy. Meanwhile it > appears > to have lead to something like a year of stupid political bullshit based > on a > secret advantage - there's no reason to invite a

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

On Thu, Apr 6, 2017 at 2:30 PM, Luv Khemani via bitcoin-dev wrote: > > Just to add on to the ethical issue of blocking this. > > > If blocking the covert form of ASICBOOST is seen as unethical, then the same > can be said about libsecp256k1, various client

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

oun...@lists.linuxfoundation.org> on behalf of Luv Khemani via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> Sent: Thursday, April 6, 2017 8:02 PM To: Gregory Maxwell; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function Hi

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

Hi Jonathan, The proposal raised here does not deny miners the ability to use ASICBOOST. Miners can still use overt ASICBOOST by version bit fiddling and get the same power savings. In fact, overt ASICBOOST is much easier to implement than covert ASICBOOST, so I don't really understand what the

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

> > Another thing that could be done is increase the number of times SHA256 is > performed... but now we are really talking about altering the PoW > algorithm. Correct me if I'm wrong: The more number of times its > performed, the less any patent-able pre or post calculation > skipping/caching

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

On Thu, Apr 6, 2017 at 7:02 AM, Luv Khemani via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Could you elaborate on why you consider ASICBOOST to be an attack? Attack > here implies ill-intent by the practitioner towards the network as a > primary motivating factor. > > See

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

s.linuxfoundation.org> Sent: Thursday, April 6, 2017 5:37 AM To: Bitcoin Dev Subject: [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

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

On Thu, Apr 6, 2017 at 2:24 AM, Jonathan Toomim via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Ethically, this situation has some similarities to the DAO fork. We have > an entity who closely examined the code, found an unintended characteristic > of that code, and made use of

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

If this is the underlying reason why SegWit is being delayed... that is pretty deplorable. Probably too late now for bitcoin, but maybe it would be good to pre-mix the block header bits around before it even enters the SHA256 hash. Not sure if best to use a hardcoded map, or to make the map

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

Ethically, this situation has some similarities to the DAO fork. We have an entity who closely examined the code, found an unintended characteristic of that code, and made use of that characteristic in order to gain tens of millions of dollars. Now that developers are aware of it, they want to

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

On 04/05/2017 08:23 PM, David Vorick via bitcoin-dev wrote: > 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

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

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

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

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

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

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

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