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. Daniele Message: 2 > Date: Thu, 6 Apr 2017 21:38:31 + > From: Gregory Maxwell >

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote: > > How do you deal with validity rules changing based on block height? I expected that one :). Just like the 100 blocks coinbase rule, changes by softforks need to be added as metadata to the transaction-index, but this is not yet in

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017, at 02:32, Gregory Maxwell wrote: > Perhaps a simple question would help: > > What is the minimal amount of space your system requires to take a new > block received from the P2P network and verifying that all its spends > were valid spends of existing coins unspent coins

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017 at 12:48 AM, Tomas wrote: > Bitcrust separates script validation (base load, when transaction come > in) from order validation (peak load, when blocks come in). How do you deal with validity rules changing based on block height? > For script validation it

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Hi Eric, Thanks, but I get the impression that the similarity is rather superficial. To address your points: > (1) higher than necessary storage space requirement due to storing the > indexing data required for correlate the spends, and Hmm. No. Spends are simply scanned in the spend-tree

Re: [bitcoin-dev] Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST

> "... put a damper on advancing the development of more efficient mining > hardware, which is once again desirable to users as it makes the transaction > ordering more future proof." Run on sentence sorry. I meant to say that development of more efficient/mature mining hardware sooner is

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/06/2017 03:12 PM, Tomas via bitcoin-dev wrote: Hi Tomas, > I have been working on a bitcoin implementation that uses a > different approach to indexing for verifying the order of > transactions. Instead of using an index of unspent outputs,

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

Not sure to get how you are answering the question > If the original blockchain hard-forks to re-adjust the difficulty, then it will just represent an alt-coin having 5% of Bitcoin community, and it can't affect Bitcoin (the segwit2mb fork). destroys the whole thing Because if the nodes don't

[bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

After some thought I managed to simplify the original uaversionbits proposal introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by the timeout. This seems to be the simplest form combining optional flag day activation with BIP9. This brings the best of both worlds

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] Segwit2Mb - combined soft/hard fork - Request For Comments

Responding between lines... On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty wrote: > 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? > >

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

The 95% miner signaling is important to prevent two Bitcoin forks, such as what happened with Ethereum HF and Ethereum Classic. Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has just 95% miner support will initially (for 2016 blocks) be 5% slower (an average block every

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

[bitcoin-dev] Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST

Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST = On the $100M profit claim = First I'd like to confirm Gregory Maxwell's assertion that covert use of ASICBOOST could result in $100 million USD per year profits. profit = reward -

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] Extension block proposal by Jeffrey et al

On Wednesday, April 05, 2017 4:54:05 PM Christopher Jeffrey via bitcoin-dev wrote: > There's understandable confusion about this, but this proposal is not > meant to be a BIP. Oh? If this was not meant to be a Bitcoin Improvement Proposal, perhaps you should clarify somewhere what altcoin you

[bitcoin-dev] bip-genvbvoting : more complete specification up for review

Hi all, I have put up an initial draft of the full 'bip-genvbvoting' (generalized version bits voting) specification for review: https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki Comments are again most welcome - and my thanks to those reviewers who took a

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

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. All of which seek to reduce the efficacy of large miners and selfish mining. I also

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

Hi Greg Great work in discovering this! > 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. Could you elaborate on why you consider ASICBOOST to be an

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] Proof-of-Loss

Erik, No, it is not, but I would like to ask anyone with any feedback on proof-of-loss to please direct it only to my email, or else follow the discussion links on the Proof-of-Loss home page. Thanks, Mirelo Original Message Subject: Re: [bitcoin-dev] Proof-of-Loss Local

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