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.
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.
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
Advertised sites are not endorsed by the bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Newbie Offline
Activity: 11
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.
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?
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.
Newbie Offline
Activity: 11
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?
—–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 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 v2
What’s the rationale for making the mini-blocks 10 per legacy block? I’m thinking of the orphan rate.
In order to keep the two chains in sync and ensure that the new PoW hash power is always working, the new PoW miners can assemble the next proto-block from mini-blocks and mine it only after legacy miners have mined and broadcast the current block. The period while the new PoW miners are mining the proto-block is downtime for the legacy miners; their hash power is going to waste. In order to minimize this downtime, we need a fast confirmation time for the new PoW. One minute isn’t too extreme, actually, if we consider Ethereum’s 20-second confirmation time.
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)
It’s a tradeoff. Yes, transitioning faster would attract more new PoW miners. So would giving them a larger share of the block reward at the beginning, say 10%.
On the other hand, since this is “non-hostile” fork proposal that seeks to gain broad community consensus, we don’t want to alienate legacy miners by turning their hardware into scrap metal too quickly. This is why I would prefer to err on the side of an overly long phase-out period rather than an overly short one. A linear phase-out is preferable to an exponential one for the same reason.
As for attacks, non-upgraded miners may attempt to attack the chain to fool non-upgraded nodes, but this is a risk for any SF. We just have to rely on having most economic nodes upgraded by flag day.
Newbie Offline
Activity: 7
wont it make the network open to attacks if the difficulty suddenly drops low?
Not really. Until it stabilizes, my expectation would be that you would just need to wait for more confirms before you can be assured that the chain you’ve put a transaction in hasn’t been orphaned. Now 6, perhaps as high as 20. When lightning is available, I don’t think that’s really that much of an issue.
Donator Legendary Offline
Activity: 938
There is collateral damage.
But the trade-off is this: allow a certain attack from a malicious actor or potentially allow cheaper-than-usual attacks from unknown actors temporarily.
Right now the mining cartel protects us from any other potential attackers in terms of hashing. Still, not an acceptable situation.
GPG ID: 7294199D – OTC ID: muyuu (470F97EB7294199D) forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
Brand new Online
Activity: 0
I would like to share an hypothesis.
With enough asics a group of miners could offer/sell an alternative to SWIFT for banks?
The group could settle a secret agreement with some banks to raise a few billion US$ for their hash capacity (they would have to leave bitcoin). They would need something like 40% to 50% of bitcoin hash rate to avoid attacks (bitcoin unlimited is in almost 40%?). They would have to keep building asics to keep hash capacity in bitcoin level. Or build even more. Them we would live in a world with 2 major coins. Both only vulnerable to each other hash capacity. The miner (banks backed) would have lot of budget to keep pumping asics until bitcoin is forced to change POW or other mitigation strategy. The group would guarantee its future in asics manufacturing and operations and would ´t care if bitcoin fails. Quick $ with low risk. As it would have a signed contract with major banks to back them. Actually this group of miners would gain with bitcoin suffering. Banks could have a chance to have its own SWIFT and damage bitcoin considerably, gaining more time for their fiat party, with very low costs for them(comparing to acquisitions we are seeing today and the SWIFT value) .
Five Nations Launch Tax Enforcement Alliance to Tackle Crypto, Cybercrime 'Threat' The US Internal Revenue Service (IRS) has launched an international taskforce together with tax enforcement authorities from four other countries to take on cryptocurrency-enabled […]
Subsidiary of Canadian Stock Exchange Operator To Open Crypto Brokerage Service Canadian stock exchange operator TMX Group announced that its subsidiary, Shorcan DCN, has entered into an agreement with Paycase Financial to launch a cryptocurrency […]
bitcoin Price Demolished Overnight Due to China Investigating Market Manipulation & Money Laundering So it’s been a wild ride for bitcoin over the past couple weeks. We shot from $800 to $1129 over the course […]
![Re: [ann] bitcoin pow upgrade initiative](https://bitcointalk.org/useravatars/avatar_64205.png "Re: [ann] bitcoin pow upgrade initiative"){kind=avatar}
![Re: [ann] bitcoin pow upgrade initiative](https://ip.bitcointalk.org/?u=https%3A%2F%2Fcloud.githubusercontent.com%2Fassets%2F6071028%2F24334282%2F39bb2d68-1257-11e7-996d-0dddacda9c09.png&t=575&c=H9nWcFlE9XPG7w "Re: [ann] bitcoin pow upgrade initiative")
![Re: [ann] bitcoin pow upgrade initiative](https://bitcointalk.org/Themes/custom1/images/ip.gif "Re: [ann] bitcoin pow upgrade initiative")
![Re: [ann] bitcoin pow upgrade initiative](https://bitcointalk.org/useravatars/avatar_50688.png "Re: [ann] bitcoin pow upgrade initiative"){kind=avatar}
