Re: [bitcoin-dev] A Small Modification to Segwit

Jorge, I'll be happy to discuss with you more about whether allowing ASICBoost would actually secure the network more or not, but that's not my main motivation. My main motivation is to get more miners to accept segwit. The version bit usage part, I don't believe requires any code changes as

Re: [bitcoin-dev] A Small Modification to Segwit

On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev wrote: > I've changed the proposal so only 8 bits are given to grinding so something > like 20 bits are available for signaling. > > I have to say I'm at a loss here as to what's next? Should I make

Re: [bitcoin-dev] A Small Modification to Segwit

g via bitcoin-dev schreef op ma 10-04-2017 om 20:39 [-0600]: > > However, we need to consider the environmental impact of mining, which > currently consumes a quite exorbitant amount of energy. Any ideas on > this front? Everything is relative. Some months ago I did some investigation and

Re: [bitcoin-dev] A Small Modification to Segwit

I've changed the proposal so only 8 bits are given to grinding so something like 20 bits are available for signaling. I have to say I'm at a loss here as to what's next? Should I make a new BIP or try to convince the authors of BIP141 to modify their BIP? Could someone inform me on the next part

Re: [bitcoin-dev] A Small Modification to Segwit

Tom Zander wrote: > The version field is still needed to actually allow future block version > upgrades. We would cut off our road forward if that were to be blocked. I tend to agree, if all 32 bits were given up to grinding. But it's worth pointing out that BIP9 is purely informational, and

Re: [bitcoin-dev] A Small Modification to Segwit

The discussion is going offtopic. Can we please take vague discussions about changing pow, so called "asic resistance", the environment etc to bitcoin-disscuss or some other forum? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] A Small Modification to Segwit

> I completely agree that it will be in the long term interest of bitcoin to > migrate, gradually, toward a commoditized POW away from the current mass > centralization. There is a big problem here though: Hundreds of millions of > dollars have been spent on the current algorithm, and will be a

Re: [bitcoin-dev] A Small Modification to Segwit

The version field is still needed to actually allow future block version upgrades. We would cut off our road forward if that were to be blocked. On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote: > Currently, the version bits (currently 4 bytes, or 32 bits) in the header >

Re: [bitcoin-dev] A Small Modification to Segwit

Makes sense. I would love if GPUs were back as the main hashing tool. However, we need to consider the environmental impact of mining, which currently consumes a quite exorbitant amount of energy. Any ideas on this front? -- Garrett MacDonald +1 720 515 2248 g...@cognitive.ch GPG Key On Apr

Re: [bitcoin-dev] A Small Modification to Segwit

Erik, I completely agree that it will be in the long term interest of bitcoin to migrate, gradually, toward a commoditized POW away from the current mass centralization. There is a big problem here though: Hundreds of millions of dollars have been spent on the current algorithm, and will be a

Re: [bitcoin-dev] A Small Modification to Segwit

I own some miners, but realistically their end of life is what, 6 months from now if I'm lucky?If we used difficulty ramps on two selected POW's, then the migration could be made smooth. I don't think changing the POW would be very challenging. Personally, I would absolutely love to be back

Re: [bitcoin-dev] A Small Modification to Segwit

On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Perhaps regular, high-consensus POW changes might even be *necessary* as a > part of good maintenance of cryptocurrency in general. Killing the > existing POW, and using an as-yet

Re: [bitcoin-dev] A Small Modification to Segwit

On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Clearly a level-playing field is critical to keeping centralization from > being a "defining feature" of Bitcoin over the long term. I've heard the > term "level playing field"

Re: [bitcoin-dev] A Small Modification to Segwit

On 9 Apr 2017 4:01 pm, "Jimmy Song" wrote: Jorge, Why won't the attacker use asicboost too? (Please don't say because of > patents) > > We're assuming the ASIC optimization in my example is incompatible with ASICBoost. But if the new optimization were compatible with

Re: [bitcoin-dev] A Small Modification to Segwit

On 04/09/2017 05:20 PM, Erik Aronesty via bitcoin-dev wrote: > Have you read the cuckoo cycle paper? Finding cycles in massive graphs > is just about the worst thing to use an ASIC for. It's actually the best thing to use an ASIC tightly coupled with DRAM for - for example, HBM and HBM2 which

Re: [bitcoin-dev] A Small Modification to Segwit

Have you read the cuckoo cycle paper? Finding cycles in massive graphs is just about the worst thing to use an ASIC for. It might be a hitherto before unknown emergent property of cryptocurrencies in general that POW *must* change every 7-9 years. Could bake that into the protocol too... On

Re: [bitcoin-dev] A Small Modification to Segwit

On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: I can speak from personal experience regarding another very prominent altcoin that attempted to utilize an asic-resistant proof of work algorithm, it is only a matter of time before the

Re: [bitcoin-dev] A Small Modification to Segwit

I can speak from personal experience regarding another very prominent altcoin that attempted to utilize an asic-resistant proof of work algorithm, it is only a matter of time before the "asic resistant" algorithm gets its own Asics. The more complicated the algorithm, the more secretive the asic

Re: [bitcoin-dev] A Small Modification to Segwit

Curious: I'm not sure why a serious discussion of POW change is not on the table as a part of a longer-term roadmap. Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of the proven, np-complete graph-theoretic or polygon manipulation POW would keep Bitcoin in commodity hardware

Re: [bitcoin-dev] A Small Modification to Segwit

Jorge, Why won't the attacker use asicboost too? (Please don't say because of > patents) > > We're assuming the ASIC optimization in my example is incompatible with ASICBoost. But if the new optimization were compatible with ASICBoost, you're right, the network would be in an equivalent situation

Re: [bitcoin-dev] A Small Modification to Segwit

Why won't the attacker use asicboost too? (Please don't say because of patents) On 9 Apr 2017 12:26 am, "Jimmy Song" wrote: > Jorge, > > Suppose someone figures out an ASIC optimization that's completely > unrelated that gives X% speed boost over your non-ASICBoosted >

Re: [bitcoin-dev] A Small Modification to Segwit

On 8 Apr 2017 8:31 pm, "praxeology_guy via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: There is the equation: Power Cost + Captial Rent + Labor ~= block reward + fees I don't know why many people insist on calling the subsidy the blick reward. Thw block reward is both the block

Re: [bitcoin-dev] A Small Modification to Segwit

Jorge, Suppose someone figures out an ASIC optimization that's completely unrelated that gives X% speed boost over your non-ASICBoosted implementation. If you ban ASICBoost, someone with this optimization can get 51% of the network by adding N machines with their new optimization. If you allow

Re: [bitcoin-dev] A Small Modification to Segwit

Pavel, > I agree. I only wanted to make clear, that the impact would be > significant. Lot of parties would be involved with nonequivalent > starting positions. > > I agree with you. I believe nonequivalent starting positions are the norm in mining, not the exception and hence don't believe this

Re: [bitcoin-dev] A Small Modification to Segwit

Eric Voskuil, TL;DR: Electrical power is a general purpose consumer good vs PoW mining equipment is a single purpose consumer good. Hence the mining equipment rent is the barrier to entry, given if you invest in power generation capital you could use the power for a different purpose. Each

Re: [bitcoin-dev] A Small Modification to Segwit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/08/2017 11:15 AM, praxeology_guy via bitcoin-dev wrote: > ASICBOOST causes Bitcoin's PoW to become more memory/latency > throttled instead of raw computation throttled. > > There is the equation: Power Cost + Captial Rent + Labor ~= block >

Re: [bitcoin-dev] A Small Modification to Segwit

To be more specific, why "being higher will secure the Bitcoin network better against newer optimizations"? Or, to be more clear, let's forget about future "optimizations", let's just think of an attacker. Does asicboost being used by all miners make the system more secure against an attacker? No,

Re: [bitcoin-dev] A Small Modification to Segwit

Jimmy, >> Until all miners update (firmware or hardware), the change encourages >> large difference in mining efficiency. And IMO it gives another >> advantage to large mining operations in general. > > Certainly, there would have to be changes for stratum, pool software, etc. > But the monetary

Re: [bitcoin-dev] A Small Modification to Segwit

On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Praxeology Guy, Why would the actual end users of Bitcoin (the long term and short term > owners of bitcoins) who run fully verifying nodes want to change Bitcoin > policy in order to make their

Re: [bitcoin-dev] A Small Modification to Segwit

> > > No, it isn't allowed right now. Doing it wouldn't invalidate blocks, but it > would clearly be an attack on the network and cause harm. The same as if > miners were to maliciously mine only empty blocks. > > What's your definition of "allowed" then? Because a miner definitely can mine only

Re: [bitcoin-dev] A Small Modification to Segwit

> > I think it might be important that the mandatory commitment expire as in > Greg's proposal - when we do eventually hardfork, it will be simpler to do > in > a safe manner if such a commitment in the fake "old block" is not required. > OK, that makes sense. I'll modify my proposal this way:

Re: [bitcoin-dev] A Small Modification to Segwit

Yes, you only need a few bits in the version number, probably less than 8. If you encourage the overt method of using AsicBoost I would argue that you no longer need to dis-encourage the couvert method anymore as in Greg's proposal. Nobody would use the couvert method anyway because the overt

Re: [bitcoin-dev] A Small Modification to Segwit

On Saturday, April 08, 2017 3:17:47 PM Jimmy Song wrote: > Overt ASICBoost is allowed on the network already. Until a proposal > explicitly blocking overt ASICBoost as a soft fork is activated, this seems > to be better than the current state which is that overt ASICBoost is > allowed, but at a

Re: [bitcoin-dev] A Small Modification to Segwit

I think it might be important that the mandatory commitment expire as in Greg's proposal - when we do eventually hardfork, it will be simpler to do in a safe manner if such a commitment in the fake "old block" is not required. I don't like your proposal because it allows ASICBoost. ASICBoost

Re: [bitcoin-dev] A Small Modification to Segwit

Pavel, Until all miners update (firmware or hardware), the change encourages > large difference in mining efficiency. And IMO it gives another > advantage to large mining operations in general. > Certainly, there would have to be changes for stratum, pool software, etc. But the monetary

Re: [bitcoin-dev] A Small Modification to Segwit

> Second, we can make this change relatively quickly. Most of the Segwit > testing stays valid and this change can be deployed relatively quickly. It is true only for nodes software. Most of the world's mining infrastructure (at least for pool mining) is not ready for such change. Current

Re: [bitcoin-dev] A Small Modification to Segwit

Praxeology Guy, Why would the actual end users of Bitcoin (the long term and short term > owners of bitcoins) who run fully verifying nodes want to change Bitcoin > policy in order to make their money more vulnerable to 51% attack? > Certainly, if only one company made use of the extra nonce

Re: [bitcoin-dev] A Small Modification to Segwit

Jimmy Song, Why would the actual end users of Bitcoin (the long term and short term owners of bitcoins) who run fully verifying nodes want to change Bitcoin policy in order to make their money more vulnerable to 51% attack? If anything, we would be making policy changes to prevent the use of

Re: [bitcoin-dev] A Small Modification to Segwit

I've gotten feedback from Adam Back that you actually don't need all 32 bits in the header for overt ASICBoost, so I'm modifying my proposal. Of the 32-bit version field, bits 16 to 23 are reserved for miners, the witness commitment stays as defined in BIP-141 except that it's now required. BIP9