Bitcoin Forum
June 24, 2017, 09:07:05 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 »  All
  Print  
Author Topic: [ANN] Bitcoin PoW Upgrade Initiative  (Read 30573 times)
Mashuri
Full Member
***
Offline Offline

Activity: 135


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

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.

1498338425
Hero Member
*
Offline Offline

Posts: 1498338425

View Profile Personal Message (Offline)

Ignore
1498338425
Reply with quote  #2

1498338425
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498338425
Hero Member
*
Offline Offline

Posts: 1498338425

View Profile Personal Message (Offline)

Ignore
1498338425
Reply with quote  #2

1498338425
Report to moderator
1498338425
Hero Member
*
Offline Offline

Posts: 1498338425

View Profile Personal Message (Offline)

Ignore
1498338425
Reply with quote  #2

1498338425
Report to moderator
shier7
Newbie
*
Offline Offline

Activity: 6


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

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: 1


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

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


View Profile
March 23, 2017, 07:26:52 AM
 #164

...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).
muyuu
Donator
Legendary
*
Offline Offline

Activity: 952



View Profile
March 23, 2017, 12:42:41 PM
 #165

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

No, because that would be braindead unless someone comes with a breakthrough that makes an arbitrary/useful PoW rock-solid and didn't need a massive amount of extra gossiping in the network.

Sadly this doesn't exist AFAIK and these two are completely broken.

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

Activity: 61


View Profile
March 23, 2017, 04:07:13 PM
 #166

It's profoundly unreasonable to pass off unbacked assertions as any form of reason


I've provided sound reasoning already, refute it.

I would if I could find it, but from what I see you've taken some facts, made up a story around them, and then because your story fits the facts you say it must be true. But of course your story fits the fact, you used them to make it up.

Yes, it reads as conspiracy theory mixed with confirmation bias.
CascadiaCC
Member
**
Offline Offline

Activity: 61


View Profile
March 23, 2017, 04:09:59 PM
 #167

Why would it be too late after an attack to HF? A few txs get stolen or blocked?

For a similar reason you're giving not to pre-empt it: building support for the new idea. It's possible that too many people will be psychologically impacted by the success of the attack, and consequently do what you're suggesting is wrong with my approach (despite the fact I've made no emotional arguements at all): allow emotions to dictate their decision instead of reason.

If we engage people to support pre-emptive action, a determined mindset would replace a fatalistic reaction. It's about harnessing a positive psychological feedback loop instead of a negative psychological feedback loop.


By my estimates 95% won't preemptively fork the PoW algo ... do you really think you can convince them all to preemptively HF?

Including Bitmain's current hashrate %? Clearly not. A PoW fork only needs to get the support of the miners who don't want to be ruled by a malign majority, although I'm seeing an obvious problem; how to measure that. Setting a block height activation would invite counter measures. Not sure how it could be achieved.


Sounds like the "Coalition of the Willing" and "Weapons of Mass Destruction" argument which lead to the disaster that was the Iraq pre-emptive strike/invasion and war.
CascadiaCC
Member
**
Offline Offline

Activity: 61


View Profile
March 23, 2017, 04:15:57 PM
 #168

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

Here's their thread: https://bitcointalk.org/index.php?topic=657601.0
CascadiaCC
Member
**
Offline Offline

Activity: 61


View Profile
March 23, 2017, 04:50:46 PM
 #169

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.

FYI: Electricity in parts of Washington State, USA is as cheap or even cheaper than China due to the hydroelectic PUDs. That's why McAffee/Bitmain are building their facility there.
awds1th
Member
**
Offline Offline

Activity: 60


View Profile
March 23, 2017, 06:13:35 PM
 #170

changing pow would be a temporary method of opposing the chinese miners. it should be a tool used alongside a UASF if there is going to be one.

mmgen-py
Member
**
Offline Offline

Activity: 68


View Profile WWW
March 23, 2017, 06:39:54 PM
 #171

changing pow would be a temporary method of opposing the chinese miners. it should be a tool used alongside a UASF if there is going to be one.

Introducing a very moderate (say 5% of the block reward) PoWA as a soft fork would allow the miners to stay in business while putting them on notice that if they misbehave in the future we can up that percentage with a new soft fork. This would be a permanent rather than temporary measure that would create a new class of DRAM miners.
muyuu
Donator
Legendary
*
Offline Offline

Activity: 952



View Profile
March 23, 2017, 07:01:16 PM
 #172

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

Here's their thread: https://bitcointalk.org/index.php?topic=657601.0

Why? We're talking about Bitcoin. Unless you mean to one of their concrete PoWs for some reason. I didn't see much documentation on their PoWs there.

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

Activity: 61


View Profile
March 23, 2017, 08:31:43 PM
 #173

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

Here's their thread: https://bitcointalk.org/index.php?topic=657601.0

Why? We're talking about Bitcoin. Unless you mean to one of their concrete PoWs for some reason. I didn't see much documentation on their PoWs there.

Yes. Specifically, we're talking about changing Bitcoin's Proof-of-Work.

OK try this then:
https://en.wikipedia.org/wiki/SHA-3

I referenced Nexus as a real-world example because of their use of a combination of Skein-1024 and Keccak-1600 algorithms which leads to an ASIC and quantum computer Proof-Of-Work which is what this thread was about.

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

SHA-3 does that.

For reference here are the lifespans of various cryptographic hash functions including our beloved SHA-2(56)
http://valerieaurora.org/hash.html

As you can see SHA-3 (Keccak) is the most secure and it has been brought up earlier in this thread.
tromp
Hero Member
*****
Offline Offline

Activity: 494


View Profile
March 23, 2017, 08:38:32 PM
 #174

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

SHA-3 does that.

All SHA-3 candidates are rather ASIC-friendly, and Hashcash with such a hash function is highly
vulnerable to quantum speedup with Grover's algorithm.
zooko
Newbie
*
Offline Offline

Activity: 20


View Profile
March 23, 2017, 08:49:03 PM
 #175

Whenever any cites that Val Aurora article, please follow-up and link to this newer, better, article:

https://z.cash/technology/history-of-hash-function-attacks.html

blog post about this article when we posted it:

https://z.cash/blog/hash-functions.html

Sincerely,

Zooko

testing image: https://z.cash/images/hash-functions-chronology.png

testing image: http://i.imgur.com/rAxg7qP.png
muyuu
Donator
Legendary
*
Offline Offline

Activity: 952



View Profile
March 23, 2017, 09:17:06 PM
 #176

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

Here's their thread: https://bitcointalk.org/index.php?topic=657601.0

Why? We're talking about Bitcoin. Unless you mean to one of their concrete PoWs for some reason. I didn't see much documentation on their PoWs there.

Yes. Specifically, we're talking about changing Bitcoin's Proof-of-Work.

OK try this then:
https://en.wikipedia.org/wiki/SHA-3

I referenced Nexus as a real-world example because of their use of a combination of Skein-1024 and Keccak-1600 algorithms which leads to an ASIC and quantum computer Proof-Of-Work which is what this thread was about.

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

SHA-3 does that.

For reference here are the lifespans of various cryptographic hash functions including our beloved SHA-2(56)
http://valerieaurora.org/hash.html

As you can see SHA-3 (Keccak) is the most secure and it has been brought up earlier in this thread.


Well, if you have been paying attention, Luke already coded a Keccak PoW change last year. It would literally take just changing the activation block if that was the change.

But thanks for your input.

I'm very familiar with it. I have coded a Keccak lib myself and a BLAKE as well.

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

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

Activity: 68


View Profile WWW
March 23, 2017, 09:56:59 PM
 #177

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

Here's my proposal: Implement the new PoW as a PoWA (proof-of-work additions) soft fork. New PoW is memory-hard Cuckoo Cycle (whose creator has joined the discussion here), or possibly Equihash.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

Conservative approach allows us to use relatively untested PoW algorithm safely, as blockchain continues to be 95% secured by old SHA2 hashing power. Getting the larger community behind a conservative solution will also be easier. Pro-Core miners will support it, since it's a far better option for them than the current standoff and possible network fork.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1666



View Profile
March 23, 2017, 10:28:39 PM
 #178

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

I like the sound of that implementation. It squashes a significant argument against a PoW change, avoids a hard fork, and would keep the markets far calmer.

Vires in numeris
muyuu
Donator
Legendary
*
Offline Offline

Activity: 952



View Profile
March 23, 2017, 11:08:24 PM
 #179

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

Here's my proposal: Implement the new PoW as a PoWA (proof-of-work additions) soft fork. New PoW is memory-hard Cuckoo Cycle (whose creator has joined the discussion here), or possibly Equihash.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

Conservative approach allows us to use relatively untested PoW algorithm safely, as blockchain continues to be 95% secured by old SHA2 hashing power. Getting the larger community behind a conservative solution will also be easier. Pro-Core miners will support it, since it's a far better option for them than the current standoff and possible network fork.


I think it's worth considering but I believe this would take a long time to review and test. The possible dynamics are extremely complex and we have to make sure we done introduce new attacks or vulnerabilities.

I believe we virtually have one already (Keccak) in case we needed a very quick and sudden change, and we can try to improve upon as time allows. We don't know how much time do we have but mixed systems will have to be simplified as much as possible or it will take months or years to have reasonable confidence in them.

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

Activity: 135


View Profile
March 24, 2017, 12:01:47 AM
 #180

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

Here's my proposal: Implement the new PoW as a PoWA (proof-of-work additions) soft fork. New PoW is memory-hard Cuckoo Cycle (whose creator has joined the discussion here), or possibly Equihash.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

Conservative approach allows us to use relatively untested PoW algorithm safely, as blockchain continues to be 95% secured by old SHA2 hashing power. Getting the larger community behind a conservative solution will also be easier. Pro-Core miners will support it, since it's a far better option for them than the current standoff and possible network fork.


I think it's worth considering but I believe this would take a long time to review and test. The possible dynamics are extremely complex and we have to make sure we done introduce new attacks or vulnerabilities.

I believe we virtually have one already (Keccak) in case we needed a very quick and sudden change, and we can try to improve upon as time allows. We don't know how much time do we have but mixed systems will have to be simplified as much as possible or it will take months or years to have reasonable confidence in them.

It's worth exploring since it is a more palatable "non-emergency" solution. As for the current fork, be it HF or SF, I like the idea of a memory intensive POW. It would indeed remove China's hardware monopoly -- and subsidized electricity can be found in many countries.

Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!