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

[Jimmy Song via bitcoin-dev]

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
those bits aren't being used by BIP9 anyway, though some cleanup to
restrict them later is probably a good idea.
The requiring witness commitment part would require some changes, but
according to Timo Hanke, that's actually not necessary as overt is so much
more efficient.

In any case, I'm happy to close this discussion until there's some
indication that more miners would accept segwit as a result of this change.

Jimmy

On Tue, Apr 11, 2017 at 4:25 PM, Jorge Timón  wrote:

> 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 a new
> BIP
> > or try to convince the authors of BIP141 to modify their BIP? Could
> someone
> > inform me on the next part of the process?
>
> See bip2, specifically
> https://github.com/bitcoin/bips/blob/master/bip-0002.
> mediawiki#bip-workflow
>
> "Following a discussion, the proposal should be submitted to the BIPs
> git repository as a pull request. This draft must be written in BIP
> style as described below, and named with an alias such as
> "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
> number (authors MUST NOT self-assign BIP numbers)."
>
> But I think it's kind of late to modify bip141, given that there's
> code out there with the current specification.
> I guess you can propose extensions or alternatives to replace it. I'm
> really not sure what's the next step, but I don't think you have
> provided enough motivation as to why we would want to maintain
> asicboost. You said it makes the network more secure, but that's not
> the case, as explained, not even if all honest miners use it.
>
> > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
> >  wrote:
> >>
> >> 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 the
> top
> >> 3 bits are still reserved for other purposes. One of them could perhaps
> be
> >> used to signal for an extended version field somewhere else, leaving the
> >> bottom 29 as entropy?
> >>
> >> Not a direction I prefer, but just a technical possibility perhaps.
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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 a new BIP
> or try to convince the authors of BIP141 to modify their BIP? Could someone
> inform me on the next part of the process?

See bip2, specifically
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-workflow

"Following a discussion, the proposal should be submitted to the BIPs
git repository as a pull request. This draft must be written in BIP
style as described below, and named with an alias such as
"bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
number (authors MUST NOT self-assign BIP numbers)."

But I think it's kind of late to modify bip141, given that there's
code out there with the current specification.
I guess you can propose extensions or alternatives to replace it. I'm
really not sure what's the next step, but I don't think you have
provided enough motivation as to why we would want to maintain
asicboost. You said it makes the network more secure, but that's not
the case, as explained, not even if all honest miners use it.

> On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
>  wrote:
>>
>> 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 the top
>> 3 bits are still reserved for other purposes. One of them could perhaps be
>> used to signal for an extended version field somewhere else, leaving the
>> bottom 29 as entropy?
>>
>> Not a direction I prefer, but just a technical possibility perhaps.
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Staf Verhaegen via bitcoin-dev]

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
Bitcoin mining used lees energy than the diesel used by the gold ore
mining industry...

greets,
Staf.




signature.asc
Description: This is a digitally signed message part
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 of the process?

On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 the top
> 3 bits are still reserved for other purposes. One of them could perhaps be
> used to signal for an extended version field somewhere else, leaving the
> bottom 29 as entropy?
>
> Not a direction I prefer, but just a technical possibility perhaps.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Sancho Panza via bitcoin-dev]

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 the top 3 
bits are still reserved for other purposes. One of them could perhaps be used 
to signal for an extended version field somewhere else, leaving the bottom 29 
as entropy?

Not a direction I prefer, but just a technical possibility perhaps.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Sancho Panza via bitcoin-dev]

> 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 huge loss if 
> this is not done slowly enough, and the miners who control the chain 
> currently would likely never allow this change to happen.

> Do you have any ideas regarding how to mitigate the damage of such a change 
> for the invested parties? Or even how we can make the change agreeable for 
> them?

Apologies for interjecting a thought on this topic.
My belief is that Bitcoin could grow freely, and become worth enough so that 
mining becomes profitable even for those of us in countries without free / 
subsidized electricity.

By that time, buying commodity mining equipment (ASIC-based) from major 
manufacturers should be no problem, esp. not for existing Bitcoin holders.

I see no sign that current major miners are principally opposed to such a 
natural process of decentralization of Bitcoin mining.

Sancho___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

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
> are used for BIP9 signaling. We change the version bits to a nonce-space
> so the miners can use it for overt ASICBoost. The 32-bits are now moved
> over to the Coinbase transaction as part of the witness commitment. The
> witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
> being used as the version bits in the block header previously. The
> witness commitment becomes required as per Gregory Maxwell’s proposal.
> Reasoning


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[g via bitcoin-dev]

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 10, 2017, 12:17 PM -0600, Erik Aronesty , wrote:
> 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 in the 
> business of buying GPU's instead of ASICs which are uniformly sketchy.   Does 
> anyone *not* mine their own equipment before "shipping late" these days?
>
> Maybe sample a video game's GPU operations and try to develop a secure hash 
> whose optimal implementation uses them in a similar ratio?   Ultimately, I 
> think it would very challenging to find a POW that doesn't make a bad problem 
> worse.  I understand that's why you suggested SHA3.
>
> Hopefully, the "nanometer race" we have will work more smoothly once the 
> asicboost issue is resolved and competition can return to normal.   But 
> "waiting things out" rarely seems to work in Bitcoin land.
>
>
>
>
>
>
> > On Mon, Apr 10, 2017 at 11:25 AM, g  wrote:
> > > 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 huge loss if this is not done slowly enough, and the miners who control 
> > > the chain currently would likely never allow this change to happen.
> > >
> > > Do you have any ideas regarding how to mitigate the damage of such a 
> > > change for the invested parties? Or even how we can make the change 
> > > agreeable for them?
> > >
> > > Warm regards,
> > > Garrett
> > >
> > > --
> > > Garrett MacDonald
> > > +1 720 515 2248
> > > g...@cognitive.ch
> > > GPG Key
> > >
> > > On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev 
> > > , wrote:
> > > > 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 and out of the hands of 
> > > > centralized manufacturing for many years.
> > > >
> > > > 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" bandied about quite a bit.   And 
> > > > it seems to me that the risk of state actor control and botnet attacks 
> > > > is less than state-actor manipulation of specialized manufacturing of 
> > > > "SHA-256 forever" hardware.   Indeed, the reliance on a fairly simple 
> > > > hash seems less and less likely a "feature" and more of a baggage.
> > > >
> > > > 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 undefined, but deployment-bit 
> > > > ready POW field to flip-flop between the current and the "next one" 
> > > > every 8 years or or so, with a ramp down beginning in the 7th year  
> > > > A stub function that is guaranteed to fail unless a new consensus POW 
> > > > is selected within 7 years.
> > > >
> > > > Something like that?
> > > >
> > > > Haven't thought about it *that* much, but I think the network would 
> > > > respond well to a well known cutover date.   This would enable 
> > > > rapid-response to quantum tech, or some other needed POW switch as 
> > > > well... because the mechanisms would be in-place and ready to switch as 
> > > > needed.
> > > >
> > > > Lots of people seem to panic over POW changes as "irresponsible", but 
> > > > it's only irresponsible if done irresponsibly.
> > > >
> > > >
> > > > > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev 
> > > > >  wrote:
> > > > > > 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 patented PoW algorithms instead of making changes to enable them.
> > > > > >
> > > 

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

[g via bitcoin-dev]

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 huge loss if 
this is not done slowly enough, and the miners who control the chain currently 
would likely never allow this change to happen.

Do you have any ideas regarding how to mitigate the damage of such a change for 
the invested parties? Or even how we can make the change agreeable for them?

Warm regards,
Garrett

--
Garrett MacDonald
+1 720 515 2248
g...@cognitive.ch
GPG Key

On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev 
, wrote:
> 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 and out of the hands of centralized 
> manufacturing for many years.
>
> 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" bandied about quite a bit.   And it seems to me 
> that the risk of state actor control and botnet attacks is less than 
> state-actor manipulation of specialized manufacturing of "SHA-256 forever" 
> hardware.   Indeed, the reliance on a fairly simple hash seems less and less 
> likely a "feature" and more of a baggage.
>
> 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 undefined, but deployment-bit ready POW field to 
> flip-flop between the current and the "next one" every 8 years or or so, with 
> a ramp down beginning in the 7th year  A stub function that is guaranteed 
> to fail unless a new consensus POW is selected within 7 years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would respond 
> well to a well known cutover date.   This would enable rapid-response to 
> quantum tech, or some other needed POW switch as well... because the 
> mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's 
> only irresponsible if done irresponsibly.
>
>
> > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev 
> >  wrote:
> > > 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 
> > > patented PoW algorithms instead of making changes to enable them.
> > >
> > > Thanks,
> > > Praxeology Guy
> > >
> > > ___
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Erik Aronesty via bitcoin-dev]

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 in the business of buying GPU's instead of ASICs which are
uniformly sketchy.   Does anyone *not* mine their own equipment before
"shipping late" these days?

Maybe sample a video game's GPU operations and try to develop a secure hash
whose optimal implementation uses them in a similar ratio?   Ultimately, I
think it would very challenging to find a POW that doesn't make a bad
problem worse.  I understand that's why you suggested SHA3.

Hopefully, the "nanometer race" we have will work more smoothly once the
asicboost issue is resolved and competition can return to normal.   But
"waiting things out" rarely seems to work in Bitcoin land.






On Mon, Apr 10, 2017 at 11:25 AM, g  wrote:

> 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 huge loss
> if this is not done slowly enough, and the miners who control the chain
> currently would likely never allow this change to happen.
>
> Do you have any ideas regarding how to mitigate the damage of such a
> change for the invested parties? Or even how we can make the change
> agreeable for them?
>
> Warm regards,
> Garrett
>
> --
> Garrett MacDonald
> +1 720 515 2248 <(720)%20515-2248>
> g...@cognitive.ch
> GPG Key 
>
> On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>, wrote:
>
> 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 and out of the hands of centralized
> manufacturing for many years.
>
> 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" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> 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 undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date.   This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
>
> On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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
>> patented PoW algorithms instead of making changes to enable them.
>>
>> Thanks,
>> Praxeology Guy
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Bram Cohen via bitcoin-dev]

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 undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>

That would force hard forks, cause huge governance problems on selecting
the new PoW algorithm, and probably cause even worse mining chip
manufacturer centralization because it would force miners to buy new chips
instead of sticking with the ones they've already got. They'll likely have
to keep buying new ones anyway as technology improves but it doesn't help
to force that process to go even faster.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Bram Cohen via bitcoin-dev]

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" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
>
Whatever your hashing function the bottleneck for mining will be power.
Equihash and Cuckoo are serious attempts at making custom hardware have no
benefit over commodity hardware, but that's more about getting rid of
custom hardware manufacturers than it is about mining decentralization,
although arguably if successful it might let botnets back in, which would
improve decentralization. While those have been surprisingly successful at
resisting hardware so far, they might eventually fall as well, and if they
do they'll have even worse properties of centralizing around a mining
hardware manufacturer than sha256 does.

It would be much safer to go the other way, to a PoW function whose best
hardware implementation is particularly straightforward and well
understood. In that case it would be best to go with sha3. Sha3 also has
the benefit of using the sponge construction, which makes it particularly
resistant to asciboost-type attacks. It was picked out specifically because
its design from a security standpoint was particularly
confidence-inspiring, and in this case it actually makes a difference.
Arguably you could also go with blake2b, whose 1024 bit block size
completely obviates the asicboost concern entirely by cramming everything
into a single block. That also might have an even simpler design in
hardware than sha3, but a real expert would need to opine on that one.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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 ASICBoost,
you're right, the network would be in an equivalent situation whether
ASICBoost was banned or not.


Only if all honest miners use asicboost, otherwise the situation for an
attack is not equivalent but worse with asicboost.

I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.


Doesn't greg's proposal of disabling covert asicboost "bring asicboost
usage into the open vs hiding it" too? It also does it without making any
assumptions on whether we want to completely disable it later (I want)
while your proposal assumes we do not.

Jimmy


> 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
>> 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 ASICBoost and assuming this gets a 20% speed boost over
>> non-ASICBoosted hardware, someone with this optimization would need 1.2N
>> machines to get 51%. The network in that sense is 20% stronger against this
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>>
>>> 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, for the attacker
>>> can use asicboost too.
>>> What about the case when not all the miners are using asicboost? Then
>>> the attacker can actually get an advantage by suing asicboost.
>>>
>>> Sometimes people compare asicboost with the use of asics in general as
>>> both providing more security for the network and users. But I don't
>>> think this is accurate. The existence of sha256d asics makes an attack
>>> with general purpose computing hardware (or even more specialized
>>> architectures like gpgpu) much more expensive and unlikely. As an
>>> alternative the attacker can spend additional resources investing in
>>> asics himself (again, making many attacks more expensive and
>>> unlikely).
>>>
>>> But as far as I know, asicboost can be implemented with software
>>> running on general purpose hardware that integrates with regular
>>> sha256d asics. There is probably an advantage on having the asicboost
>>> implementation "in the same box" as the sha256d, yet again the
>>> attacker can invest in hardware with the competitive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be more precise whether that makes "tx history harder
>>> to rewrite"), even if it results on the hashrate charts looking "more
>>> secure".
>>>
>>>
>>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> >  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 money more vulnerable to 51% attack?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, they
>>> would
>>> > have an advantage. But think of it this way, if some newer ASIC
>>> optimization
>>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>>> with
>>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>>> secure
>>> > the Bitcoin network better against newer optimizations.
>>> >
>>> >
>>> > Why?
>>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Thomas Daede via bitcoin-dev]

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 reduce latency and increase
throughput by placing the DRAM on an interposer with the ASIC die, or
even putting the logic on the DRAM die itself.

It would need at least proof that existing chips using HBM are ideal for
Cuckoo Cycle (unlikely) and that no DRAM manufacturer could ever be
coaxed into making an ASIC (even harder to guarantee).

I think any long term PoW change is irrelevant to the review or adoption
of the covert ASICBOOST BIPs, given the many unresolved problems of such
a change.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Erik Aronesty via bitcoin-dev]

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 Apr 9, 2017 7:51 PM, "David Vorick"  wrote:

>
>
> 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 "asic resistant"
> algorithm gets its own Asics.  The more complicated the algorithm, the more
> secretive the asic technology is developed.  Even without it,
> multi-megawatt gpu farms have already formed in the areas of the world with
> low energy costs.  I'd support the goal if I thought it possible, but I
> really don't think centralization of mining can be prevented.
>
> On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 and out of the hands of centralized
>> manufacturing for many years.
>>
>> 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" bandied about quite a bit.   And it seems to me
>> that the risk of state actor control and botnet attacks is less than
>> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
>> hardware.   Indeed, the reliance on a fairly simple hash seems less and
>> less likely a "feature" and more of a baggage.
>>
>> 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 undefined, but deployment-bit ready POW
>> field to flip-flop between the current and the "next one" every 8 years or
>> or so, with a ramp down beginning in the 7th year  A stub function that
>> is guaranteed to fail unless a new consensus POW is selected within 7
>> years.
>>
>> Something like that?
>>
>> Haven't thought about it *that* much, but I think the network would
>> respond well to a well known cutover date.   This would enable
>> rapid-response to quantum tech, or some other needed POW switch as well...
>> because the mechanisms would be in-place and ready to switch as needed.
>>
>> Lots of people seem to panic over POW changes as "irresponsible", but
>> it's only irresponsible if done irresponsibly.
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> The real bottleneck today is the amount of capex required to achieve
> optimal mining. I am strongly in favor of PoW research that investigates
> better PoW, but I do not think that any obvious strategies are known yet to
> improve substantially on computation heavy hashcash.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 "asic resistant"
algorithm gets its own Asics.  The more complicated the algorithm, the more
secretive the asic technology is developed.  Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs.  I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.

On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev"  wrote:

> 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 and out of the hands of centralized
> manufacturing for many years.
>
> 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" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> 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 undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date.   This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


The real bottleneck today is the amount of capex required to achieve
optimal mining. I am strongly in favor of PoW research that investigates
better PoW, but I do not think that any obvious strategies are known yet to
improve substantially on computation heavy hashcash.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jared Lee Richardson via bitcoin-dev]

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 technology is developed.  Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs.  I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.

On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 and out of the hands of centralized
> manufacturing for many years.
>
> 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" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> 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 undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date.   This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
>
> On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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
>> patented PoW algorithms instead of making changes to enable them.
>>
>> Thanks,
>> Praxeology Guy
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Erik Aronesty via bitcoin-dev]

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 and out of the hands of centralized
manufacturing for many years.

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" bandied about quite a bit.   And it seems to me
that the risk of state actor control and botnet attacks is less than
state-actor manipulation of specialized manufacturing of "SHA-256 forever"
hardware.   Indeed, the reliance on a fairly simple hash seems less and
less likely a "feature" and more of a baggage.

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 undefined, but deployment-bit ready POW
field to flip-flop between the current and the "next one" every 8 years or
or so, with a ramp down beginning in the 7th year  A stub function that
is guaranteed to fail unless a new consensus POW is selected within 7
years.

Something like that?

Haven't thought about it *that* much, but I think the network would respond
well to a well known cutover date.   This would enable rapid-response to
quantum tech, or some other needed POW switch as well... because the
mechanisms would be in-place and ready to switch as needed.

Lots of people seem to panic over POW changes as "irresponsible", but it's
only irresponsible if done irresponsibly.


On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> patented PoW algorithms instead of making changes to enable them.
>
> Thanks,
> Praxeology Guy
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 whether
ASICBoost was banned or not.

I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.

Jimmy


> 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
>> 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 ASICBoost and assuming this gets a 20% speed boost over
>> non-ASICBoosted hardware, someone with this optimization would need 1.2N
>> machines to get 51%. The network in that sense is 20% stronger against this
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>>
>>> 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, for the attacker
>>> can use asicboost too.
>>> What about the case when not all the miners are using asicboost? Then
>>> the attacker can actually get an advantage by suing asicboost.
>>>
>>> Sometimes people compare asicboost with the use of asics in general as
>>> both providing more security for the network and users. But I don't
>>> think this is accurate. The existence of sha256d asics makes an attack
>>> with general purpose computing hardware (or even more specialized
>>> architectures like gpgpu) much more expensive and unlikely. As an
>>> alternative the attacker can spend additional resources investing in
>>> asics himself (again, making many attacks more expensive and
>>> unlikely).
>>>
>>> But as far as I know, asicboost can be implemented with software
>>> running on general purpose hardware that integrates with regular
>>> sha256d asics. There is probably an advantage on having the asicboost
>>> implementation "in the same box" as the sha256d, yet again the
>>> attacker can invest in hardware with the competitive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be more precise whether that makes "tx history harder
>>> to rewrite"), even if it results on the hashrate charts looking "more
>>> secure".
>>>
>>>
>>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> >  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 money more vulnerable to 51% attack?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, they
>>> would
>>> > have an advantage. But think of it this way, if some newer ASIC
>>> optimization
>>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>>> with
>>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>>> secure
>>> > the Bitcoin network better against newer optimizations.
>>> >
>>> >
>>> > Why?
>>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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
> 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 ASICBoost and assuming this gets a 20% speed boost over
> non-ASICBoosted hardware, someone with this optimization would need 1.2N
> machines to get 51%. The network in that sense is 20% stronger against this
> attack in terms of cost.
>
> Jimmy
>
> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>
>> 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, for the attacker
>> can use asicboost too.
>> What about the case when not all the miners are using asicboost? Then
>> the attacker can actually get an advantage by suing asicboost.
>>
>> Sometimes people compare asicboost with the use of asics in general as
>> both providing more security for the network and users. But I don't
>> think this is accurate. The existence of sha256d asics makes an attack
>> with general purpose computing hardware (or even more specialized
>> architectures like gpgpu) much more expensive and unlikely. As an
>> alternative the attacker can spend additional resources investing in
>> asics himself (again, making many attacks more expensive and
>> unlikely).
>>
>> But as far as I know, asicboost can be implemented with software
>> running on general purpose hardware that integrates with regular
>> sha256d asics. There is probably an advantage on having the asicboost
>> implementation "in the same box" as the sha256d, yet again the
>> attacker can invest in hardware with the competitive advantage from
>> having asicboost more intergrated with the sha256d asics too.
>>
>> To reiterate, whether all miners use asicboost or only a subset of
>> them, I remain unconvinced that provides any additional security to
>> the network (to be more precise whether that makes "tx history harder
>> to rewrite"), even if it results on the hashrate charts looking "more
>> secure".
>>
>>
>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>> >
>> >
>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>> >  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 money more vulnerable to 51% attack?
>> >
>> >
>> > Certainly, if only one company made use of the extra nonce space, they
>> would
>> > have an advantage. But think of it this way, if some newer ASIC
>> optimization
>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>> with
>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>> secure
>> > the Bitcoin network better against newer optimizations.
>> >
>> >
>> > Why?
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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 subsidy plus the block fees.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 ASICBoost and assuming this gets a 20% speed boost over
non-ASICBoosted hardware, someone with this optimization would need 1.2N
machines to get 51%. The network in that sense is 20% stronger against this
attack in terms of cost.

Jimmy

On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:

> 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, for the attacker
> can use asicboost too.
> What about the case when not all the miners are using asicboost? Then
> the attacker can actually get an advantage by suing asicboost.
>
> Sometimes people compare asicboost with the use of asics in general as
> both providing more security for the network and users. But I don't
> think this is accurate. The existence of sha256d asics makes an attack
> with general purpose computing hardware (or even more specialized
> architectures like gpgpu) much more expensive and unlikely. As an
> alternative the attacker can spend additional resources investing in
> asics himself (again, making many attacks more expensive and
> unlikely).
>
> But as far as I know, asicboost can be implemented with software
> running on general purpose hardware that integrates with regular
> sha256d asics. There is probably an advantage on having the asicboost
> implementation "in the same box" as the sha256d, yet again the
> attacker can invest in hardware with the competitive advantage from
> having asicboost more intergrated with the sha256d asics too.
>
> To reiterate, whether all miners use asicboost or only a subset of
> them, I remain unconvinced that provides any additional security to
> the network (to be more precise whether that makes "tx history harder
> to rewrite"), even if it results on the hashrate charts looking "more
> secure".
>
>
> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
> >
> >
> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> >  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 money more vulnerable to 51% attack?
> >
> >
> > Certainly, if only one company made use of the extra nonce space, they
> would
> > have an advantage. But think of it this way, if some newer ASIC
> optimization
> > comes up, would you rather have a non-ASICBoosted hash rate to defend
> with
> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
> secure
> > the Bitcoin network better against newer optimizations.
> >
> >
> > Why?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 to be a problem.


>
> I think the ASICBoost can and should be prevented completely.
>

It certainly can be and from the responses I'm getting, I believe there
would be at least a few people that would enthusiastically support a BIP to
do that. That is, however, a separate issue than my proposal. My proposal
aims to bring ASICBoost out into the open *while it is still possible*. A
BIP to prevent ASICBoost completely is in that sense compatible.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[praxeology_guy via bitcoin-dev]

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 unit of electrical power (1 V* A = 1 Watt) is a finite unit of a highly 
non-durable consumable good.

It is true that electrical power is created by utilizing capital equipment, and 
the capital rent + labor of generating such power is the basis for the "Power 
Cost" component of the ideal miner competition profit equation.

But... electrical power is a general consumer good that can be used for many 
things, so investing in the capital to create it is not a very risky endeavor.

On the other hand, Bitcoin mining equipment capital is an EXTEREMELY specific 
kind of capital that only has exactly one use: efficiently/competitively mining 
a coin that has a particular PoW algorithm. Hence investing in bitcoin mining 
equipment is a more risky endeavor than power generation capital. Such a risk 
is a barrier to entry, and it is the barrier that is most considered when an 
entity considers mining Bitcoins.

Mature Arithmetic Logic Unit (ALU) bound PoW algorithms lacking new attacks 
(cryptographic definition) can only be out-dated by more efficient, more 
general purpose (less specific case proprietary) transistor fabrication 
technology.

Memory Latency bound PoW algorithms lacking new attacks (cryptographic 
definition) have the risk of being encumbered by all sorts of physical hardware 
patent inventions. This is because latency has significantly more room for such 
specific-to-PoW non-general purpose inventions... beyond additional patents 
relating to memory technology on top of ALU patents. Patents, I should point 
out, either cause the price of capital equipment to increase or enforce a 
monopoly on the capital... neither of which are desirable.

The capital maturity outlook of memory latency bound algorithms is also 
significantly worse than ALU bound... due to all of the expected future 
patent-able optimizations that could improve memory latency. Hence investing in 
memory latency bound mining equipment is even riskier because of the likeliness 
of a new patented optimization making your capital non-competitive, and given 
its specific nature, worthless.

This discussion brings me to a new insight. We have said that some places have 
"cheaper" power than others, due to the non-durable nature of electrical power. 
With the existence of Bitcoin, given other cost factors being less significant, 
Bitcoin causes all sources of power everywhere to be more equal in price at a 
particular time.

Now you might argue that memory latency bound PoW algorithms result in the 
mining capital component being the larger component than the electricity 
component being a good thing because: then mining would be less local to 
otherwise untapped (cheap) power sources. The problem with this is that as the 
mining capital matures (as all the optimizations are found, and the patents run 
out), we go strait back to the power cost being the largest component... and we 
had to suffer all the years of various entities unpredictably attaining a 
monopoly on mining in order to get there.

Please let me know if I made a mistake.

Thanks,
Praxeology Guy___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

-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
> reward + fees
> 
> Capital Rent is a barrier to entry, and hence in desiring a more 
> distributed system, we would like to minimize the Capital Rent
> portion of the equation.
> 
> Resolving memory/latency throttle requires a greater Captial Rent
> than raw computation throttle.
> 
> Hence (agreeing with Luke), ASICBOOST is not desirable, even if it 
> wasn't a government enforced monopoly on mining.
> 
> Please let me know if I made a mistake.

Electric power is not an abstraction, it's the output of machines.
What you are referring to as Power Cost typically consists of a higher
rent component than computing hardware, where rent is the sharing of a
resource by multiple people. So by your reasoning you appear to have
drawn the wrong conclusion.

e
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY6TEUAAoJEDzYwH8LXOFOiQIH/RN8YhLCokZtGoFZ+dOgwCxc
/ej3m9CXVGyWvcCJMQd2ZJFgpjL5mgJdcCdaWoTeZfh0Nmvc3hDex46wWpUZc/mR
NbRj56hyqe+cWAwQJJpAOWiJXjEuS3npXFvZIBpslECXCL6U+LSxdW9WSg0w+HBD
jihIlG2TeGSrMR/atKfSnVRAnz9ahPvgUwcR8l7oLsjP2JvBGl+fQHL5MwpvRg4a
sXK3eMIeH7wGJyiKOwXyMeRMfCRlwpkBCw0R+FYt2Q5l/uwkRAKuJiYUlJixFAZA
ggQth02pFn/tASB49oBKZU3QviVRGgoIQ5DFyI8OPa10FeVsxaeNeBQylwWJA3c=
=Ryo5
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.

Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).

But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.

To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".


On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>
>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>  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 money more vulnerable to 51% attack?
>
>
> Certainly, if only one company made use of the extra nonce space, they would
> have an advantage. But think of it this way, if some newer ASIC optimization
> comes up, would you rather have a non-ASICBoosted hash rate to defend with
> or an ASICBoosted hash rate? Certainly, the latter, being higher will secure
> the Bitcoin network better against newer optimizations.
>
>
> Why?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Pavel Moravec via bitcoin-dev]

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 incentives align to all the changes needed.

I agree. I only wanted to make clear, that the impact would be
significant. Lot of parties would be involved with nonequivalent
starting positions.

> Remember, overt ASICBoost can get something like a 12.5% efficiency boost
> from toggling a single bit in the version (equivalent to 2 colliding work
> items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4% from
> 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf). In lieu
> of an explicit allowance of overt ASICBoost, the monetary incentives lead to
> odd BIP9 signaling, especially if 4 or more proposals signal at once. There
> really isn't a practical way to block overt ASICBoost without forcing the
> version bits to be some value.

You can e.g. place the version number into a coinbase, similarly to
block height. Then, it is the same (number of operations) as modifying
the coinbase directly.

A cost of version in coinbase is 4B per block, sure, but it allows to
save all bits for "more useful" purposes. Either for BIP9 signalling
or other future purposes I cannot see now. And it removes an incentive
to mess with version bits.

Mining empty blocks and finding collisions by toggling bits there can
be prevented as well.

> In other words, the question isn't about allowing/disallowing ASICBoost at
> this point. The question is whether we want ASICBoost open or hidden.

I think the ASICBoost can and should be prevented completely.


Pavel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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 money more vulnerable to 51% attack?
>

Certainly, if only one company made use of the extra nonce space, they
would have an advantage. But think of it this way, if some newer ASIC
optimization comes up, would you rather have a non-ASICBoosted hash rate to
defend with or an ASICBoosted hash rate? Certainly, the latter, being
higher will secure the Bitcoin network better against newer optimizations.


Why?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

>
>
> 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 empty blocks and a miner definitely can do overt ASICBoost (using
as little as 1 bit of the version field) right now. I thought you meant
allowed in the sense that if a block is allowed, it is a valid block on the
network. It sounds like you mean something else, perhaps, "a block is
allowed if it doesn't cause harm to the network." I'm not sure how you
quantify that as that seems pretty subjective.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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

Beginning block X and until block Y the coinbase transaction of
each block MUST contain a BIP-141 segwit commitment


> I don't like your proposal because it allows ASICBoost. ASICBoost
> effectively
> makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of
> entry to
> new mining chip manufacturers, and gives a larger advantage to the miners
> able
> to make use of it. Instead, IMO we should fix the vulnerability exploited
> by
> ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change
> the
> PoW to an algorithm that is more ASIC-friendly.
>

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 cost to BIP9 signals.

Jimmy


> That being said, I don't think I would oppose the proposal if it gained
> notably better support than Segwit currently has (as yet another
> compromise),
> and the above concerns were addressed (eg, Bitfury and Canaan state they
> can
> compete using ASICBoost and the patents are licensed freely to everyone).
>
> Luke
>
>
> On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:
> > 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 then is modified so that bits 16 to 23 are now no longer
> > usable.
> >
> > On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song  wrote:
> > > Hey everyone, This is an idea that I had about Segwit and Gregory's
> > > proposal from yesterday that I wanted to run by everyone on this list.
> > > I'm not at all sure what this would mean for non-upgraded nodes on the
> > > network and would like feedback on that. This is not a formal BIP as
> > > it's a modification to a previously submitted one, but I'm happy to
> > > formalize it if it would help.
> > > 
> > > MotivationOne of the interesting aspects of Gregory Maxwell’s proposal
> is
> > > that it only precludes the covert version of ASICBoost. He specifically
> > > left the overt version alone.
> > >
> > > Overt ASICBoost requires grinding on the version bits of the Block
> header
> > > instead of the Merkle Root. This is likely more efficient than the
> Merkle
> > > Root grinding (aka covert ASICBoost) and requires way less resources
> > > (much less RAM, SHA256 calculations, no tx shuffling, etc).
> > >
> > > If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add
> a
> > > slight modification, this should, in theory, make ASICBoost a lot more
> > > useful to miners and appeal to their financial interests.
> > > The Modification
> > >
> > > Currently, the version bits (currently 4 bytes, or 32 bits) in the
> header
> > > are used for BIP9 signaling. We change the version bits to a
> nonce-space
> > > so the miners can use it for overt ASICBoost. The 32-bits are now moved
> > > over to the Coinbase transaction as part of the witness commitment. The
> > > witness commitment goes from 38 bytes to 42 bytes, with the last 4
> bytes
> > > being used as the version bits in the block header previously. The
> > > witness commitment becomes required as per Gregory Maxwell’s proposal.
> > > Reasoning
> > >
> > > First, this brings ASICBoost out into the open. Covert ASICBoost
> becomes
> > > much more costly and overt ASICBoost is now encouraged.
> > >
> > > Second, we can make this change relatively quickly. Most of the Segwit
> > > testing stays valid and this change can be deployed relatively quickly.
> > >
> > > Note on SPV clients
> > >
> > > Currently Segwit stores the witness commitment in the Coinbase tx, so
> > > lightweight clients will need to get the Coinbase tx + Merkle proof to
> > > validate segwit transactions anyway. Putting block version information
> in
> > > the Coinbase tx will not impose an extra burden on upgraded light
> > > clients.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Timo Hanke via bitcoin-dev]

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
method is so much simpler. So maybe the proposals can be completely
disentangled?


On Fri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 then is modified so that bits 16 to 23 are now no longer
> usable.
>
> On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song  wrote:
>
>> Hey everyone, This is an idea that I had about Segwit and Gregory's
>> proposal from yesterday that I wanted to run by everyone on this list. I'm
>> not at all sure what this would mean for non-upgraded nodes on the network
>> and would like feedback on that. This is not a formal BIP as it's a
>> modification to a previously submitted one, but I'm happy to formalize it
>> if it would help.
>> 
>> MotivationOne of the interesting aspects of Gregory Maxwell’s proposal
>> is that it only precludes the covert version of ASICBoost. He
>> specifically left the overt version alone.
>>
>> Overt ASICBoost requires grinding on the version bits of the Block
>> header instead of the Merkle Root. This is likely more efficient than the
>> Merkle Root grinding (aka covert ASICBoost) and requires way less
>> resources (much less RAM, SHA256 calculations, no tx shuffling, etc).
>>
>> If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
>> slight modification, this should, in theory, make ASICBoost a lot more
>> useful to miners and appeal to their financial interests.
>> The Modification
>>
>> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
>> are used for BIP9 signaling. We change the version bits to a nonce-space so
>> the miners can use it for overt ASICBoost. The 32-bits are now moved
>> over to the Coinbase transaction as part of the witness commitment. The
>> witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
>> being used as the version bits in the block header previously. The witness
>> commitment becomes required as per Gregory Maxwell’s proposal.
>> Reasoning
>>
>> First, this brings ASICBoost out into the open. Covert ASICBoost becomes
>> much more costly and overt ASICBoost is now encouraged.
>>
>> Second, we can make this change relatively quickly. Most of the Segwit
>> testing stays valid and this change can be deployed relatively quickly.
>>
>> Note on SPV clients
>>
>> Currently Segwit stores the witness commitment in the Coinbase tx, so
>> lightweight clients will need to get the Coinbase tx + Merkle proof to
>> validate segwit transactions anyway. Putting block version information in
>> the Coinbase tx will not impose an extra burden on upgraded light clients.
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

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 cost to BIP9 signals.

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.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

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 effectively 
makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of entry to 
new mining chip manufacturers, and gives a larger advantage to the miners able 
to make use of it. Instead, IMO we should fix the vulnerability exploited by 
ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change the 
PoW to an algorithm that is more ASIC-friendly.

That being said, I don't think I would oppose the proposal if it gained 
notably better support than Segwit currently has (as yet another compromise), 
and the above concerns were addressed (eg, Bitfury and Canaan state they can 
compete using ASICBoost and the patents are licensed freely to everyone).

Luke


On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:
> 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 then is modified so that bits 16 to 23 are now no longer
> usable.
> 
> On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song  wrote:
> > Hey everyone, This is an idea that I had about Segwit and Gregory's
> > proposal from yesterday that I wanted to run by everyone on this list.
> > I'm not at all sure what this would mean for non-upgraded nodes on the
> > network and would like feedback on that. This is not a formal BIP as
> > it's a modification to a previously submitted one, but I'm happy to
> > formalize it if it would help.
> > 
> > MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
> > that it only precludes the covert version of ASICBoost. He specifically
> > left the overt version alone.
> > 
> > Overt ASICBoost requires grinding on the version bits of the Block header
> > instead of the Merkle Root. This is likely more efficient than the Merkle
> > Root grinding (aka covert ASICBoost) and requires way less resources
> > (much less RAM, SHA256 calculations, no tx shuffling, etc).
> > 
> > If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
> > slight modification, this should, in theory, make ASICBoost a lot more
> > useful to miners and appeal to their financial interests.
> > The Modification
> > 
> > Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> > are used for BIP9 signaling. We change the version bits to a nonce-space
> > so the miners can use it for overt ASICBoost. The 32-bits are now moved
> > over to the Coinbase transaction as part of the witness commitment. The
> > witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
> > being used as the version bits in the block header previously. The
> > witness commitment becomes required as per Gregory Maxwell’s proposal.
> > Reasoning
> > 
> > First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> > much more costly and overt ASICBoost is now encouraged.
> > 
> > Second, we can make this change relatively quickly. Most of the Segwit
> > testing stays valid and this change can be deployed relatively quickly.
> > 
> > Note on SPV clients
> > 
> > Currently Segwit stores the witness commitment in the Coinbase tx, so
> > lightweight clients will need to get the Coinbase tx + Merkle proof to
> > validate segwit transactions anyway. Putting block version information in
> > the Coinbase tx will not impose an extra burden on upgraded light
> > clients.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 incentives align to all the changes needed.

Remember, overt ASICBoost can get something like a 12.5% efficiency boost
from toggling a single bit in the version (equivalent to 2 colliding work
items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4%
from 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf).
In lieu of an explicit allowance of overt ASICBoost, the monetary
incentives lead to odd BIP9 signaling, especially if 4 or more proposals
signal at once. There really isn't a practical way to block overt ASICBoost
without forcing the version bits to be some value.

In other words, the question isn't about allowing/disallowing ASICBoost at
this point. The question is whether we want ASICBoost open or hidden.


> You make a strong assumption that the new optimization is not
> compatible with overt ASICBoost. If it is compatible, ASICBoost
> doesn't help you with "defending against" the new optimization at all.
> And it can be the case that the new optimization is based on ASICBoost
> so you can make the situation "worse" by allowing it.
>

This would only be the case if overt ASICBoost were not possible at all. It
is currently possible to use overt ASICBoost, so optimizations based on
overt ASICBoost would also be possible unless something were done to
actively block it.

> Certainly, if only one company made use of the extra nonce space, they
> would have an advantage.
>
> Can you explain why the reality should be significantly different? In
> sufficiently near future.


Market incentives, I would imagine. How quickly that would be is not
something I'm qualified to answer.


> We don't have to deal with any such theoretical situation now. You
> proposal goes in opposite direction, by adding support for patented
> algorithm. I don't know myself what the possible legal implications
> are (maybe only for a subset of miners) so I consider it as an
> unnecessary risk. At least before some conclusive legal analysis says
> differently.
>

I'm not adding support as much as explicitly allowing what's implicitly
allowed. Whatever risks you imagine for this proposal exist on the network
currently, with unmodified BIP-141 and with modified BIP-141. The
difference in adding the modification is that overt ASICBoost is explicitly
allowed in the modified BIP-141 as to not hide it.

Jimmy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Pavel Moravec via bitcoin-dev]

> 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 version of Stratum protocol doesn't support block
version changing. A broad adoption would require:

- A new standard extension to the mining protocol (generally, we want
the hash rate to be free to change the used pool without efficiency
loss)
- Pool operators must change their software.
- All miners must update their firmware IF they have compatible
hardware (we know there is compatible hardware out there but
definitely not all of the currently used). The firmware can be changed
after the mining protocol extension is settled.

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.

> But think of it this way, if some newer ASIC optimization comes up, would you 
> rather have a non-ASICBoosted hash rate to defend with or an ASICBoosted hash 
> rate? Certainly, the latter, being higher will secure the Bitcoin network 
> better against newer optimizations.

You make a strong assumption that the new optimization is not
compatible with overt ASICBoost. If it is compatible, ASICBoost
doesn't help you with "defending against" the new optimization at all.
And it can be the case that the new optimization is based on ASICBoost
so you can make the situation "worse" by allowing it.

> Certainly, if only one company made use of the extra nonce space, they would 
> have an advantage.

Can you explain why the reality should be significantly different? In
sufficiently near future.

> Is that patented in any jurisdiction, all jurisdictions or only certain 
> jurisdictions? Would a patent granted for SHA256 in Swaziland be sufficient 
> for Bitcoin to change the Proof of Work algorithm?

We don't have to deal with any such theoretical situation now. You
proposal goes in opposite direction, by adding support for patented
algorithm. I don't know myself what the possible legal implications
are (maybe only for a subset of miners) so I consider it as an
unnecessary risk. At least before some conclusive legal analysis says
differently.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 space, they
would have an advantage. But think of it this way, if some newer ASIC
optimization comes up, would you rather have a non-ASICBoosted hash rate to
defend with or an ASICBoosted hash rate? Certainly, the latter, being
higher will secure the Bitcoin network better against newer optimizations.


> If anything, we would be making policy changes to prevent the use of
> patented PoW algorithms instead of making changes to enable them.
>

Is that patented in any jurisdiction, all jurisdictions or only certain
jurisdictions? Would a patent granted for SHA256 in Swaziland be sufficient
for Bitcoin to change the Proof of Work algorithm? This is a very
subjective judgment based on quasi-legality and I don't think that's a road
that Bitcoin should go down.

Certainly, it would be better if the patent for ASICBoost were
open-sourced, but the legality of such-and-such thing in such-and-such
jurisdiction should not affect Bitcoin policy as that in itself introduces
significant risk to the network. A sufficiently authoritarian government
can then grant a monopoly for various algorithms in their country and
negatively impact Bitcoin.

Indeed, there are already many individuals that disobey the laws of their
country to help the Bitcoin network run. I would expect the same with
patents. Should there come a time when a patent or some other legal
maneuvering gives one network actor a large advantage to the detriment of
the network, I believe that Bitcoin will handle that in the specific case.

In the meantime, I believe such changes increase the odds of Segwit
actually being accepted and activated as per BIP-141.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[praxeology_guy via bitcoin-dev]

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 patented 
PoW algorithms instead of making changes to enable them.

Thanks,
Praxeology Guy___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jimmy Song via bitcoin-dev]

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 then is modified so that bits 16 to 23 are now no longer
usable.

On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song  wrote:

> Hey everyone, This is an idea that I had about Segwit and Gregory's
> proposal from yesterday that I wanted to run by everyone on this list. I'm
> not at all sure what this would mean for non-upgraded nodes on the network
> and would like feedback on that. This is not a formal BIP as it's a
> modification to a previously submitted one, but I'm happy to formalize it
> if it would help.
> 
> MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
> that it only precludes the covert version of ASICBoost. He specifically
> left the overt version alone.
>
> Overt ASICBoost requires grinding on the version bits of the Block header
> instead of the Merkle Root. This is likely more efficient than the Merkle
> Root grinding (aka covert ASICBoost) and requires way less resources
> (much less RAM, SHA256 calculations, no tx shuffling, etc).
>
> If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
> slight modification, this should, in theory, make ASICBoost a lot more
> useful to miners and appeal to their financial interests.
> The Modification
>
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> are used for BIP9 signaling. We change the version bits to a nonce-space so
> the miners can use it for overt ASICBoost. The 32-bits are now moved over
> to the Coinbase transaction as part of the witness commitment. The witness
> commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used
> as the version bits in the block header previously. The witness commitment
> becomes required as per Gregory Maxwell’s proposal.
> Reasoning
>
> First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> much more costly and overt ASICBoost is now encouraged.
>
> Second, we can make this change relatively quickly. Most of the Segwit
> testing stays valid and this change can be deployed relatively quickly.
>
> Note on SPV clients
>
> Currently Segwit stores the witness commitment in the Coinbase tx, so
> lightweight clients will need to get the Coinbase tx + Merkle proof to
> validate segwit transactions anyway. Putting block version information in
> the Coinbase tx will not impose an extra burden on upgraded light clients.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev