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
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
wrote:
> I've changed the proposal so only 8 bits are given to grinding so something
> like 20 bits are available for signaling.
>
> I have to say I'm at a loss here as to what's next? Should I make a new BIP
> or try to convince the auth
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
Bitcoi
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 o
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 th
The discussion is going offtopic. Can we please take vague discussions
about changing pow, so called "asic resistance", the environment etc
to bitcoin-disscuss or some other forum?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https:/
> 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
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
> a
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,
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 h
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
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 u
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" band
On 9 Apr 2017 4:01 pm, "Jimmy Song" wrote:
Jorge,
Why won't the attacker use asicboost too? (Please don't say because of
> patents)
>
>
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with ASICBoost,
you're right, the
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 red
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
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 "
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 t
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
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
Why won't the attacker use asicboost too? (Please don't say because of
patents)
On 9 Apr 2017 12:26 am, "Jimmy Song" wrote:
> Jorge,
>
> Suppose someone figures out an ASIC optimization that's completely
> unrelated that gives X% speed boost over your non-ASICBoosted
> implementation. If you ban
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
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 ASI
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
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 uni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/08/2017 11:15 AM, praxeology_guy via bitcoin-dev wrote:
> ASICBOOST causes Bitcoin's PoW to become more memory/latency
> throttled instead of raw computation throttled.
>
> There is the equation: Power Cost + Captial Rent + Labor ~= block
> re
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 mini
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,
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 i
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 mo
>
>
> 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 em
>
> 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:
Be
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
meth
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 cos
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 eff
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 incentive
> 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
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 spac
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 pa
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 th
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
41 matches
Mail list logo
