Bitcoin Forum
May 03, 2024, 07:29:08 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 »  All
  Print  
Author Topic: [ANN] Bitcoin PoW Upgrade Initiative  (Read 42931 times)
muyuu
Donator
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile
March 21, 2017, 02:34:14 AM
 #141

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

Maybe as a progressive but relatively quick PoW switch as a SF, it could be done. As Maxwell describes here: https://www.reddit.com/r/Bitcoin/comments/60j1zi/bram_cohen_bittorrents_creator_a_soft_fork_change/df6snyy/

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Actually I had not thought of going about it in this order and it makes an awful lot of sense.

I was thinking in having the contingency ready for the sudden one and the longer term progressive one to be applied in a more "relaxed" period. But actually the "I'm altering the deal, pray I don't alter it any further" approach makes even more sense from the incentives point of view.

-----

As for intricate, not proven combinations of multiple algorithms: I'd stay away. More risk that some attack vector is discovered in the future.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
1714721348
Hero Member
*
Offline Offline

Posts: 1714721348

View Profile Personal Message (Offline)

Ignore
1714721348
Reply with quote  #2

1714721348
Report to moderator
1714721348
Hero Member
*
Offline Offline

Posts: 1714721348

View Profile Personal Message (Offline)

Ignore
1714721348
Reply with quote  #2

1714721348
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714721348
Hero Member
*
Offline Offline

Posts: 1714721348

View Profile Personal Message (Offline)

Ignore
1714721348
Reply with quote  #2

1714721348
Report to moderator
1714721348
Hero Member
*
Offline Offline

Posts: 1714721348

View Profile Personal Message (Offline)

Ignore
1714721348
Reply with quote  #2

1714721348
Report to moderator
mmgen-py
Member
**
Offline Offline

Activity: 110
Merit: 26


View Profile WWW
March 21, 2017, 06:43:32 AM
 #142

Could someone fork Bitcoin-core and make the necessary changes so we can have a bitcoin-equihash-testnet?

Or maybe bitcoin-cuckoo-testnet? We need to evaluate the relative strengths/weaknesses of these two PoWs, I think, and decide on one of them.
linzheming
Newbie
*
Offline Offline

Activity: 10
Merit: 0



View Profile
March 21, 2017, 09:49:12 AM
 #143

If someone has relative cheap electricity, he can be sure to get comparative advantage as long as bitcoin use PoW.

The variable of block reward time make mining pools economical. small percentage of hashpower won't get steady income when it mined solo.

So the mining itself can always leads to a bit centralize under current consensus, what ever PoW you switched to. It's not the right solution for central mining.

mmgen-py
Member
**
Offline Offline

Activity: 110
Merit: 26


View Profile WWW
March 21, 2017, 10:19:48 AM
 #144

If someone has relative cheap electricity, he can be sure to get comparative advantage as long as bitcoin use PoW.

Unlike mining ASICs, the hardware required by memory-hard PoWs (DRAM) is available everywhere. This alone will lead to decentralization. Cheap electricity is available in other countries, so mining will no longer be monopolized by China.
rico666
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
March 21, 2017, 10:37:37 AM
 #145

If someone has relative cheap electricity, he can be sure to get comparative advantage as long as bitcoin use PoW.

Unlike mining ASICs, the hardware required by memory-hard PoWs (DRAM) is available everywhere. This alone will lead to decentralization. Cheap electricity is available in other countries, so mining will no longer be monopolized by China.


Even without cheap electricity: Hardware, that has been democratized (CPU, GPU) - we can speak of general purpose computational devices - is warranty enough for decentralization. Special purpose hardware, expensive AND available only from a few vendors (moreover concentrated in one region) is the exact opposite.

I for one would be happy to throw my Bitmain Devices out of the window (and I do run them on free electricity), for a CPU-only PoW.
Ok - I would bring them to a civic amenity site instead throwing them out of the window, but still...


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  Past BURST Activities
cloverme
Legendary
*
Offline Offline

Activity: 1512
Merit: 1054


SpacePirate.io


View Profile WWW
March 21, 2017, 12:35:16 PM
 #146

I'd like to see a change to PoW as well, but I highly doubt it will ever happen. Way too much mining happens in China and off of Bitmain asics, but this has been going on for years. That doesn't happen easily without the right kind of partnerships and influence in place. The war in mining is fueled by network difficulty, cost of power, and, coin price; it's a science to balance those to be able to mine at a profit, which is what these miners are doing.

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again. To address some the blockchain control concerns, I think the way that difficulty is leveraged would need to be modified as well. If you can just throw hardware at the difficulty, you'll just repeat the same path again in months/years. If asics are removed from the equation and replaced with cpu/memory, that will disrupt the mining swarm in the short term, but the mining collective would just regroup and retarget again where cpu/memory commodities can be leveraged in low cost environments where power and cooling are inexpensive. If you can keep adding n+1 nodes, you can just game the ability to solve a block with more hardware you control. However, I do think it's a better approach though to bring mining back to the node because it at least lowers the bar on power requirements on mining back to lower-cost equipment that gives entry nodes a better chance to solve a block.
mmgen-py
Member
**
Offline Offline

Activity: 110
Merit: 26


View Profile WWW
March 21, 2017, 01:30:27 PM
 #147

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again.

Racks of computers in datacenters is a given, but why only in China? Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3071



View Profile
March 21, 2017, 01:34:51 PM
 #148

Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

Exactly

Maybe we can't level the whole playing field definitively, but that's no argument for not taking the steps that can be made towards a free-er market in mining

(and that's true of all markets for all goods, there will always be cat and mouse protectionist games being played, the current cartel based world trade paradigm being the most salient example, for instance)

Vires in numeris
pedrog
Legendary
*
Offline Offline

Activity: 2786
Merit: 1031



View Profile
March 21, 2017, 02:38:44 PM
 #149

If PoW is changed can it still be called bitcoin?

If such fork happens what will they call it?

How different will this coin be from the original vision?

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again.

Racks of computers in datacenters is a given, but why only in China? Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

You can't still compete with their hardware prices and electricity costs.

Same stuff when GPU mining, I could buy the same GPUs as everyone else in the world but it was much more expensive for me and electricity costs would make my mining operation unprofitable.

krile
Hero Member
*****
Offline Offline

Activity: 746
Merit: 500



View Profile
March 21, 2017, 03:00:31 PM
 #150

Guys isn't one of the main reasons that Bitcoin is so valuable because of the crazy high mining difficulty and capital investment that is required for ASICs, electricity...etc.

To me it sounds like if you go back to GPU mining, you cut off one leg to the market, making the price of bitcoin plumet and stabilize much lower than it is now.

Wont the 16nm development wall that was reached recently, decentralize mining organically as time passes?

I think this "mining centralization" problem is only a temporary issue. And making the shift from ASIC to GPU just gives power to another entity (in most cases probably the same people since most ASIC farms also include a GPU farm).

I am not so naive to believe that going to GPU will magically put home hobby miners in control or decentralize the hashing in any significant way (maybe for a month, but then we are back to pools and farms being in control)

The PoS 0 reward solution (empiric example here: https://bitcointalk.org/index.php?topic=1801129.0)  would be much more attractive, putting some control to nodes and the people that actually own BTC.

muyuu
Donator
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile
March 21, 2017, 08:37:20 PM
 #151

Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

Exactly

Maybe we can't level the whole playing field definitively, but that's no argument for not taking the steps that can be made towards a free-er market in mining

(and that's true of all markets for all goods, there will always be cat and mouse protectionist games being played, the current cartel based world trade paradigm being the most salient example, for instance)

It may not be definitive and it may not be perfect, but it sure would be an improvement.

Bonus 1: being able to introduce script versioning and L2.

Bonus 2: the very threat of a future PoW change will make sure the miners will at least think twice about building up too much in-house and much less brazenly collude like they have already done.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
The One
Legendary
*
Offline Offline

Activity: 924
Merit: 1000



View Profile
March 21, 2017, 09:33:49 PM
 #152

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper:

Quote from: Bitcoin: A Peer-to-Peer Electronic Cash System, Section 6
The incentive may help encourage nodes to stay honest.
If a greedy attacker is able to assemble more CPU power than all the honest nodes,
he would have to choose between using it to defraud people by stealing back his payments,
or using it to generate new coins.

He ought to find it more profitable to play by the rules,
such rules that favour him with more new coins than everyone else combined,
than to undermine the system and the validity of his own wealth.



What if the mining pools are controlled by government (china) hell-bent of killing Bitcoin? The rules are then thrown out of the window.

..C..
.....................
........What is C?.........
..............
...........ICO            Dec 1st – Dec 30th............
       ............Open            Dec 1st- Dec 30th............
...................ANN thread      Bounty....................

dance
Full Member
***
Offline Offline

Activity: 189
Merit: 100


View Profile
March 21, 2017, 09:55:09 PM
 #153

Bitcoin should be alted to PoS.
muyuu
Donator
Legendary
*
Offline Offline

Activity: 980
Merit: 1000



View Profile
March 21, 2017, 10:39:07 PM
 #154

Bitcoin should be alted to PoS.

There's already a boatful of shitcoins.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
Fatman3001
Legendary
*
Offline Offline

Activity: 1526
Merit: 1013


Make Bitcoin glow with ENIAC


View Profile
March 21, 2017, 11:56:57 PM
 #155


Jeebus!

This thread is really catching on. Have any of you thought of maybe trying find a pragmatic solution to the issue at hand?

Can't we all just get along?


"I predict the Internet will soon go spectacularly supernova and in 1996 catastrophically collapse." - Robert Metcalfe, 1995
cloverme
Legendary
*
Offline Offline

Activity: 1512
Merit: 1054


SpacePirate.io


View Profile WWW
March 22, 2017, 12:25:33 AM
 #156

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again.

Racks of computers in datacenters is a given, but why only in China? Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

China has very inexpensive power, so they can run more systems less expensively than elsewhere. However, I get your point, while it's not the silver bullet it would certainly help level the playing field again, at least for a little while.
Mashuri
Full Member
***
Offline Offline

Activity: 135
Merit: 107


View Profile
March 22, 2017, 05:13:30 PM
 #157

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

Maybe as a progressive but relatively quick PoW switch as a SF, it could be done. As Maxwell describes here: https://www.reddit.com/r/Bitcoin/comments/60j1zi/bram_cohen_bittorrents_creator_a_soft_fork_change/df6snyy/

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Actually I had not thought of going about it in this order and it makes an awful lot of sense.

I was thinking in having the contingency ready for the sudden one and the longer term progressive one to be applied in a more "relaxed" period. But actually the "I'm altering the deal, pray I don't alter it any further" approach makes even more sense from the incentives point of view.

-----

As for intricate, not proven combinations of multiple algorithms: I'd stay away. More risk that some attack vector is discovered in the future.

The more I think about it the more I believe a SF PoW change is the best option -- even in an emergency.  It's the least disruptive to users and businesses with alternate clients.  Exchanges, wallet providers, etc should only need to set up a border node and they'll have all the time they need to upgrade their legacy systems.  AFAIK, this can't be done with a HF and would cause a lot more economic disruption.

shier7
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
March 23, 2017, 06:39:15 AM
 #158

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

Maybe as a progressive but relatively quick PoW switch as a SF, it could be done. As Maxwell describes here: https://www.reddit.com/r/Bitcoin/comments/60j1zi/bram_cohen_bittorrents_creator_a_soft_fork_change/df6snyy/

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Actually I had not thought of going about it in this order and it makes an awful lot of sense.

I was thinking in having the contingency ready for the sudden one and the longer term progressive one to be applied in a more "relaxed" period. But actually the "I'm altering the deal, pray I don't alter it any further" approach makes even more sense from the incentives point of view.

-----

As for intricate, not proven combinations of multiple algorithms: I'd stay away. More risk that some attack vector is discovered in the future.

The more I think about it the more I believe a SF PoW change is the best option -- even in an emergency.  It's the least disruptive to users and businesses with alternate clients.  Exchanges, wallet providers, etc should only need to set up a border node and they'll have all the time they need to upgrade their legacy systems.  AFAIK, this can't be done with a HF and would cause a lot more economic disruption.

I'm pretty much there also. Block needs to be SHA2'd just like before... as well as "something else'd" to be valid. If we roll out SW and ideally LN strikes at the exact same time... the affect would be pretty effective. In my understanding-- there would still be the difficulty lag, which would be overcome with SW/LN ... no hardfork. What's not to like?

How about (just another fun log to throw on the fire... feel free to pick it apart... not too thoroughly though out...) miners need to hash THE ENTIRE BLOCKCHAIN + the new block?
Pascal6662
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
March 23, 2017, 06:47:35 AM
 #159

Any chance of coming up with something that has benefits outside Bitcoin as well?  Similar to GridCoin or CureCoin?
shier7
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
March 23, 2017, 07:26:52 AM
Last edit: March 23, 2017, 07:49:45 AM by shier7
 #160

...ok... so just tried to hash the entire .bitcoin/blocks on my node... that takes a long time lol. Something like: (following) might work better/ be more practical...

sha256(sha256( nonce + NormalValidBlockData + hash2(hash2(first n bytes of all previous blocks/blockhashes concatenated + nonce)) ))

where n is difficulty2...

come to think of it... there really is no need for difficulty2... difficulty1 (the normal difficulty) will have to come way down after the block interval goes way up due to 1) asic deprecation and 2) more complex hash function...

effectively putting the big hash in the inner loop of the little hash.

This would be very difficult to build an asic for... specialized hardware is fast ram. a commodity.

incentives to keep blockchain size down. way easier to verify than to hash... but it breaks node pruning.

Could be very simple to include the hash2(hash2()) value... just encode it in a transaction in the block. Nodes check to see if the transaction exists by calculating the hash per the reported nonce and looking at OP_RETURN or something... if not... the block is invalid.

...another idea to prevent an initial shock to the block creation time is to initialize n as a function of the regular difficulty such that n = 1 at the current difficulty (on flag day).
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!