[ANN] Bitcoin PoW Upgrade Initiative

[tonymidlee]

The more I think about it , the more concerned I become. Ver and Wu are a bunch of crazy guys , and we must be prepared for the worst.

So, I for one strongly support the change of PoW algo.

I personally suggest some RAM-intensive problem, say 8GB at lease,  basically you need a lot of memory, which makes the ASIC impossible.

[1714735170]

1714735170

[1714735170]

1714735170

[1714735170]

1714735170

[bit_me]

Just adding my suggestion to counter the bot net fear mongers (aka altcoin gpu farm owners).

It would be a good idea to use a memory intensive pow, 6gb or more. This will eradicate the supposed threat from bot nets and allow for anyone with a CPU to mine with a simple ram upgrade. One CPU one vote. The bitcoin network can be secured once again by off the shelf parts.


I also think having this ready to go and on testnet as a counter to any malicious actors is great. Hopefully consensus can be reached but China pboc has already announced they want to make their own crypto coin we can not ignore the fact it is in their interest to try and undermine the open bitcoin network.

Edit: lol tonymidlee you beat me to it.

[Carlton Banks]

I'm into this idea.


But let's not fuck about, forget the "only in an insurmountable emergency" rhetoric, the emergency is already here.

The longer it takes to build support, the quicker proven bad actors like Bitmain will just develop a Keccak ASIC, if they've not started doing that already. Keccak PoW coins have already been tested in the market, doing 101% rigorous QA is a trade-off against the actual attack we're trying to fend off.


And if it's more appropriate to change the name, The Blockchain Formerly Known as Bitcoin, whatever, then so be it. The brand is the flimsiest aspect of the current Bitcoin's value proposition, it's arguably a highly desirable public relations move, as it then forces the attackers into coming up with different reasons why they're now desperate to "save" everyone from the evil developers who switched from Bitcoin to neoBitcoin.

i.e. If BU saved everyone from the evil Bitcoin Core devs, what is the need to follow them around, constantly trying to hard-fork the new project?

[nemgun]

I doubt Bitmain will loose time and money to develop a keccac ASIC, they did an enormous investment in the new farm.

The emergency is to make bitcoin compliant with an algorythm change, if the miners still wants to force a protocl change, then he will simply be activated. It can be used a threatening option.

Do not forget that miners have to follow the community, not force it to adopt the changes they want, if the miners want a more suitable version of bitcoin to mine, let them create their own, i will stay with bitcoin-core as long as they respect the original ideology, because i respect people who do so, and i respect their ideology.

I don't care about bitcoin price, nor about his name, these can change as long as the heart remains the same.

And Carlton Banks is right.

[HardwareReviewer]

A change of PoW as a quickfix (to fool currently manufactured ASICS) without too much risk of bugs can be as follows:

Instead of checking for n zero bits, implement checking for n one bits instead.

If you are bold, you can have the sequence of leading bits to check to be dependant on the trailing bits of the previous block.

[mmgen-py]

I like the idea of a memory-hard (Equihash?) PoW.

Another option would be a PoW that's randomized every retargeting period to make it ASIC-proof. A block hash would be used as the source of randomness.

[Guy Corem]

I like the idea of a memory-hard (Equihash?) PoW.

Another option would be a PoW that's randomized every retargeting period to make it ASIC-proof. A block hash would be used as the source of randomness.

https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.fv0s8ll36

[HardwareReviewer]

A long term ASIC-resistant solution would be where the PoW algo itself is dynamic:

The algo, consistent of base code blocks, will be compiled using (previous) block parameters.

So the exact algo will not be known beforehand, thus ASIC-resistant.

Does it make sense?

[BitUsher]

Jihan and bitmain have given plenty of statements they intend to attack -

https://twitter.com/gavinandresen/status/827904756525981697

https://archive.is/zjvh1

Preventing a minority-hashrate fork from confirming any transactions is a good idea. Nakomoto Consensus != unanimity.

https://www.cryptocoinsnews.com/bitcoin-market-needs-big-blocks-says-founder-btc-top-mining-pool/

“We have prepared $100 million USD to kill the small fork of CoreCoin, no matter what POW algorithm, sha256 or scrypt or X11 or any other GPU algorithm. Show me your money. We very much welcome a CoreCoin change to POS.”

We must prepare!

How about developing a ethash and Equihash PoW change so we can have ETC and Zcash merge mine bitcoin for much more security in case Zhuoer and other miners decide to spin up their GPU farms in an attack as they have claimed?  Having 2 different tested PoW algos would also have the benefit of being more difficult to create an asic for.  What do you guys think?

[Carlton Banks]

We must prepare!
[snip]
What do you guys think?

I told you already: "preparing" sounds too much like a euphemism for "fucking around"


Quit the bandying of hashing algorithms around already, we need to pre-empt their attack, not sit around waiting for it to happen. If the lead-time to develop a Keccak ASIC is long enough, we need to get the ball rolling, as soon as is diligently possible.

[mda]

Definitely more cpu processing time though.

I agree that giving the user control is the way to go, any change of PoW only kicks the can down the road.
What do you think about addition of a database where every miner is defined by his bitcoin address and every set of miners is defined by an unique string.
Then any block that includes a transaction containing incorrect string (miner missing in set) is rejected by the network.
This way rogue miners will be penalized with lost fees and signaling of code changes can be based on amount of earned fees instead of hashrate.

[BitUsher]

I told you already: "preparing" sounds too much like a euphemism for "fucking around"


Quit the bandying of hashing algorithms around already, we need to pre-empt their attack, not sit around waiting for it to happen. If the lead-time to develop a Keccak ASIC is long enough, we need to get the ball rolling, as soon as is diligently possible.

Simply changing the PoW pre-emtively sets a bad precedent because it harms good miners and long term investors and it will harm cryptocurrency in general by showing how flippant the community can be. Most of the users and core developers I have spoken to do not support pre-emptively changing the PoW algo, thus this HF would have very few following it , and we would not have the moral high ground. Also , merely preparing and testing is a form of pre-emption because it is enough to scare the hell out of miners so they do not attack in the first place . We already see Jihan opening up and looking for a compromise by the mere mention of a PoW change. We should not let this stop the work we are doing here though.

Perhaps there can be another way though to prepare .... where we develop a full node wallet , like Knots, where it simultaneously mines the other PoW algo on a testnet, where during times of contention users can enable this secondary mining and have the users ready to quickly HF over when ready.

[nemgun]

I told you already: "preparing" sounds too much like a euphemism for "fucking around"


Quit the bandying of hashing algorithms around already, we need to pre-empt their attack, not sit around waiting for it to happen. If the lead-time to develop a Keccak ASIC is long enough, we need to get the ball rolling, as soon as is diligently possible.

Simply changing the PoW pre-emtively sets a bad precedent because it harms good miners and long term investors and it will harm cryptocurrency in general by showing how flippant the community can be. Most of the users and core developers I have spoken to do not support pre-emptively changing the PoW algo, thus this HF would have very few following it , and we would not have the moral high ground.

Perhaps there can be another way though to prepare .... where we develop a full node wallet , like Knots, where it simultaneously mines the other PoW algo on a testnet, where during times of contention users can enable this secondary mining and have the users ready to quickly HF over when ready.

True, someone aleready experimented a multi algo coin, i forgot the name of the coin, but it can't bring good results as each algorithm requires custom GPU tweaks, so if you change the algo at each new block, miners will leave. Annother sollution would be to define an ASIC safe algo and use it, i don't know much about Keccac, but if luke-jr believes that he can be amended to fit in bitcoin-core code, then we should go for this sollution.

[BitUsher]

True, someone aleready experimented a multi algo coin, i forgot the name of the coin, but it can't bring good results as each algorithm requires custom GPU tweaks, so if you change the algo at each new block, miners will leave. Annother sollution would be to define an ASIC safe algo and use it, i don't know much about Keccac, but if luke-jr believes that he can be amended to fit in bitcoin-core code, then we should go for this sollution.

Fair concern ... but if the algos match ETC and zcash and merged mined couldn't this concern be negated as we would be bringing in 2 different communities to help secure Bitcoin? ETC and zcash folks get along with Bitcoin Core folks as well and share many similar values and we could benefit from  their collaboration against those who wish to attack immutability.

[tokona44]

Nice with CPU-only model. when do we start

[Rakete4]

The only way to upgrade the POW while keeping Bitcoin Bitcoin, is to add an extra POW as a soft fork.

I see there are mostly newbies posting in this thread.  Perhaps you should take some time to educate yourself about how bitocoin and blockchains work.

Feathercoin and some other coins changed proof of work. And guess what? It's still Feathercoin.

[BitUsher]

What do you guys think of Bram Cohens Proof of Space/Proof of Time?
I agree with him that PoW is a waste of energy, however all the experts say everything else is a joke and won't work. (Proof of Stake etc...)
So I guess our only option is to use PoW to secure the blockchain. But then again I'm no expert so I don't know if Proof of Space/Proof of Time is feasible or not.

Here he is talking about it on Whale Pool: https://youtu.be/HZOD3ytZLWo?t=2395

https://twitter.com/bramcohen/status/843856434999844864

I haven't talked about Burstcoin because it's busted. Any random junk can make a functional proof of work. That isn't true of proof of space

Proof of space is too hypothetical and not well tested to be considered

Thus we are left with these options

Keccak - Code already ready and ASIC resistant
Equihash - Code tested on zcash and ASIC resistant
Ethhash- Code tested on ETC and ASIC resistant
or combination of the above...

I would stay away from PoS because it is insecure and goes against bitcoins ethos. I would stay away from Cuckoo because we dont have code ready like others.

[Carlton Banks]

merely preparing and testing is a form of pre-emption because it is enough to scare the hell out of miners so they do not attack in the first place.

Or they prepare counter-measures to whatever is (publicly) tested, because they are too belligerent to back down, tail between legs. I seriously doubt your scenario.

We already see Jihan opening up and looking for a compromise by the mere mention of a PoW change.

Or buying time.


I pretty sure you don't get it.

Bitmain et al don't care about their infrastructure, or negotiating, I'm convinced you've never dealt with sufficiently pathological characters to understand this.

Forget their words, or rhetorical actions, and look strictly at what their primary mode of behaviour adds up to. They will do or say anything in order to get what they want; the destruction of this currency and it's economy.


Decisive, strike-first and belligerent evasive action is probably the only thing that can save the value in the Bitcoin network as it is today, and if you can't see that, and some surprise move that nobody (except apparently me) anticipated sends things into even more of a tailspin, then you and everyone else who are saying "let's talk and pro-crastinate on our options for another 9 months" will get everything you deserve.

To put it another way, imagine that those directing Bitmain's actions have a planned killer blow to land. Do you think they're going to announce it 6 months in advance on a public forum? We must act, we're being forced into an "eat or be eaten" situation, and you can't see it.

[nemgun]

Again Carlton is right, they are too beligerant to be trusted, they use any opportunity to blaim bitcoin-core devs, have anyone here checked the issue opened in BU's repo by gmaxwell ? It is an edifiant example of how they behave when it comes to core devs.
They actions untill know proofs they want to take over bitcoin, plus, their code is in appearance open sourced, but only to watch, if you want to contribute you need them to accept your modifications, and they some says they are glad to pay for others to work on BU code. This makes me thinking of some shitcoins, they always work like that.
Actions, either offencive, or deffencive, must be taken to ensure the future of bitcoin.
I don't know for you, but i won't accept a paypal 2.0
If miners take controle of bitcoin, they will for sure play with fees, or, who knows, maybe they will totally screw the code, the same way they screw BU code.

I have nothing agains capitalism, but it is really bad for decentralised projects, as they tend to add more centralisation in order to controle it. think about this.

[BitUsher]

merely preparing and testing is a form of pre-emption because it is enough to scare the hell out of miners so they do not attack in the first place.

Or they prepare counter-measures to whatever is (publicly) tested, because they are too belligerent to back down, tail between legs. I seriously doubt your scenario.

We already see Jihan opening up and looking for a compromise by the mere mention of a PoW change.

Or buying time.


I pretty sure you don't get it.

Bitmain et al don't care about their infrastructure, or negotiating, I'm convinced you've never dealt with sufficiently pathological characters to understand this.

Forget their words, or rhetorical actions, and look strictly at what their primary mode of behaviour adds up to. They will do or say anything in order to get what they want; the destruction of this currency and it's economy.


Decisive, strike-first and belligerent evasive action is probably the only thing that can save the value in the Bitcoin network as it is today, and if you can't see that, and some surprise move that nobody (except apparently me) anticipated sends things into even more of a tailspin, then you and everyone else who are saying "let's talk and pro-crastinate on our options for another 9 months" will get everything you deserve.

To put it another way, imagine that those directing Bitmain's actions have a planned killer blow to land. Do you think they're going to announce it 6 months in advance on a public forum? We must act, we're being forced into an "eat or be eaten" situation, and you can't see it.

Do you really believe that they can produce a Equihash, Keccak, or ETHhath asic in 6 months?

We should also be prepared with a secret backup HF algo tested and ready to go in the event they do indeed decide to attack with a secret ASIC, this should alleviate your concerns. If your concern is that they will fund gpu farms to attack , than we should be pushing for a Equihash and /or Ethhash merge mine option to protect ourselves.

There is something to be said with maintaining the moral high ground as well.... defensive only approach will attract many more people and thus much more investment , trust and security as we already see from the fact that almost everyone wants defensive only.