* [bitcoin-dev] A Small Modification to Segwit
@ 2017-04-07 20:06 Jimmy Song
2017-04-08 0:05 ` Jimmy Song
` (2 more replies)
0 siblings, 3 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-07 20:06 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3741 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-07 20:06 [bitcoin-dev] A Small Modification to Segwit Jimmy Song
@ 2017-04-08 0:05 ` Jimmy Song
2017-04-08 14:59 ` Luke Dashjr
2017-04-08 16:19 ` Timo Hanke
2017-04-08 1:48 ` praxeology_guy
2017-04-11 7:59 ` Tom Zander
2 siblings, 2 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 0:05 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]
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 <jaejoon@gmail•com> 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.
>
[-- Attachment #2: Type: text/html, Size: 5368 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-07 20:06 [bitcoin-dev] A Small Modification to Segwit Jimmy Song
2017-04-08 0:05 ` Jimmy Song
@ 2017-04-08 1:48 ` praxeology_guy
2017-04-08 2:46 ` Jimmy Song
2017-04-09 18:44 ` Erik Aronesty
2017-04-11 7:59 ` Tom Zander
2 siblings, 2 replies; 41+ messages in thread
From: praxeology_guy @ 2017-04-08 1:48 UTC (permalink / raw)
To: Jimmy Song; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 497 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 1:48 ` praxeology_guy
@ 2017-04-08 2:46 ` Jimmy Song
2017-04-08 8:33 ` Pavel Moravec
2017-04-08 16:27 ` Jorge Timón
2017-04-09 18:44 ` Erik Aronesty
1 sibling, 2 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 2:46 UTC (permalink / raw)
To: praxeology_guy; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2436 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 2:46 ` Jimmy Song
@ 2017-04-08 8:33 ` Pavel Moravec
2017-04-08 14:35 ` Jimmy Song
2017-04-08 16:27 ` Jorge Timón
1 sibling, 1 reply; 41+ messages in thread
From: Pavel Moravec @ 2017-04-08 8:33 UTC (permalink / raw)
To: Jimmy Song, Bitcoin Protocol Discussion
> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 8:33 ` Pavel Moravec
@ 2017-04-08 14:35 ` Jimmy Song
2017-04-08 16:38 ` Pavel Moravec
2017-04-08 18:15 ` praxeology_guy
0 siblings, 2 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 14:35 UTC (permalink / raw)
To: Pavel Moravec; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3768 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 0:05 ` Jimmy Song
@ 2017-04-08 14:59 ` Luke Dashjr
2017-04-08 15:17 ` Jimmy Song
2017-04-08 16:19 ` Timo Hanke
1 sibling, 1 reply; 41+ messages in thread
From: Luke Dashjr @ 2017-04-08 14:59 UTC (permalink / raw)
To: bitcoin-dev, Jimmy Song
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 <jaejoon@gmail•com> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 14:59 ` Luke Dashjr
@ 2017-04-08 15:17 ` Jimmy Song
2017-04-08 16:05 ` Luke Dashjr
0 siblings, 1 reply; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 15:17 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4581 bytes --]
>
> 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 <jaejoon@gmail•com> 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.
>
[-- Attachment #2: Type: text/html, Size: 5955 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 15:17 ` Jimmy Song
@ 2017-04-08 16:05 ` Luke Dashjr
2017-04-08 16:16 ` Jimmy Song
0 siblings, 1 reply; 41+ messages in thread
From: Luke Dashjr @ 2017-04-08 16:05 UTC (permalink / raw)
To: Jimmy Song; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 16:05 ` Luke Dashjr
@ 2017-04-08 16:16 ` Jimmy Song
0 siblings, 0 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 16:16 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
>
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1069 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 0:05 ` Jimmy Song
2017-04-08 14:59 ` Luke Dashjr
@ 2017-04-08 16:19 ` Timo Hanke
1 sibling, 0 replies; 41+ messages in thread
From: Timo Hanke @ 2017-04-08 16:19 UTC (permalink / raw)
To: Jimmy Song, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]
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 <jaejoon@gmail•com> 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
>
>
[-- Attachment #2: Type: text/html, Size: 7544 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 2:46 ` Jimmy Song
2017-04-08 8:33 ` Pavel Moravec
@ 2017-04-08 16:27 ` Jorge Timón
2017-04-08 17:22 ` Jorge Timón
1 sibling, 1 reply; 41+ messages in thread
From: Jorge Timón @ 2017-04-08 16:27 UTC (permalink / raw)
To: Jimmy Song, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
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?
[-- Attachment #2: Type: text/html, Size: 1392 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 14:35 ` Jimmy Song
@ 2017-04-08 16:38 ` Pavel Moravec
2017-04-08 22:19 ` Jimmy Song
2017-04-08 18:15 ` praxeology_guy
1 sibling, 1 reply; 41+ messages in thread
From: Pavel Moravec @ 2017-04-08 16:38 UTC (permalink / raw)
To: Jimmy Song; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 16:27 ` Jorge Timón
@ 2017-04-08 17:22 ` Jorge Timón
2017-04-08 22:26 ` Jimmy Song
0 siblings, 1 reply; 41+ messages in thread
From: Jorge Timón @ 2017-04-08 17:22 UTC (permalink / raw)
To: Jimmy Song, 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 <jtimon@jtimon•cc> wrote:
>
>
> 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?
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 14:35 ` Jimmy Song
2017-04-08 16:38 ` Pavel Moravec
@ 2017-04-08 18:15 ` praxeology_guy
2017-04-08 18:51 ` Eric Voskuil
2017-04-09 11:46 ` Jorge Timón
1 sibling, 2 replies; 41+ messages in thread
From: praxeology_guy @ 2017-04-08 18:15 UTC (permalink / raw)
Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
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.
Thanks,
Praxeology Guy
[-- Attachment #2: Type: text/html, Size: 834 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 18:15 ` praxeology_guy
@ 2017-04-08 18:51 ` Eric Voskuil
2017-04-08 20:38 ` praxeology_guy
2017-04-09 11:46 ` Jorge Timón
1 sibling, 1 reply; 41+ messages in thread
From: Eric Voskuil @ 2017-04-08 18:51 UTC (permalink / raw)
To: praxeology_guy, Bitcoin Protocol Discussion
-----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-----
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 18:51 ` Eric Voskuil
@ 2017-04-08 20:38 ` praxeology_guy
0 siblings, 0 replies; 41+ messages in thread
From: praxeology_guy @ 2017-04-08 20:38 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3781 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 16:38 ` Pavel Moravec
@ 2017-04-08 22:19 ` Jimmy Song
0 siblings, 0 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 22:19 UTC (permalink / raw)
To: Pavel Moravec; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1232 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 17:22 ` Jorge Timón
@ 2017-04-08 22:26 ` Jimmy Song
2017-04-09 11:48 ` Jorge Timón
0 siblings, 1 reply; 41+ messages in thread
From: Jimmy Song @ 2017-04-08 22:26 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]
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 <jtimon@jtimon•cc> 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 <jtimon@jtimon•cc> wrote:
> >
> >
> > 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?
>
[-- Attachment #2: Type: text/html, Size: 3925 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 18:15 ` praxeology_guy
2017-04-08 18:51 ` Eric Voskuil
@ 2017-04-09 11:46 ` Jorge Timón
1 sibling, 0 replies; 41+ messages in thread
From: Jorge Timón @ 2017-04-09 11:46 UTC (permalink / raw)
To: praxeology_guy, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 328 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 755 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 22:26 ` Jimmy Song
@ 2017-04-09 11:48 ` Jorge Timón
2017-04-09 14:01 ` Jimmy Song
0 siblings, 1 reply; 41+ messages in thread
From: Jorge Timón @ 2017-04-09 11:48 UTC (permalink / raw)
To: Jimmy Song; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3481 bytes --]
Why won't the attacker use asicboost too? (Please don't say because of
patents)
On 9 Apr 2017 12:26 am, "Jimmy Song" <jaejoon@gmail•com> 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 <jtimon@jtimon•cc> 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 <jtimon@jtimon•cc> wrote:
>> >
>> >
>> > 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?
>>
>
>
[-- Attachment #2: Type: text/html, Size: 4418 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 11:48 ` Jorge Timón
@ 2017-04-09 14:01 ` Jimmy Song
[not found] ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
0 siblings, 1 reply; 41+ messages in thread
From: Jimmy Song @ 2017-04-09 14:01 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4066 bytes --]
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" <jaejoon@gmail•com> 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 <jtimon@jtimon•cc> 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 <jtimon@jtimon•cc> wrote:
>>> >
>>> >
>>> > 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?
>>>
>>
>>
[-- Attachment #2: Type: text/html, Size: 5503 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-08 1:48 ` praxeology_guy
2017-04-08 2:46 ` Jimmy Song
@ 2017-04-09 18:44 ` Erik Aronesty
2017-04-09 21:16 ` Jared Lee Richardson
` (3 more replies)
1 sibling, 4 replies; 41+ messages in thread
From: Erik Aronesty @ 2017-04-09 18:44 UTC (permalink / raw)
To: praxeology_guy, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 3211 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 18:44 ` Erik Aronesty
@ 2017-04-09 21:16 ` Jared Lee Richardson
2017-04-09 23:51 ` David Vorick
2017-04-10 14:34 ` Bram Cohen
` (2 subsequent siblings)
3 siblings, 1 reply; 41+ messages in thread
From: Jared Lee Richardson @ 2017-04-09 21:16 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 4599 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 21:16 ` Jared Lee Richardson
@ 2017-04-09 23:51 ` David Vorick
2017-04-10 0:20 ` Erik Aronesty
0 siblings, 1 reply; 41+ messages in thread
From: David Vorick @ 2017-04-09 23:51 UTC (permalink / raw)
To: Jared Lee Richardson; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4478 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 23:51 ` David Vorick
@ 2017-04-10 0:20 ` Erik Aronesty
2017-04-10 1:45 ` Thomas Daede
0 siblings, 1 reply; 41+ messages in thread
From: Erik Aronesty @ 2017-04-10 0:20 UTC (permalink / raw)
To: David Vorick; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]
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" <david.vorick@gmail•com> 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.
>
[-- Attachment #2: Type: text/html, Size: 5256 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-10 0:20 ` Erik Aronesty
@ 2017-04-10 1:45 ` Thomas Daede
0 siblings, 0 replies; 41+ messages in thread
From: Thomas Daede @ 2017-04-10 1:45 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
[not found] ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
@ 2017-04-10 9:16 ` Jorge Timón
0 siblings, 0 replies; 41+ messages in thread
From: Jorge Timón @ 2017-04-10 9:16 UTC (permalink / raw)
To: Jimmy Song; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4524 bytes --]
On 9 Apr 2017 4:01 pm, "Jimmy Song" <jaejoon@gmail•com> 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" <jaejoon@gmail•com> 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 <jtimon@jtimon•cc> 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 <jtimon@jtimon•cc> wrote:
>>> >
>>> >
>>> > 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?
>>>
>>
>>
[-- Attachment #2: Type: text/html, Size: 7142 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 18:44 ` Erik Aronesty
2017-04-09 21:16 ` Jared Lee Richardson
@ 2017-04-10 14:34 ` Bram Cohen
2017-04-10 14:46 ` Bram Cohen
2017-04-10 15:25 ` g
3 siblings, 0 replies; 41+ messages in thread
From: Bram Cohen @ 2017-04-10 14:34 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2437 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 18:44 ` Erik Aronesty
2017-04-09 21:16 ` Jared Lee Richardson
2017-04-10 14:34 ` Bram Cohen
@ 2017-04-10 14:46 ` Bram Cohen
2017-04-10 15:25 ` g
3 siblings, 0 replies; 41+ messages in thread
From: Bram Cohen @ 2017-04-10 14:46 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1369 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-09 18:44 ` Erik Aronesty
` (2 preceding siblings ...)
2017-04-10 14:46 ` Bram Cohen
@ 2017-04-10 15:25 ` g
2017-04-10 18:17 ` Erik Aronesty
2017-04-11 9:31 ` Sancho Panza
3 siblings, 2 replies; 41+ messages in thread
From: g @ 2017-04-10 15:25 UTC (permalink / raw)
To: praxeology_guy, Bitcoin Protocol Discussion, Erik Aronesty
[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]
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 <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
[-- Attachment #2: Type: text/html, Size: 5160 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-10 15:25 ` g
@ 2017-04-10 18:17 ` Erik Aronesty
2017-04-11 2:39 ` g
2017-04-11 9:31 ` Sancho Panza
1 sibling, 1 reply; 41+ messages in thread
From: Erik Aronesty @ 2017-04-10 18:17 UTC (permalink / raw)
To: g; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4624 bytes --]
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 <g@cognitive•ch> 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 <https://pgp.mit.edu/pks/lookup?op=get&search=0x0A06E7F9E51DE2D6>
>
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 6913 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-10 18:17 ` Erik Aronesty
@ 2017-04-11 2:39 ` g
2017-04-11 18:39 ` Staf Verhaegen
0 siblings, 1 reply; 41+ messages in thread
From: g @ 2017-04-11 2:39 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5247 bytes --]
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 <erik@q32•com>, 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 <g@cognitive•ch> 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 <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
>
[-- Attachment #2: Type: text/html, Size: 8189 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-07 20:06 [bitcoin-dev] A Small Modification to Segwit Jimmy Song
2017-04-08 0:05 ` Jimmy Song
2017-04-08 1:48 ` praxeology_guy
@ 2017-04-11 7:59 ` Tom Zander
2017-04-11 13:25 ` Sancho Panza
2 siblings, 1 reply; 41+ messages in thread
From: Tom Zander @ 2017-04-11 7:59 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-10 15:25 ` g
2017-04-10 18:17 ` Erik Aronesty
@ 2017-04-11 9:31 ` Sancho Panza
2017-04-11 13:00 ` Jorge Timón
1 sibling, 1 reply; 41+ messages in thread
From: Sancho Panza @ 2017-04-11 9:31 UTC (permalink / raw)
To: g, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
> 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
[-- Attachment #2: Type: text/html, Size: 1279 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-11 9:31 ` Sancho Panza
@ 2017-04-11 13:00 ` Jorge Timón
0 siblings, 0 replies; 41+ messages in thread
From: Jorge Timón @ 2017-04-11 13:00 UTC (permalink / raw)
To: Sancho Panza; +Cc: 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?
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-11 7:59 ` Tom Zander
@ 2017-04-11 13:25 ` Sancho Panza
2017-04-11 14:40 ` Jimmy Song
0 siblings, 1 reply; 41+ messages in thread
From: Sancho Panza @ 2017-04-11 13:25 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 670 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-11 13:25 ` Sancho Panza
@ 2017-04-11 14:40 ` Jimmy Song
2017-04-11 21:25 ` Jorge Timón
0 siblings, 1 reply; 41+ messages in thread
From: Jimmy Song @ 2017-04-11 14:40 UTC (permalink / raw)
To: Sancho Panza; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 1860 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-11 2:39 ` g
@ 2017-04-11 18:39 ` Staf Verhaegen
0 siblings, 0 replies; 41+ messages in thread
From: Staf Verhaegen @ 2017-04-11 18:39 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-11 14:40 ` Jimmy Song
@ 2017-04-11 21:25 ` Jorge Timón
2017-04-11 23:42 ` Jimmy Song
0 siblings, 1 reply; 41+ messages in thread
From: Jorge Timón @ 2017-04-11 21:25 UTC (permalink / raw)
To: Jimmy Song; +Cc: bitcoin-dev
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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
> <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
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] A Small Modification to Segwit
2017-04-11 21:25 ` Jorge Timón
@ 2017-04-11 23:42 ` Jimmy Song
0 siblings, 0 replies; 41+ messages in thread
From: Jimmy Song @ 2017-04-11 23:42 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3370 bytes --]
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 <jtimon@jtimon•cc> wrote:
> On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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
> > <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
> >
>
[-- Attachment #2: Type: text/html, Size: 4793 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2017-04-11 23:42 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-07 20:06 [bitcoin-dev] A Small Modification to Segwit Jimmy Song
2017-04-08 0:05 ` Jimmy Song
2017-04-08 14:59 ` Luke Dashjr
2017-04-08 15:17 ` Jimmy Song
2017-04-08 16:05 ` Luke Dashjr
2017-04-08 16:16 ` Jimmy Song
2017-04-08 16:19 ` Timo Hanke
2017-04-08 1:48 ` praxeology_guy
2017-04-08 2:46 ` Jimmy Song
2017-04-08 8:33 ` Pavel Moravec
2017-04-08 14:35 ` Jimmy Song
2017-04-08 16:38 ` Pavel Moravec
2017-04-08 22:19 ` Jimmy Song
2017-04-08 18:15 ` praxeology_guy
2017-04-08 18:51 ` Eric Voskuil
2017-04-08 20:38 ` praxeology_guy
2017-04-09 11:46 ` Jorge Timón
2017-04-08 16:27 ` Jorge Timón
2017-04-08 17:22 ` Jorge Timón
2017-04-08 22:26 ` Jimmy Song
2017-04-09 11:48 ` Jorge Timón
2017-04-09 14:01 ` Jimmy Song
[not found] ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
2017-04-10 9:16 ` Jorge Timón
2017-04-09 18:44 ` Erik Aronesty
2017-04-09 21:16 ` Jared Lee Richardson
2017-04-09 23:51 ` David Vorick
2017-04-10 0:20 ` Erik Aronesty
2017-04-10 1:45 ` Thomas Daede
2017-04-10 14:34 ` Bram Cohen
2017-04-10 14:46 ` Bram Cohen
2017-04-10 15:25 ` g
2017-04-10 18:17 ` Erik Aronesty
2017-04-11 2:39 ` g
2017-04-11 18:39 ` Staf Verhaegen
2017-04-11 9:31 ` Sancho Panza
2017-04-11 13:00 ` Jorge Timón
2017-04-11 7:59 ` Tom Zander
2017-04-11 13:25 ` Sancho Panza
2017-04-11 14:40 ` Jimmy Song
2017-04-11 21:25 ` Jorge Timón
2017-04-11 23:42 ` Jimmy Song
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox