Discussion:
A Small Modification to Segwit
Add Reply
Jimmy Song via bitcoin-dev
2017-04-07 20:06:39 UTC
Reply
Permalink
Raw Message
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.
Jimmy Song via bitcoin-dev
2017-04-08 00:05:16 UTC
Reply
Permalink
Raw Message
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.
Post by Jimmy Song via bitcoin-dev
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.
Luke Dashjr via bitcoin-dev
2017-04-08 14:59:12 UTC
Reply
Permalink
Raw Message
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
Post by Jimmy Song via bitcoin-dev
I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 then is modified so that bits 16 to 23 are now no longer
usable.
Post by Jimmy Song via bitcoin-dev
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.
Luke Dashjr via bitcoin-dev
2017-04-08 16:05:09 UTC
Reply
Permalink
Raw Message
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
Jimmy Song via bitcoin-dev
2017-04-08 16:16:05 UTC
Reply
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
No, it isn't allowed right now. Doing it wouldn't invalidate blocks, but it
would clearly be an attack on the network and cause harm. The same as if
miners were to maliciously mine only empty blocks.
What's your definition of "allowed" then? Because a miner definitely can
mine only empty blocks and a miner definitely can do overt ASICBoost (using
as little as 1 bit of the version field) right now. I thought you meant
allowed in the sense that if a block is allowed, it is a valid block on the
network. It sounds like you mean something else, perhaps, "a block is
allowed if it doesn't cause harm to the network." I'm not sure how you
quantify that as that seems pretty subjective.
Timo Hanke via bitcoin-dev
2017-04-08 16:19:01 UTC
Reply
Permalink
Raw Message
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 <
Post by Jimmy Song via bitcoin-dev
I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 then is modified so that bits 16 to 23 are now no longer
usable.
Post by Jimmy Song via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
praxeology_guy via bitcoin-dev
2017-04-08 01:48:01 UTC
Reply
Permalink
Raw Message
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
Jimmy Song via bitcoin-dev
2017-04-08 02:46:29 UTC
Reply
Permalink
Raw Message
Praxeology Guy,

Why would the actual end users of Bitcoin (the long term and short term
Post by praxeology_guy via bitcoin-dev
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.
Post by praxeology_guy via bitcoin-dev
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.
Pavel Moravec via bitcoin-dev
2017-04-08 08:33:01 UTC
Reply
Permalink
Raw Message
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.
Jimmy Song via bitcoin-dev
2017-04-08 14:35:30 UTC
Reply
Permalink
Raw Message
Pavel,

Until all miners update (firmware or hardware), the change encourages
Post by Pavel Moravec via bitcoin-dev
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.
Post by Pavel Moravec via bitcoin-dev
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.
Post by Pavel Moravec via bitcoin-dev
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.
Post by Pavel Moravec via bitcoin-dev
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
Pavel Moravec via bitcoin-dev
2017-04-08 16:38:03 UTC
Reply
Permalink
Raw Message
Jimmy,
Post by Jimmy Song via bitcoin-dev
Post by Pavel Moravec via bitcoin-dev
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.
Post by Jimmy Song via bitcoin-dev
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.
Post by Jimmy Song via bitcoin-dev
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
Jimmy Song via bitcoin-dev
2017-04-08 22:19:11 UTC
Reply
Permalink
Raw Message
Pavel,
Post by Pavel Moravec via bitcoin-dev
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.
Post by Pavel Moravec via bitcoin-dev
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.
praxeology_guy via bitcoin-dev
2017-04-08 18:15:43 UTC
Reply
Permalink
Raw Message
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
Eric Voskuil via bitcoin-dev
2017-04-08 18:51:32 UTC
Reply
Permalink
Raw Message
Post by praxeology_guy via bitcoin-dev
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
praxeology_guy via bitcoin-dev
2017-04-08 20:38:43 UTC
Reply
Permalink
Raw Message
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
Jorge Timón via bitcoin-dev
2017-04-09 11:46:22 UTC
Reply
Permalink
Raw Message
On 8 Apr 2017 8:31 pm, "praxeology_guy via bitcoin-dev" <
bitcoin-***@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.
Jorge Timón via bitcoin-dev
2017-04-08 16:27:48 UTC
Reply
Permalink
Raw Message
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" <
bitcoin-***@lists.linuxfoundation.org> wrote:

Praxeology Guy,

Why would the actual end users of Bitcoin (the long term and short term
Post by praxeology_guy via bitcoin-dev
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?
Jorge Timón via bitcoin-dev
2017-04-08 17:22:22 UTC
Reply
Permalink
Raw Message
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".
Post by Jorge Timón via bitcoin-dev
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
Praxeology Guy,
Post by praxeology_guy via bitcoin-dev
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?
Jimmy Song via bitcoin-dev
2017-04-08 22:26:25 UTC
Reply
Permalink
Raw Message
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
Post by Jorge Timón via bitcoin-dev
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.
Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).
But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.
To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".
Post by Jorge Timón via bitcoin-dev
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
Praxeology Guy,
Post by praxeology_guy via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
have an advantage. But think of it this way, if some newer ASIC
optimization
Post by Jorge Timón via bitcoin-dev
comes up, would you rather have a non-ASICBoosted hash rate to defend
with
Post by Jorge Timón via bitcoin-dev
or an ASICBoosted hash rate? Certainly, the latter, being higher will
secure
Post by Jorge Timón via bitcoin-dev
the Bitcoin network better against newer optimizations.
Why?
Jorge Timón via bitcoin-dev
2017-04-09 11:48:27 UTC
Reply
Permalink
Raw Message
Why won't the attacker use asicboost too? (Please don't say because of
patents)
Post by Jimmy Song via bitcoin-dev
Jorge,
Suppose someone figures out an ASIC optimization that's completely
unrelated that gives X% speed boost over your non-ASICBoosted
implementation. If you ban ASICBoost, someone with this optimization can
get 51% of the network by adding N machines with their new optimization. If
you allow ASICBoost and assuming this gets a 20% speed boost over
non-ASICBoosted hardware, someone with this optimization would need 1.2N
machines to get 51%. The network in that sense is 20% stronger against this
attack in terms of cost.
Jimmy
Post by Jorge Timón via bitcoin-dev
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.
Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).
But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.
To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".
Post by Jorge Timón via bitcoin-dev
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
Praxeology Guy,
Post by praxeology_guy via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
Post by praxeology_guy via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
have an advantage. But think of it this way, if some newer ASIC
optimization
Post by Jorge Timón via bitcoin-dev
comes up, would you rather have a non-ASICBoosted hash rate to defend
with
Post by Jorge Timón via bitcoin-dev
or an ASICBoosted hash rate? Certainly, the latter, being higher will
secure
Post by Jorge Timón via bitcoin-dev
the Bitcoin network better against newer optimizations.
Why?
Jimmy Song via bitcoin-dev
2017-04-09 14:01:01 UTC
Reply
Permalink
Raw Message
Jorge,

Why won't the attacker use asicboost too? (Please don't say because of
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
Post by Jimmy Song via bitcoin-dev
Jorge,
Suppose someone figures out an ASIC optimization that's completely
unrelated that gives X% speed boost over your non-ASICBoosted
implementation. If you ban ASICBoost, someone with this optimization can
get 51% of the network by adding N machines with their new optimization. If
you allow ASICBoost and assuming this gets a 20% speed boost over
non-ASICBoosted hardware, someone with this optimization would need 1.2N
machines to get 51%. The network in that sense is 20% stronger against this
attack in terms of cost.
Jimmy
Post by Jorge Timón via bitcoin-dev
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.
Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).
But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.
To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".
Post by Jorge Timón via bitcoin-dev
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
Praxeology Guy,
Post by praxeology_guy via bitcoin-dev
Why would the actual end users of Bitcoin (the long term and short
term
Post by Jorge Timón via bitcoin-dev
Post by praxeology_guy via bitcoin-dev
owners of bitcoins) who run fully verifying nodes want to change
Bitcoin
Post by Jorge Timón via bitcoin-dev
Post by praxeology_guy via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
have an advantage. But think of it this way, if some newer ASIC
optimization
Post by Jorge Timón via bitcoin-dev
comes up, would you rather have a non-ASICBoosted hash rate to defend
with
Post by Jorge Timón via bitcoin-dev
or an ASICBoosted hash rate? Certainly, the latter, being higher will
secure
Post by Jorge Timón via bitcoin-dev
the Bitcoin network better against newer optimizations.
Why?
Jorge Timón via bitcoin-dev
2017-04-10 09:16:50 UTC
Reply
Permalink
Raw Message
On 9 Apr 2017 4:01 pm, "Jimmy Song" <***@gmail.com> wrote:

Jorge,

Why won't the attacker use asicboost too? (Please don't say because of
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
Post by Jimmy Song via bitcoin-dev
Jorge,
Suppose someone figures out an ASIC optimization that's completely
unrelated that gives X% speed boost over your non-ASICBoosted
implementation. If you ban ASICBoost, someone with this optimization can
get 51% of the network by adding N machines with their new optimization. If
you allow ASICBoost and assuming this gets a 20% speed boost over
non-ASICBoosted hardware, someone with this optimization would need 1.2N
machines to get 51%. The network in that sense is 20% stronger against this
attack in terms of cost.
Jimmy
Post by Jorge Timón via bitcoin-dev
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.
Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).
But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.
To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".
Post by Jorge Timón via bitcoin-dev
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
Praxeology Guy,
Post by praxeology_guy via bitcoin-dev
Why would the actual end users of Bitcoin (the long term and short
term
Post by Jorge Timón via bitcoin-dev
Post by praxeology_guy via bitcoin-dev
owners of bitcoins) who run fully verifying nodes want to change
Bitcoin
Post by Jorge Timón via bitcoin-dev
Post by praxeology_guy via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
have an advantage. But think of it this way, if some newer ASIC
optimization
Post by Jorge Timón via bitcoin-dev
comes up, would you rather have a non-ASICBoosted hash rate to defend
with
Post by Jorge Timón via bitcoin-dev
or an ASICBoosted hash rate? Certainly, the latter, being higher will
secure
Post by Jorge Timón via bitcoin-dev
the Bitcoin network better against newer optimizations.
Why?
Erik Aronesty via bitcoin-dev
2017-04-09 18:44:47 UTC
Reply
Permalink
Raw Message
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 <
Post by praxeology_guy via bitcoin-dev
Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term
owners of bitcoins) who run fully verifying nodes want to change Bitcoin
policy in order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of
patented PoW algorithms instead of making changes to enable them.
Thanks,
Praxeology Guy
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jared Lee Richardson via bitcoin-dev
2017-04-09 21:16:26 UTC
Reply
Permalink
Raw Message
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" <
Post by Erik Aronesty via bitcoin-dev
Curious: I'm not sure why a serious discussion of POW change is not on the
table as a part of a longer-term roadmap.
Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
the proven, np-complete graph-theoretic or polygon manipulation POW would
keep Bitcoin in commodity hardware and out of the hands of centralized
manufacturing for many years.
Clearly a level-playing field is critical to keeping centralization from
being a "defining feature" of Bitcoin over the long term. I've heard the
term "level playing field" bandied about quite a bit. And it seems to me
that the risk of state actor control and botnet attacks is less than
state-actor manipulation of specialized manufacturing of "SHA-256 forever"
hardware. Indeed, the reliance on a fairly simple hash seems less and
less likely a "feature" and more of a baggage.
Perhaps regular, high-consensus POW changes might even be *necessary* as a
part of good maintenance of cryptocurrency in general. Killing the
existing POW, and using an as-yet undefined, but deployment-bit ready POW
field to flip-flop between the current and the "next one" every 8 years or
or so, with a ramp down beginning in the 7th year.... A stub function that
is guaranteed to fail unless a new consensus POW is selected within 7
years.
Something like that?
Haven't thought about it *that* much, but I think the network would
respond well to a well known cutover date. This would enable
rapid-response to quantum tech, or some other needed POW switch as well...
because the mechanisms would be in-place and ready to switch as needed.
Lots of people seem to panic over POW changes as "irresponsible", but it's
only irresponsible if done irresponsibly.
On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
Post by praxeology_guy via bitcoin-dev
Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term
owners of bitcoins) who run fully verifying nodes want to change Bitcoin
policy in order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of
patented PoW algorithms instead of making changes to enable them.
Thanks,
Praxeology Guy
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
David Vorick via bitcoin-dev
2017-04-09 23:51:29 UTC
Reply
Permalink
Raw Message
On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
bitcoin-***@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.
Post by Erik Aronesty via bitcoin-dev
Curious: I'm not sure why a serious discussion of POW change is not on the
table as a part of a longer-term roadmap.
Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
the proven, np-complete graph-theoretic or polygon manipulation POW would
keep Bitcoin in commodity hardware and out of the hands of centralized
manufacturing for many years.
Clearly a level-playing field is critical to keeping centralization from
being a "defining feature" of Bitcoin over the long term. I've heard the
term "level playing field" bandied about quite a bit. And it seems to me
that the risk of state actor control and botnet attacks is less than
state-actor manipulation of specialized manufacturing of "SHA-256 forever"
hardware. Indeed, the reliance on a fairly simple hash seems less and
less likely a "feature" and more of a baggage.
Perhaps regular, high-consensus POW changes might even be *necessary* as a
part of good maintenance of cryptocurrency in general. Killing the
existing POW, and using an as-yet undefined, but deployment-bit ready POW
field to flip-flop between the current and the "next one" every 8 years or
or so, with a ramp down beginning in the 7th year.... A stub function that
is guaranteed to fail unless a new consensus POW is selected within 7
years.
Something like that?
Haven't thought about it *that* much, but I think the network would
respond well to a well known cutover date. This would enable
rapid-response to quantum tech, or some other needed POW switch as well...
because the mechanisms would be in-place and ready to switch as needed.
Lots of people seem to panic over POW changes as "irresponsible", but it's
only irresponsible if done irresponsibly.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-***@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.
Erik Aronesty via bitcoin-dev
2017-04-10 00:20:49 UTC
Reply
Permalink
Raw Message
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...
Post by David Vorick via bitcoin-dev
On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
I can speak from personal experience regarding another very prominent
altcoin that attempted to utilize an asic-resistant proof of work
algorithm, it is only a matter of time before the "asic resistant"
algorithm gets its own Asics. The more complicated the algorithm, the more
secretive the asic technology is developed. Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs. I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.
On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <
Post by Erik Aronesty via bitcoin-dev
Curious: I'm not sure why a serious discussion of POW change is not on
the table as a part of a longer-term roadmap.
Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
the proven, np-complete graph-theoretic or polygon manipulation POW would
keep Bitcoin in commodity hardware and out of the hands of centralized
manufacturing for many years.
Clearly a level-playing field is critical to keeping centralization from
being a "defining feature" of Bitcoin over the long term. I've heard the
term "level playing field" bandied about quite a bit. And it seems to me
that the risk of state actor control and botnet attacks is less than
state-actor manipulation of specialized manufacturing of "SHA-256 forever"
hardware. Indeed, the reliance on a fairly simple hash seems less and
less likely a "feature" and more of a baggage.
Perhaps regular, high-consensus POW changes might even be *necessary* as
a part of good maintenance of cryptocurrency in general. Killing the
existing POW, and using an as-yet undefined, but deployment-bit ready POW
field to flip-flop between the current and the "next one" every 8 years or
or so, with a ramp down beginning in the 7th year.... A stub function that
is guaranteed to fail unless a new consensus POW is selected within 7
years.
Something like that?
Haven't thought about it *that* much, but I think the network would
respond well to a well known cutover date. This would enable
rapid-response to quantum tech, or some other needed POW switch as well...
because the mechanisms would be in-place and ready to switch as needed.
Lots of people seem to panic over POW changes as "irresponsible", but
it's only irresponsible if done irresponsibly.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
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.
Thomas Daede via bitcoin-dev
2017-04-10 01:45:24 UTC
Reply
Permalink
Raw Message
Post by Erik Aronesty via bitcoin-dev
Have you read the cuckoo cycle paper? Finding cycles in massive graphs
is just about the worst thing to use an ASIC for.
It'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.
Bram Cohen via bitcoin-dev
2017-04-10 14:34:47 UTC
Reply
Permalink
Raw Message
On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <
Post by Erik Aronesty via bitcoin-dev
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.
Bram Cohen via bitcoin-dev
2017-04-10 14:46:35 UTC
Reply
Permalink
Raw Message
On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <
Post by Erik Aronesty via bitcoin-dev
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.
Erik Aronesty via bitcoin-dev
2017-04-10 18:17:03 UTC
Reply
Permalink
Raw Message
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.
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>
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 <
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 <
Post by praxeology_guy via bitcoin-dev
Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term
owners of bitcoins) who run fully verifying nodes want to change Bitcoin
policy in order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of
patented PoW algorithms instead of making changes to enable them.
Thanks,
Praxeology Guy
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
g via bitcoin-dev
2017-04-11 02:39:32 UTC
Reply
Permalink
Raw Message
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
***@cognitive.ch
GPG Key
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.
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
GPG Key
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.
Post by praxeology_guy via bitcoin-dev
Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term owners of bitcoins) who run fully verifying nodes want to change Bitcoin policy in order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of patented PoW algorithms instead of making changes to enable them.
Thanks,
Praxeology Guy
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Staf Verhaegen via bitcoin-dev
2017-04-11 18:39:11 UTC
Reply
Permalink
Raw Message
Post by g via bitcoin-dev
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.
Sancho Panza via bitcoin-dev
2017-04-11 09:31:43 UTC
Reply
Permalink
Raw Message
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
Jorge Timón via bitcoin-dev
2017-04-11 13:00:29 UTC
Reply
Permalink
Raw Message
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?
Tom Zander via bitcoin-dev
2017-04-11 07:59:33 UTC
Reply
Permalink
Raw Message
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.
Post by Jimmy Song via bitcoin-dev
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
Sancho Panza via bitcoin-dev
2017-04-11 13:25:21 UTC
Reply
Permalink
Raw Message
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.
Jimmy Song via bitcoin-dev
2017-04-11 14:40:28 UTC
Reply
Permalink
Raw Message
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 <
Post by Tom Zander via bitcoin-dev
Post by Tom Zander via bitcoin-dev
The version field is still needed to actually allow future block version
upgrades. We would cut off our road forward if that were to be blocked.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2017-04-11 21:25:45 UTC
Reply
Permalink
Raw Message
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
Post by Jimmy Song via bitcoin-dev
I've changed the proposal so only 8 bits are given to grinding so something
like 20 bits are available for signaling.
I have to say I'm at a loss here as to what's next? Should I make a new BIP
or try to convince the authors of BIP141 to modify their BIP? Could someone
inform me on the next part of the process?
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.
Post by Jimmy Song via bitcoin-dev
On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
Post by Sancho Panza via bitcoin-dev
Post by Tom Zander via bitcoin-dev
The version field is still needed to actually allow future block version
upgrades. We would cut off our road forward if that were to be blocked.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jimmy Song via bitcoin-dev
2017-04-11 23:42:41 UTC
Reply
Permalink
Raw Message
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
Post by Jorge Timón via bitcoin-dev
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
Post by Jimmy Song via bitcoin-dev
I've changed the proposal so only 8 bits are given to grinding so
something
Post by Jimmy Song via bitcoin-dev
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
Post by Jimmy Song via bitcoin-dev
or try to convince the authors of BIP141 to modify their BIP? Could
someone
Post by Jimmy Song via bitcoin-dev
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.
Post by Jimmy Song via bitcoin-dev
On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
Post by Sancho Panza via bitcoin-dev
Post by Tom Zander via bitcoin-dev
The version field is still needed to actually allow future block
version
Post by Jimmy Song via bitcoin-dev
Post by Sancho Panza via bitcoin-dev
Post by Tom Zander via bitcoin-dev
upgrades. We would cut off our road forward if that were to be
blocked.
Post by Jimmy Song via bitcoin-dev
Post by Sancho Panza via bitcoin-dev
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
Post by Jimmy Song via bitcoin-dev
Post by Sancho Panza via bitcoin-dev
3 bits are still reserved for other purposes. One of them could perhaps
be
Post by Jimmy Song via bitcoin-dev
Post by Sancho Panza via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...