muyuu

Legendary



Offline



Activity: 966

Merit: 1000









DonatorLegendaryActivity: 966Merit: 1000 Re: [ANN] Bitcoin PoW Upgrade Initiative March 24, 2017, 02:03:43 PM #181 An automatic full PoW switch trigger on extremely anomalous conditions. GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)

forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ

Carlton Banks



Offline



Activity: 2842

Merit: 2273









LegendaryActivity: 2842Merit: 2273 Re: [ANN] Bitcoin PoW Upgrade Initiative March 24, 2017, 05:38:59 PM #182 Quote from: mmgen-py on March 24, 2017, 12:14:33 PM Quote from: Carlton Banks on March 24, 2017, 11:15:27 AM What will prevent the SHA256 miners orphaning the new hashing algo blocks? Would it not be better to start at 51% share to the new hash algo to prevent that, or would an exponential rise in blocks built on using the the new hash algo as it approaches 51% of the hashrate be acceptable?



I doubt that any of the existing miners would agree to a proposal that immediately slashes their block reward in half, while many might agree to a 5% haircut. Especially since the miners that choose to join us will get a nice windfall at first as the difficulty adjusts downwards.



Uncooperative miners will end up on a different chain in any casethere's nothing we can do about that. We just count on the economic majority being upgraded and ignoring their chain. They can continue mining their chain at a loss or rejoin Bitcointhe choice is theirs.



I doubt that any of the existing miners would agree to a proposal that immediately slashes their block reward in half, while many might agree to a 5% haircut. Especially since the miners that choose to join us will get a nice windfall at first as the difficulty adjusts downwards.Uncooperative miners will end up on a different chain in any casethere's nothing we can do about that. We just count on the economic majority being upgraded and ignoring their chain. They can continue mining their chain at a loss or rejoin Bitcointhe choice is theirs.

Right, well I hate to resurrect previous sore points, but.....





We should begin to build support for this. If every iteration requires a soft fork, then either an additional soft fork can let us wind back to 100% SHA-2 (in the perhaps unlikely event of the uncooperative ASIC miners changing their minds), or we just carry on until 100% CPU mining is back in charge.



If we do not build support before the threat of external hard fork attacks (note the plural "attacks"), I fear we may get outplayed with lateral attacks via the internet infrastructure, the legal system, the dev team, all 3, or something I'm not even considering. It should be an obvious fact that international collaboration between those perpetrating this BU attack (at a minimum between some English speaking + Chinese interests) should indicate quite how seriously the unknown opponent is taking Bitcoin.





If the most balanced way to do this is by gradation, and I believe a good case has been made for that, then waiting for an emergency to occur could well cause the strategy to invite the opponent to produce their most potent attacks to stop it. Switching to 100% CPU mining in an emergency makes sense, switching to 5% over weeks or months does not. Right, well I hate to resurrect previous sore points, but.....We should begin to build support for this. If every iteration requires a soft fork, then either an additional soft fork can let us wind back to 100% SHA-2 (in the perhaps unlikely event of the uncooperative ASIC miners changing their minds), or we just carry on until 100% CPU mining is back in charge.If we do not build support before the threat of external hard fork attacks (note the plural "attacks"), I fear we may get outplayed with lateral attacks via the internet infrastructure, the legal system, the dev team, all 3, or something I'm not even considering. It should be an obvious fact that international collaboration between those perpetrating this BU attack (at a minimum between some English speaking + Chinese interests) should indicate quite how seriously the unknown opponent is taking Bitcoin.If the most balanced way to do this is by gradation, and I believe a good case has been made for that, then waiting for an emergency to occur could well cause the strategy to invite the opponent to produce their most potent attacks to stop it. Switching to 100% CPU mining in an emergency makes sense, switching to 5% over weeks or months does not. Vires in numeris

mmgen-py



Offline



Activity: 105

Merit: 10







MemberActivity: 105Merit: 10 Re: [ANN] Bitcoin PoW Upgrade Initiative March 24, 2017, 07:32:36 PM

Last edit: March 24, 2017, 07:43:12 PM by mmgen-py #183 Quote from: Carlton Banks on March 24, 2017, 05:38:59 PM Switching to 100% CPU mining in an emergency makes sense, switching to 5% over weeks or months does not.



Of course. We need both an emergency plan and a non-emergency plan. The emergency plan would be a 100% HF switch to the new algorithm. The non-emergency plan is the gradual one I'm proposing. And for it we of course need to work with the community and build support. If it activates, I don't envision ever going back to all-ASIC mining. On the contrary, the whole point is to build a new, more decentralized mining community around readily-available DRAM.



I proceed from the assumption that we might not get the emergency we're expecting, at least not anytime soon. It's too risky for our opponents. Instead, they'll just keep waging a war of attrition against us in the ways you've mentioned. This is why we need to be proactive in advancing the non-emergency plan while our position is still strong.

Of course. We need both an emergency plan and a non-emergency plan. The emergency plan would be a 100% HF switch to the new algorithm. The non-emergency plan is the gradual one I'm proposing. And for it we of course need to work with the community and build support. If it activates, I don't envision ever going back to all-ASIC mining. On the contrary, the whole point is to build a new, more decentralized mining community around readily-available DRAM.I proceed from the assumption that we might not get the emergency we're expecting, at least not anytime soon. It's too risky for our opponents. Instead, they'll just keep waging a war of attrition against us in the ways you've mentioned. This is why we need to be proactive in advancing the non-emergency plan while our position is still strong.

Carlton Banks



Offline



Activity: 2842

Merit: 2273









LegendaryActivity: 2842Merit: 2273 Re: [ANN] Bitcoin PoW Upgrade Initiative March 24, 2017, 08:25:51 PM #184 Quote from: mmgen-py on March 24, 2017, 07:32:36 PM I proceed from the assumption that we might not get the emergency we're expecting, at least not anytime soon. It's too risky for our opponents. Instead, they'll just keep waging a war of attrition against us in the ways you've mentioned. This is why we need to be proactive in advancing the non-emergency plan while our position is still strong.





I more or less agree, but the assumption I've bolded is dangerous. There is a significant risk that a "short sharp shock" act of caprice could happen very suddenly, especially now that BU is looking increasingly unlikely to gain any foothold with users. As I mentioned in another thread, the opposition have exceeded their "crying wolf" quota. What makes anyone believe the attackers will not choose a different MO altogether?



Frankly, I would be most surprised if another hard fork campaign would ever be a genuine attempt, I would expect a sudden political act against Bitcoin (via the potential vectors I described before) to happen during the next hard fork campaign, "when it is least expected" lol. We should expect it, and prepare the user community accordingly. I more or less agree, but the assumption I've bolded is dangerous. There is a significant risk that a "short sharp shock" act of caprice could happen very suddenly, especially now that BU is looking increasingly unlikely to gain any foothold with users. As I mentioned in another thread, the opposition have exceeded their "crying wolf" quota. What makes anyone believe the attackers will not choose a different MO altogether?Frankly, I would be most surprised if another hard fork campaign would ever be a genuine attempt, I would expect a sudden political act against Bitcoin (via the potential vectors I described before) to happen during the next hard fork campaign, "when it is least expected" lol. We should expect it, and prepare the user community accordingly. Vires in numeris

Frogolocalypse



Offline



Activity: 8

Merit: 0







NewbieActivity: 8Merit: 0 Re: [ANN] Bitcoin PoW Upgrade Initiative March 25, 2017, 02:49:51 AM #185



https://bitcointalk.org/index.php?topic=1833391.msg18247163#msg18247163



Rather than change the core client, I have an extension of the method detailed above. What about having a PKI (public key infrastructure) transaction pool? PKI TxnPool.



The goal is to ensure that only miners that meet your user requirements can include your txns in a block. The desire is to de-incentivize miners that are attacking the network, and that there is a clear path between nodes and miners for transactions that are validated. This might not be able to stop a 51% attack, but it might be able to stop miner centralization occurring in the first place.



PKI txnpool.



Setup :

Miner creates prv/pub key pair. Miner publishes pub key. Could be anywhere. Miner creates black-list of nodes (empty). Pseudonymous. Miners signs black-list with priv-key.



Node creates prv/pub key pair. Pseudonymous. Node creates white-list miners using pub keys of miners.



Adding txns to PKI txnpool.



Node reads node mempool for new txn. Node validates txn. Node creates hash of txn. Node encrypts txn using pub-keys of all miners in white-list. Node signs encrypted txn. Node creates txn-relay-file with : hash of txn, Node pubkey, Signature, list of white-listed miners, encrypted txn. Node adds encrypted txn to PKI txnpool for relay.



We now have a txn that has been validated, with a node identifier, and a white-list of miners that can include their txn on the block-chain.



PKI txnpool relay.



Node peers with other node. Nodes exchange pubkeys. Nodes exchange miner black-lists with version numbers greater than on node. Miner validates signature of miner black-list. Node black-lists Node that has incorrectly signed miner black-list. If valid continue, if not, cancel peer connection. Nodes remove txns from PKI txnpool that are signed by black-listed nodes. Nodes create exchange white-list, removing a miner from the white-list if it is in the miner black-list. Nodes exchange curated miner white-lists. Nodes exchange txns that meet node white-list requirements.



PKI txnpool removing txns that have been included in blocks or are too old.



Node gets new block. Node creates hash of each txn in block. Node removes from PKI txnpool that have duplicate hash. Node removes from PKI txnpool txns that are >cfg time from adding to local pool.



Miners use PKI txnpool to get txns.



Miner queries PKI txnpool. Miner node sets white-list to only that miner. It doesn't matter if they have more, they just won't be able to decrypt txns that they don't have the privkey for. Miner uses privkey to decrypt txn. Miner node validates txn. If txn is invalid, add node that created txn to miner black-list. Miner updates and signs black-list. Miner replicates new miner-black-list to peer nodes.





Through this, PKI txnpool nodes work in an independent pool from bitcoin. Nodes must ensure they create valid transactions, or they will be black-listed by any miner that opens a txn they created, and determine it is invalid, and the txns they create won't replicated. Miners can only decrypt transactions that have been encrypted using their pubkey. This solution should allow users to select from a group of miners, and by extension, de-select miners that don't meet their requirements. This provides a user and miner controlled tool to route-around malicious miners and nodes. An extension of this post :Rather than change the core client, I have an extension of the method detailed above. What about having a PKI (public key infrastructure) transaction pool? PKI TxnPool.The goal is to ensure that only miners that meet your user requirements can include your txns in a block. The desire is to de-incentivize miners that are attacking the network, and that there is a clear path between nodes and miners for transactions that are validated. This might not be able to stop a 51% attack, but it might be able to stop miner centralization occurring in the first place.Miner creates prv/pub key pair. Miner publishes pub key. Could be anywhere. Miner creates black-list of nodes (empty). Pseudonymous. Miners signs black-list with priv-key.Node creates prv/pub key pair. Pseudonymous. Node creates white-list miners using pub keys of miners.Node reads node mempool for new txn. Node validates txn. Node creates hash of txn. Node encrypts txn using pub-keys of all miners in white-list. Node signs encrypted txn. Node creates txn-relay-file with : hash of txn, Node pubkey, Signature, list of white-listed miners, encrypted txn. Node adds encrypted txn to PKI txnpool for relay.We now have a txn that has been validated, with a node identifier, and a white-list of miners that can include their txn on the block-chain.Node peers with other node. Nodes exchange pubkeys. Nodes exchange miner black-lists with version numbers greater than on node. Miner validates signature of miner black-list. Node black-lists Node that has incorrectly signed miner black-list. If valid continue, if not, cancel peer connection. Nodes remove txns from PKI txnpool that are signed by black-listed nodes. Nodes create exchange white-list, removing a miner from the white-list if it is in the miner black-list. Nodes exchange curated miner white-lists. Nodes exchange txns that meet node white-list requirements.Node gets new block. Node creates hash of each txn in block. Node removes from PKI txnpool that have duplicate hash. Node removes from PKI txnpool txns that are >cfg time from adding to local pool.Miner queries PKI txnpool. Miner node sets white-list to only that miner. It doesn't matter if they have more, they just won't be able to decrypt txns that they don't have the privkey for. Miner uses privkey to decrypt txn. Miner node validates txn. If txn is invalid, add node that created txn to miner black-list. Miner updates and signs black-list. Miner replicates new miner-black-list to peer nodes.Through this, PKI txnpool nodes work in an independent pool from bitcoin. Nodes must ensure they create valid transactions, or they will be black-listed by any miner that opens a txn they created, and determine it is invalid, and the txns they create won't replicated. Miners can only decrypt transactions that have been encrypted using their pubkey. This solution should allow users to select from a group of miners, and by extension, de-select miners that don't meet their requirements. This provides a user and miner controlled tool to route-around malicious miners and nodes.

Andre_Goldman



Offline



Activity: 322

Merit: 251



Property1of1OU







Sr. MemberActivity: 322Merit: 251Property1of1OU Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 06:12:17 AM #190



a GPU Farm get a much lower hardware depreciation than ASIC hardware economics.



A GPU farm can also be used for Deep Learning rent (for instance.:

AWS, Google, Azure GPU cluster (on average costs) $0.90 per hour to run)

also some small GPU providers



You can reseller your used hardware to gamers on ebay, etc.



My opinion from the miner's economic point of view ...a GPU Farm get a much lower hardware depreciation than ASIC hardware economics.A GPU farm can also be used for Deep Learning rent (for instance.:AWS, Google, Azure GPU cluster (on average costs) $0.90 per hour to run)also some small GPU providers https://www.leadergpu.com/ You can reseller your used hardware to gamers on ebay, etc. Patent1number: ****-****

pinkflower



Offline



Activity: 826

Merit: 259







Sr. MemberActivity: 826Merit: 259 Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 09:28:15 AM #191 Quote from: iCEBREAKER on March 25, 2017, 09:52:26 AM Quote from: zooko on March 19, 2017, 05:42:02 PM Quote from: Cryptorials on March 19, 2017, 05:20:01 PM Have you guys looked at Cuckoo cycle?



FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it  it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it  it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

What about cycling through 10 unique PoWs every 10 blocks?



I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?



Block 1 JH

Block 2 Skein

Block 3 Groestl

Block 4 Cuckoo

Block 5 Keccak

Block 6 Equihash

Block 7 BLAKE2

Block 8 SCrypt

Block 9 CryptoNight

Block 10 Ethash





What about cycling through 10 unique PoWs every 10 blocks?I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?Block 1 JHBlock 2 SkeinBlock 3 GroestlBlock 4 CuckooBlock 5 KeccakBlock 6 EquihashBlock 7 BLAKE2Block 8 SCryptBlock 9 CryptoNightBlock 10 Ethash

Wont this make difficulty rise and fall like a wave? If the answer is yes, then wont this open the network to attacks if there is a fall in difficulty. Maybe it wont be the case after a year but in the beginning it could be.



If youre going that road, why not have 2 POW algorithm at first with the option of expanding it instead of starting with 10 outright. Wont this make difficulty rise and fall like a wave? If the answer is yes, then wont this open the network to attacks if there is a fall in difficulty. Maybe it wont be the case after a year but in the beginning it could be.If youre going that road, why not have 2 POW algorithm at first with the option of expanding it instead of starting with 10 outright.

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 05:24:48 PM #193 There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?

Carlton Banks



Offline



Activity: 2842

Merit: 2273









LegendaryActivity: 2842Merit: 2273 Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 07:11:44 PM #194 Quote from: BitUsher on March 26, 2017, 05:24:48 PM There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?



The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe)



Can the several developers not present their designs, rates and also addresses to donate to? The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe)Can the several developers not present their designs, rates and also addresses to donate to? Vires in numeris

mmgen-py



Offline



Activity: 105

Merit: 10







MemberActivity: 105Merit: 10 Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 07:27:21 PM

Last edit: April 16, 2017, 05:04:46 PM by mmgen-py #195





New PoW chain is shown in pink, legacy blockchain in blue.



Brief description:



New PoW miners mine continuously, legacy miners almost continuously. Proofs for the new PoW blockchain's mini-blocks are embedded into legacy chain in a special output of the coinbase transaction.

All assembling of TXs into blocks and reorgs happen on the new PoW chain. Legacy miners' participation is restricted to solving the SHA256 proof-of-work, adding their payout address to the coinbase TX and broadcasting the block.

Mini-blocks are 100 Kb in size; new PoW blockchain has one-minute block discovery rate (i.e., confirmation time).

Mini-block headers are like ordinary block headers but with an added payout address.

Legacy miners experience an avg. of 10% downtime while waiting for new PoW miners to mine the next proto-block.

Initially, 90% of block reward will go to legacy miners and 10% to new PoW miners. Legacy miners' share could be gradually reduced (over a period of years?) until it reaches zero.

After legacy miner broadcasts a valid block, new PoW miner assembles a "proto-block" (a nearly complete Bitcoin block) out of TXs from all mini-blocks mined since last proto-block. Extra TXs are added from mempool to make the block full. Payout outputs for mini-blocks and proto-block are added to the coinbase TX (with 10% of block reward divided equally among them). Mini-block headers and legacy block header hash are embedded in the special output of the coinbase TX. Miner solves the proto-block and broadcasts it to legacy miners.

Legacy miner adds his payout output and proto-block header to the coinbase TX and Merkle root to the header, making the block complete. He then solves and broadcasts the block as usual. Legacy miner is allowed to alter only four pieces of data: timestamp, nonce, coinbase nonce and his payout output.

If new PoW miners solve nine mini-blocks faster than legacy miners solve one block, then they continue mining empty mini-blocks until legacy miners finally solve the block. Thus a proto-block may contain more than nine mini-blocks.

In the reverse case, proto-block will contain fewer than nine mini-blocks.

"Longest chain" according to new consensus rules is chain with the most embedded mini-block/proto-block proofs. This prevents legacy miners from initiating reorgs.



System is PoW agnostic, but a memory-hard algorithm such as Cuckoo Cycle or Equihash would be preferred, as this would lead to the creation of a new decentralized mining industry based on universally available DRAM.

This description is preliminary; certain details may be subject to change.



Benefits:



New decentralized mining industry is created.

Legacy miners are deprived of all decision-making power and possibility of attacking the chain.

Gradual or partial phase-in of new PoW reduces security risk.

Bitcoin's effective confirmation time is reduced to one minute.

Despite the 10% "haircut" they receive, legacy miners can profit from the SF if economic majority upgrades and most value remains on upgraded chain. Thus the proposal could expect to gain broad community consensus, even among miners.

Variations:



Legacy miners' share of block reward could be left at 90%, with no phase-out, making proposal more attractive to them.

Here's how I propose to decentralize mining with a PoWA (proof-of-work additions) soft fork:New PoW chain is shown in pink, legacy blockchain in blue.This description is preliminary; certain details may be subject to change.

Carlton Banks



Offline



Activity: 2842

Merit: 2273









LegendaryActivity: 2842Merit: 2273 Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 09:15:03 PM #196 Quote from: mmgen-py on March 26, 2017, 07:27:21 PM









New PoW chain is shown in pink, legacy blockchain in blue.



Brief description:



New PoW miners and legacy miners mine in parallel. Proofs for the new PoW blockchain's mini-blocks are embedded into legacy chain in a special transaction.

All assembling of TXs into blocks and reorgs happen on the new PoW chain. Legacy miners' role is restricted to finding SHA256 hashes, final block assembly (calculating payouts, creating the coinbase TX) and broadcasting the block.

Mini-blocks are 100 Kb in size; new PoW blockchain has one-minute block discovery rate (i.e. confirmation time).

Mini-block headers are like ordinary block headers but with an added payout address.

New PoW miners mine with no downtime. Legacy miners experience an avg. of 10% downtime while waiting for new PoW miners to mine one block. (It may be possible to eliminate this downtime by having new PoW miners solve only mini-blocks and not entire block.)

Initially, 95% of block reward will go to legacy miners and 5% to new PoW miners. Legacy miners' share will be gradually reduced (over a period of years?) until it reaches zero.

After legacy miner broadcasts a valid block, new PoW miners assemble all TXs from mini-blocks mined so far into a single Bitcoin block with no Coinbase TX, solve the block and broadcast it along with mini-block headers to legacy miners.

Legacy miner adds mini-block proofs, TX counts and payout addresses to the special transaction, calculates payouts (initially distributing 95% of reward to himself and 5% equally among new PoW miners), adds payout outputs to Coinbase TX and then solves and broadcasts the block as usual.

If new PoW miners solve nine mini-blocks faster than legacy miners solve one block, then they continue mining empty mini-blocks until legacy miners finally solve the block. Thus a block may contain more than 10 mini-blocks.

In the reverse case, fewer than 10 mini-blocks will be assembled into a block, and the new PoW miner who assembles the block will add as many TXs to the final mini-block as required in order to reach the blocksize limit (currently 1MB).

All of the above is preliminary and subject to change.



Here's a schematic of my proposed PoWA (proof-of-work additions) soft-fork blockchain.New PoW chain is shown in pink, legacy blockchain in blue.All of the above is preliminary and subject to change.

What's the rationale for making the mini-blocks 10 per legacy block? I'm thinking of the orphan rate.



I'm also unconvinced about a "years" timeframe. I would propose 1 year, where the interval between the 5% steps starts at close to infinity increase for the 5-10% part, and gradually increases the interval between steps (like an exponential curve inverted about x=y, is that the cosine curve?)



Going faster to begin with should help to attract hashing power to newPoW, and in turn dissuade the BU miners from even attempting the various attacks they have no doubt developed. The "long tail" will gradually contribute to calming what would inevitably be a very febrile atmosphere surrounding the initial 5% change (the accompanying FUD would no doubt be typically disproportionate) What's the rationale for making the mini-blocks 10 per legacy block? I'm thinking of the orphan rate.I'm also unconvinced about a "years" timeframe. I would propose 1 year, where the interval between the 5% steps starts at close to infinity increase for the 5-10% part, and gradually increases the interval between steps (like an exponential curve inverted about x=y, is that the cosine curve?)Going faster to begin with should help to attract hashing power to newPoW, and in turn dissuade the BU miners from even attempting the various attacks they have no doubt developed. The "long tail" will gradually contribute to calming what would inevitably be a very febrile atmosphere surrounding the initial 5% change (the accompanying FUD would no doubt be typically disproportionate) Vires in numeris

tenletters



Offline



Activity: 31

Merit: 0







NewbieActivity: 31Merit: 0 Re: [ANN] Bitcoin PoW Upgrade Initiative March 26, 2017, 11:45:17 PM

Last edit: March 27, 2017, 12:23:04 AM by tenletters #197 Quote from: iCEBREAKER on March 25, 2017, 09:52:26 AM Quote from: zooko on March 19, 2017, 05:42:02 PM Quote from: Cryptorials on March 19, 2017, 05:20:01 PM Have you guys looked at Cuckoo cycle?



FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it  it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it  it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

What about cycling through 10 unique PoWs every 10 blocks?



I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?



Block 1 JH

Block 2 Skein

Block 3 Groestl

Block 4 Cuckoo

Block 5 Keccak

Block 6 Equihash

Block 7 BLAKE2

Block 8 SCrypt

Block 9 CryptoNight

Block 10 Ethash





What about cycling through 10 unique PoWs every 10 blocks?I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?Block 1 JHBlock 2 SkeinBlock 3 GroestlBlock 4 CuckooBlock 5 KeccakBlock 6 EquihashBlock 7 BLAKE2Block 8 SCryptBlock 9 CryptoNightBlock 10 Ethash

DeSantis has started some work (he wants to do some testing before posting his source code for peer review though).

He's creating a Keccak fork and a Cuckoo fork, and has created a beautiful automated testing utility that I hope he gives me permission to link to you guys.



The testing utility (I've viewed the source, it's not vaporware) allows you to spin up multiple Docker containers, each containing a different Bitcoin node; some of the nodes can be Bitcoin 0.14.0, some of them can be Bitcoin Unlimited, and some of them can be Keccak, Cuckoo, etc.



With these containerized Bitcoin nodes, you can then simulate various forking scenarios, and actually observe in real-time how it plays out. With my limited bitcoin programming knowledge, I am waiting for him to document the config file that controls the node counts & types, and to create some python installation script (which are easier to debug for me at least).



tl;dr - DeSantis is testing Keccak & Cuckoo using a Bitcoin Network Simulator . DeSantis has started some work (he wants to do some testing before posting his source code for peer review though).He's creating a Keccak fork and a Cuckoo fork, and has created a beautiful automated testing utility that I hope he gives me permission to link to you guys.The testing utility (I've viewed the source, it's not vaporware) allows you to spin up multiple Docker containers, each containing a different Bitcoin node; some of the nodes can be Bitcoin 0.14.0, some of them can be Bitcoin Unlimited, and some of them can be Keccak, Cuckoo, etc.With these containerized Bitcoin nodes, you can then simulate various forking scenarios, and actually observe in real-time how it plays out. With my limited bitcoin programming knowledge, I am waiting for him to document the config file that controls the node counts & types, and to create some python installation script (which are easier to debug for me at least).tl;dr -

tenletters



Offline



Activity: 31

Merit: 0







NewbieActivity: 31Merit: 0 Re: [ANN] Bitcoin PoW Upgrade Initiative March 27, 2017, 12:21:42 AM #198 Quote from: Carlton Banks on March 26, 2017, 07:11:44 PM Quote from: BitUsher on March 26, 2017, 05:24:48 PM There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?



The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe)



Can the several developers not present their designs, rates and also addresses to donate to?

The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe)Can the several developers not present their designs, rates and also addresses to donate to?



-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256



Hi devs, can you all send your nominations for who the most credible individuals are for managing an m-of-n account (for holding the PoW bounty's reward funds)?



1) Please send PGP-signed emails to



2) Once all the nominations are received, I will make one big post containing all of the signed emails (unless the sender wishes to remain anonymous due to fear of BitfuryGeorge).



3) We reach out to the agreed upon individuals, inviting them to become custodians of the multisig address and requesting a public BTC address (for which they control the private key) from each of them.



4) Create the multisig address, notify the new custodians of the account.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2



iQEcBAEBCAAGBQJY2FrYAAoJECXDNTkzG2QGrvwH/0CjwKRgSmHmMPFXKA8F1YWa

CMcrWx0KN2ykhqxclxEAlMIs8Zb4u3KO89nejza/Guh0f2sNWSCW6NvrEhRzHodf

TSn8VpCcjpeYc1Iu5wSMBTVk6h/dqZy0eJJRukN4M8qTstnwvU2B48I7Q24x9zLe

B2lOxqhm3fIauaXCTgey4YLgvMfo058jg7+x9DrYKtmP8jht49AmvBv+XI69YfHq

XHvTpbipeNsoTR7qQUXnsnGtbMW7Sl0jywFjRUe1Gq7xGBf6ICH6WkCBLgRDCPCA

z+7gqv6zqjZaAqmbaZej/+4JShnhX2wgj1LKvtW65TdJuyxy4KG6sS231wgAp/4=

=yOSx

-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256Hi devs, can you all send your nominations for who the most credible individuals are for managing an m-of-n account (for holding the PoW bounty's reward funds)?1) Please send PGP-signed emails to jecooper@alum.mit.edu (you may encrypt if you wish to remain anonymous, my PGP key ID is 331B6406 (pgp.mit.edu)).2) Once all the nominations are received, I will make one big post containing all of the signed emails (unless the sender wishes to remain anonymous due to fear of BitfuryGeorge).3) We reach out to the agreed upon individuals, inviting them to become custodians of the multisig address and requesting a public BTC address (for which they control the private key) from each of them.4) Create the multisig address, notify the new custodians of the account.-----BEGIN PGP SIGNATURE-----Version: GnuPG v2iQEcBAEBCAAGBQJY2FrYAAoJECXDNTkzG2QGrvwH/0CjwKRgSmHmMPFXKA8F1YWaCMcrWx0KN2ykhqxclxEAlMIs8Zb4u3KO89nejza/Guh0f2sNWSCW6NvrEhRzHodfTSn8VpCcjpeYc1Iu5wSMBTVk6h/dqZy0eJJRukN4M8qTstnwvU2B48I7Q24x9zLeB2lOxqhm3fIauaXCTgey4YLgvMfo058jg7+x9DrYKtmP8jht49AmvBv+XI69YfHqXHvTpbipeNsoTR7qQUXnsnGtbMW7Sl0jywFjRUe1Gq7xGBf6ICH6WkCBLgRDCPCAz+7gqv6zqjZaAqmbaZej/+4JShnhX2wgj1LKvtW65TdJuyxy4KG6sS231wgAp/4==yOSx-----END PGP SIGNATURE-----