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 *
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
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
essentia
> 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:
https://
crucial that we get these independently verified ASAP.
Daniele
Message: 2
Date: Thu, 6 Apr 2017 21:38:31 +
From: Gregory Maxwell
To: Bitcoin Dev
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on
the Bitcoin POW function
tcoin Dev
> Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on
> the Bitcoin POW function
> Message-ID:
> gmail.com>
> Content-Type: text/plain; charset=UTF-8
> On Wed, Apr 5, 2017 at 9:37 PM, Gregory Maxwell wrote:
> > each
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 with one chosen in
> 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
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. That's a very unwanted effect, and
> an
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 smal
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 in
> 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 (the
> 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
thu
> 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 b
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
> m
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?
__
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
> wrote:
> >
> >
> 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 repeat
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 optimisations, Compactblocks.
This is s
bitcoin-dev
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 Greg
Great work in discovering this!
> A month ago I was explaining the attack on Bitcoin
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 o
>
> 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 hav
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
https:
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 could be used to
block it in the network if it became a problem.
W
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 t
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 wit
Miners blocking SegWit due to ASICBOOST requirements also means they
would block future deployment of committed bloom filters.
On 2017-04-06 00:37, Gregory Maxwell via bitcoin-dev wrote:
A month ago I was explaining the attack on Bitcoin's SHA2 hashcash
which
is exploited by ASICBOOST and the
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 m
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 reve
On Wednesday, April 05, 2017 9:37:45 PM Gregory Maxwell via bitcoin-dev wrote:
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
Why not simply require the BIP-141 commi
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
> > 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
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
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 "
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
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
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,
>
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
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
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
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
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
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
#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
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
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
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
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
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
49 matches
Mail list logo
