Topic: [ANN] Bitcoin PoW Upgrade Initiative - page 12. (Read 42931 times)
already got those ready, lets get this test underway
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.
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.
whats needed from the regular folk that are just miners?
Software will be deployed soon for you to start mining once the testnet is up with your GPU . If you want to prepare , get a high end gaming GPU for a desktop computer.
whats needed from the regular folk that are just miners?
Instead change the mining algorithm or the way blocks are mined, maybe even develop a secondary software to take all the combined hash power of the entire network
The combined protocol would simply become the new protocol and thus this is essentially over complicating matters.
A simple change in this case has 3 unique advantages:
1) breaks less software code (APIS, firmware, custom apps , wallets, ect... )
2) Is less likely to contain exploits and easier to secure
3) Is less likely to contain propositions people disagree with and can argue over.... if we are being attacked by the miners and a speculative coin vote fails than we have no choice but to perform a HF and we don't want to add anything to the HF that would leave others behind because they disagree with part of the proposal
mining exactly every 10 minutes with blocks of any size up to even 16MB?
Sounds to me like extension blocks for more capacity, but that is outside the scope of this topic.
Instead change the mining algorithm or the way blocks are mined, maybe even develop a secondary software to take all the combined hash power of the entire network and secures the blockchain by mining exactly every 10 minutes with blocks of any size up to even 16MB?
I want to know what happens if there was only one mega pool mining and then rewarding miners based on their hash rate?
I want to know what happens if there was only one mega pool mining and then rewarding miners based on their hash rate?
PoS doesn't work, see this PDF https://download.wpsoftware.net/bitcoin/pos.pdf
Yes, this is why we should not waste our attention on PoS at the moment, but there is an argument to be made for a PoW/PoS hybrid temporarily preventing a 51% attack if the economic majority is against the miners.
Also perhaps security is less of an issue for PoS if it could be structured as a supplementary layer which doesn't actually secure transactions, only serves to reduce centralization?
Perhaps , but a lot more testing and thought needs to go into this and we don't have time, so as a matter of practical urgency we need to start a testnet with us mining on it with as simple of a Pow change as possible... Keccak is the best candidate.
Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?
A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as no secure PoS really exist and politically adding PoS to bitcoin will be much more difficult.
I'm glad you think its worth looking at, thanks.
The benefit I think is that miners will fight a PoW change tooth and nail and may gain some sympathy for that from users, because it is a little bit unfair to miners even if it does have benefits and will look to many like a major change. If miners fight such a supplementary PoS they are transparently only doing so in the self-interest of big pools trying to centralize power. So perhaps it won't be more difficult politically.
Also perhaps security is less of an issue for PoS if it could be structured as a supplementary layer which doesn't actually secure transactions, only serves to reduce centralization?
PoS doesn't work, see this PDF https://download.wpsoftware.net/bitcoin/pos.pdf
It is good to be prepared for any eventuality. Just because we talk about a PoW hard fork doesn't mean we'll use it on a whim.
A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.
A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.
Yes, we should only use this after an attack occurs, but need to test and prepare now. If anything showing we are prepared is likely to prevent an attack in the first place.
https://twitter.com/petertoddbtc/status/843450186416365569
Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?
A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as no secure PoS really exist and politically adding PoS to bitcoin will be much more difficult.
My advice it to first test and get running a testnet version of simple PoW Keccak with 0.14 and than investigate a Hybrid SHA256/Keccak proposal ... and after these are running on a testnet with individuals actively mining we can start to explore a PoW /PoS hybrid.
Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?
It is good to be prepared for any eventuality. Just because we talk about a PoW hard fork doesn't mean we'll use it on a whim.
A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.
A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.
So 2 newbie accounts trying to post something and stir up some debates in the community I see 
I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.
Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.
Judging from this latest tweet, we may need to prepare for the worst...
https://twitter.com/JihanWu/status/843341104531427336
Quote from: Jihan
I found that the HF future contract of Bitfinex is very unfair against big blocker. 2 support BU supporter, HF should be accelerated.
I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.
Great, lets work to be prepared for the worst!
I don't like hardforks, but let's better be prepared if things get really ugly!
I don't like hardforks, but let's better be prepared if things get really ugly!
While not specifically related to a PoW change, I would like to see whether there is something that might be investigated to provide more choice to users for any PoW implementation. I'm pretty sure this isn't a re-direct. Let me know if it is.
PKI Mining and Node relay. (Public Key Infrastructure Mining and Node Relay)
Would it be possible to add an encryption key to a txn that signals that you will only allow miners that have the key to mine your txns? This then might be solved as a configuration setting on the nodes :
1. Accept/relay all txns.
2. Key management solution within client that allows me to select from a list of miners that I, as a user, find acceptable.
3. I accept/relay txns that meet a library of keys (white-list).
4. Reject txns that meet a library of keys (black-list).
The immediate issue is that your txn would need to have several keys, for the list of pools/miners that you would be prepared to use to include your txns in a blocks. I'm thinking that there needs to be some method using nodes to re-direct around hostile miners, to miners that meet your requirements. GnuPGP provides the facility for using multiple keys to encrypt the same key. The miner defines a private key, generates a public key from that private key, and the user encrypts their transaction using the private key(s) of their choice.
This might not even be handled in any other way than a 'handshake' between nodes. When a node connects to another node, it passes along its white-list. Perhaps its black-list too, but not necessary. The node it has connected to can then replicate the transactions that meet the list. The node then weeds out the transactions that meet its black-list.
So how would a node perform its validation function with some or all of the content of txn encrypted? Would it be possible to use the public key of one of the encryption keys in order to do a blind validation? I can't see how that would work. Does anyone know of a model that would allow this?
The reason I like this type of option is that it is opt-in, which satisfies the ethos of bitcoin. Then there is incentive for miners to 'do the right thing' and be an accepted miner. You can have white-lists, and black-lists, managed by the user. But it also might give you control, as a node owner, to decide which txns destined to which miner are relayed through your node. I don't want my node to be used to relay transactions to that miner. I think it would also encourage for there to be more nodes.
This entire system doesn't deal with block propagation, so I think it would have a negligible effect on traffic.
But you'd also need to be able to remove transactions from your pool if they are in the block. So it sounds like you wouldn't be able to use encrypt all of the data, just some of it. Enough so you couldn't mine it, but not enough so that you couldn't identify it.
Definitely more cpu processing time though.
Reckon you could do it by making a hash of your transaction details, and then referencing that vs a hash of each of the transactions in the new block. Compare the two, and you'll know you can remove the transactions in the block with matching hashes. So whether all of the txn was encrypted or not, the hash is a header field that isn't. This would allow you to remove transactions in your pool when a new block confirms that they have been included in a block.
Think I might even be over-thinking the validation part. There are two validations. One of the txn, and one of the txn in a block. The second one isn't affected by this process. The first one is. BUT. Do I care about the first one much? The miner still has that key. They can decrypt the txns they have, validate them, and therefore include them in blocks. So the issue doesn't become is it validated, but of incentives.
Validation would still be issue for txn at node though. Spam. Adversarial users could create transactions that clog nodes that will never be included in blocks. If the transaction is invalid, but the relaying node can't validate it, they'd be replicating it to all of the nodes You'd need to have some method of making the user has to pay for this type of transaction. So they lose money the more of them that they create.
PKI Mining and Node relay. (Public Key Infrastructure Mining and Node Relay)
Would it be possible to add an encryption key to a txn that signals that you will only allow miners that have the key to mine your txns? This then might be solved as a configuration setting on the nodes :
1. Accept/relay all txns.
2. Key management solution within client that allows me to select from a list of miners that I, as a user, find acceptable.
3. I accept/relay txns that meet a library of keys (white-list).
4. Reject txns that meet a library of keys (black-list).
The immediate issue is that your txn would need to have several keys, for the list of pools/miners that you would be prepared to use to include your txns in a blocks. I'm thinking that there needs to be some method using nodes to re-direct around hostile miners, to miners that meet your requirements. GnuPGP provides the facility for using multiple keys to encrypt the same key. The miner defines a private key, generates a public key from that private key, and the user encrypts their transaction using the private key(s) of their choice.
This might not even be handled in any other way than a 'handshake' between nodes. When a node connects to another node, it passes along its white-list. Perhaps its black-list too, but not necessary. The node it has connected to can then replicate the transactions that meet the list. The node then weeds out the transactions that meet its black-list.
So how would a node perform its validation function with some or all of the content of txn encrypted? Would it be possible to use the public key of one of the encryption keys in order to do a blind validation? I can't see how that would work. Does anyone know of a model that would allow this?
The reason I like this type of option is that it is opt-in, which satisfies the ethos of bitcoin. Then there is incentive for miners to 'do the right thing' and be an accepted miner. You can have white-lists, and black-lists, managed by the user. But it also might give you control, as a node owner, to decide which txns destined to which miner are relayed through your node. I don't want my node to be used to relay transactions to that miner. I think it would also encourage for there to be more nodes.
This entire system doesn't deal with block propagation, so I think it would have a negligible effect on traffic.
But you'd also need to be able to remove transactions from your pool if they are in the block. So it sounds like you wouldn't be able to use encrypt all of the data, just some of it. Enough so you couldn't mine it, but not enough so that you couldn't identify it.
Definitely more cpu processing time though.
Reckon you could do it by making a hash of your transaction details, and then referencing that vs a hash of each of the transactions in the new block. Compare the two, and you'll know you can remove the transactions in the block with matching hashes. So whether all of the txn was encrypted or not, the hash is a header field that isn't. This would allow you to remove transactions in your pool when a new block confirms that they have been included in a block.
Think I might even be over-thinking the validation part. There are two validations. One of the txn, and one of the txn in a block. The second one isn't affected by this process. The first one is. BUT. Do I care about the first one much? The miner still has that key. They can decrypt the txns they have, validate them, and therefore include them in blocks. So the issue doesn't become is it validated, but of incentives.
Validation would still be issue for txn at node though. Spam. Adversarial users could create transactions that clog nodes that will never be included in blocks. If the transaction is invalid, but the relaying node can't validate it, they'd be replicating it to all of the nodes You'd need to have some method of making the user has to pay for this type of transaction. So they lose money the more of them that they create.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Key-ID: 331B6406
Fingerprint: BE9209A6C773FBF91E4ED2E425C33539331B6406
Last updated: 2017/03/25 04:48 UTC
Rule #1: We are not here to debate against PoW change-- this thread is for people who have already decided to help with a PoW change of some kind. It is, however, acceptable (and desirable) to debate exactly what kind of PoW fork, based on data, testing, exploit discovery, etc.
[BrCoh1] Cuckoo cycle is one of the most ASIC-resistant Proof-of-Work algorithms.
Bitmain is close to having de facto control of a great majority of the network hashrate:
"Bitmain, one of bitcoin’s biggest miners with a current hash-share of around 15% of the network, is to launch a new giant mining facility this December with 45 rooms, independent substations, offices and a total size of 140,000 kilowatts.
By some calculations, that translates to around 45% of the network hash-share, but it is not clear whether the new facilities are simply for a relocation or to accommodate additional mining power."
[ Quentson, A. (2016, February 11). "Bitmain to Launch a Giant New Bitcoin Mining Center". CryptoCoinsNews.]
This poses the risk of:
- transaction censorship ("PBoC does not approve of your transaction, so Bitmain has their pools exclude it from blocks")
- double-spend attacks (if Bitmain is not motivated by mining profits (as a KnC miner executive once speculated) because e.g. their real profits come from a ChinaGov paycheck), then they will happily destroy the value of Bitcoin's network by executing double-spend attacks.
Given the urgency of settling these issues in order to protect Bitcoin's prime reputation and its adoption rate, I offer the following recommended ranking of types of communications on this thread, starting with the most valuable at (1):
(1) Empirical data - Tests, competitive benchmarks between PoW algorithms when merged with Bitcoin codebase, accurate descriptions of vulnerabilities/exploits with sample code.
(2) Analysis of data - Identification and further extrapolation of patterns in data, technical critique of methods used in tests, model-based predictions of outcomes of tests (if the tests themselves are too resource/labor intensive to actually carry out)
(3) Interpretation of results - Discussion (with proof/justification) of what the results and analysis of the tests will mean for the Bitcoin market cap, decentralization, censorship-resistance, and any new vulnerabilities.
(4) Broader discussion - Including discussion of businesses related to Bitcoin, quotes by notable personalities relevant to Bitcoin, regulations and other activities of governments with respect to Bitcoin, and what implications these things have for the PoW project.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY1fjOAAoJECXDNTkzG2QGfcoIAJEp1+LmBom2ZDAEC13PeIdH
8V9w6bP0/dRe2lcrwU5bOSCZHrzqI7JOCUC28KMXrt3RvHUdtuwcnoPpS3Rebaub
+5BloS+OEwSNDb5qvLIJX7dp38GYKThK/Kw70r5/NS+Vh1VMCwZyWd+BLjoMSnmw
QyNZOLSVk9bR7WShxdq0aj4ADGAPhTwBey0/R9CfHZOlQzWHQIVwmOXShOBfDI1O
ENomlu9k1b1fPf5U5V8Zg3rEyPU0nfWLSGjNqwGNeRuofob61XCFfYGHopyPdmRP
cliCCXg1R236sJICFjYJ/c/+gyzw9cxRXwwXseJ/ik2wM/5dl9rzgnQp4TmnNB8=
=fBZw
-----END PGP SIGNATURE-----
Hash: SHA256
Key-ID: 331B6406
Fingerprint: BE9209A6C773FBF91E4ED2E425C33539331B6406
Last updated: 2017/03/25 04:48 UTC
Bitcoin Proof-of-Work Update Initiative
Goal
To research the suitability of alternate proof-of-work algorithms, to test them, and then to implement the algorithm that makes it through these filters as Bitcoin mainnet's new proof-of-work function.Contributors
- luke-jr - renowned Bitcoin Core developer - Development
- /u/riiume (me) - Marketing/publishing
- r00tdude
- desantis - is working on a PoW fork proposal
- ... Perhaps you? If interested in going full bore on this project, please PM me, along with a one sentence bio, then you will be added to this list.
Rule #1: We are not here to debate against PoW change-- this thread is for people who have already decided to help with a PoW change of some kind. It is, however, acceptable (and desirable) to debate exactly what kind of PoW fork, based on data, testing, exploit discovery, etc.
Developer Resources
- luke-jr's prototype of how a PoW change could be implemented in code: https://github.com/luke-jr/bitcoin/commit/8d3a84c242598ef3cdc733e99dddebfecdad84a6
- Bitcoin Hard Fork Research - repository of quality research into general Bitcoin hard forks
- Malice Reactive Proof of Work Additions (MR POWA)
- Github BIP - in the works
- Wiki - in the works - a curated reference to the most valuable data/tests/benchmarks to come out of these discussions. Hopefully a sort of "rock-of-objectivity" upon which the ongoing planning and discussing can be built.
Media, Essays
- "Proof-of-Work update is not a threat to miners, it is a necessity for users" [Nicolas Dorier]
- Reddit+Twitter+SocialMedia:
Claims Worth Testing
(pm me if you would like to recommend edits to this list)[BrCoh1] Cuckoo cycle is one of the most ASIC-resistant Proof-of-Work algorithms.
Social
- Website: btcpowupdate.org
- Twitter: @BtcPowUpgrade
Raison D'être
Bitmain is close to having de facto control of a great majority of the network hashrate:
"Bitmain, one of bitcoin’s biggest miners with a current hash-share of around 15% of the network, is to launch a new giant mining facility this December with 45 rooms, independent substations, offices and a total size of 140,000 kilowatts.
By some calculations, that translates to around 45% of the network hash-share, but it is not clear whether the new facilities are simply for a relocation or to accommodate additional mining power."
[ Quentson, A. (2016, February 11). "Bitmain to Launch a Giant New Bitcoin Mining Center". CryptoCoinsNews.]
This poses the risk of:
- transaction censorship ("PBoC does not approve of your transaction, so Bitmain has their pools exclude it from blocks")
- double-spend attacks (if Bitmain is not motivated by mining profits (as a KnC miner executive once speculated) because e.g. their real profits come from a ChinaGov paycheck), then they will happily destroy the value of Bitcoin's network by executing double-spend attacks.
Recommended Discussion Guidelines
Given the urgency of settling these issues in order to protect Bitcoin's prime reputation and its adoption rate, I offer the following recommended ranking of types of communications on this thread, starting with the most valuable at (1):
(1) Empirical data - Tests, competitive benchmarks between PoW algorithms when merged with Bitcoin codebase, accurate descriptions of vulnerabilities/exploits with sample code.
(2) Analysis of data - Identification and further extrapolation of patterns in data, technical critique of methods used in tests, model-based predictions of outcomes of tests (if the tests themselves are too resource/labor intensive to actually carry out)
(3) Interpretation of results - Discussion (with proof/justification) of what the results and analysis of the tests will mean for the Bitcoin market cap, decentralization, censorship-resistance, and any new vulnerabilities.
(4) Broader discussion - Including discussion of businesses related to Bitcoin, quotes by notable personalities relevant to Bitcoin, regulations and other activities of governments with respect to Bitcoin, and what implications these things have for the PoW project.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY1fjOAAoJECXDNTkzG2QGfcoIAJEp1+LmBom2ZDAEC13PeIdH
8V9w6bP0/dRe2lcrwU5bOSCZHrzqI7JOCUC28KMXrt3RvHUdtuwcnoPpS3Rebaub
+5BloS+OEwSNDb5qvLIJX7dp38GYKThK/Kw70r5/NS+Vh1VMCwZyWd+BLjoMSnmw
QyNZOLSVk9bR7WShxdq0aj4ADGAPhTwBey0/R9CfHZOlQzWHQIVwmOXShOBfDI1O
ENomlu9k1b1fPf5U5V8Zg3rEyPU0nfWLSGjNqwGNeRuofob61XCFfYGHopyPdmRP
cliCCXg1R236sJICFjYJ/c/+gyzw9cxRXwwXseJ/ik2wM/5dl9rzgnQp4TmnNB8=
=fBZw
-----END PGP SIGNATURE-----
Jump to: