Bitcoin Forum
December 16, 2017, 06:47:27 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [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 42609 times)
muyuu
Donator
Legendary
*
Offline Offline

Activity: 966



View Profile
March 24, 2017, 12:26:44 AM
 #181

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.

One that simply transitions progressively from SHA256 to a single cryptohash, I don't think it would be very complicated. I guess it depends on how the transition is coded concretely.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513450047
Hero Member
*
Offline Offline

Posts: 1513450047

View Profile Personal Message (Offline)

Ignore
1513450047
Reply with quote  #2

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

Activity: 95


View Profile WWW
March 24, 2017, 09:14:53 AM
 #182

One that simply transitions progressively from SHA256 to a single cryptohash, I don't think it would be very complicated. I guess it depends on how the transition is coded concretely.

To keep things simple, there doesn't have to be any transition at all, just a flat 5% payout to the new miners. That percentage would be increased in a new SF only in the event of miner misbehavior. On the other hand, if we do decide to go with a gradual transition, I don't see any great technical complexity with that either. Only it would have to be very gradual, otherwise we can't expect any support from the existing mining community.

This is how the system might work:

DRAM miner solves the block with no Coinbase TX but with his payout address appended. DRAM miner broadcasts block, solution and payout address to SHA2 miners. SHA2 miner adds DRAM miner's proof to the Coinbase and a 0.625 BTC output to DRAM miner's payout address in the Coinbase TX. SHA2 miner then solves block as usual. Block is now secured by two PoWs.

Some additional protocol (or messages to existing P2P protocol) will be required for DRAM miners to relay their data to the SHA2 miners, but other than this they don't need to coordinate in any way.

The only additional work required for verifying nodes is to check that payout address and amount are correct and verify DRAM miner's proof.

Not quite sure how we'd handle the matter of difficulty retargeting for the new PoW. This seems to be the trickiest problem.

Would be nice to get some feedback on all this from one of the devs.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
March 24, 2017, 11:15:27 AM
 #183

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?

Vires in numeris
mmgen-py
Member
**
Offline Offline

Activity: 95


View Profile WWW
March 24, 2017, 12:14:33 PM
 #184

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

Activity: 966



View Profile
March 24, 2017, 02:03:43 PM
 #185

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
Legendary
*
Offline Offline

Activity: 1848



View Profile
March 24, 2017, 05:38:59 PM
 #186

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.


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
Member
**
Offline Offline

Activity: 95


View Profile WWW
March 24, 2017, 07:32:36 PM
 #187

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.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
March 24, 2017, 08:25:51 PM
 #188

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.

Vires in numeris
Frogolocalypse
Newbie
*
Offline Offline

Activity: 8


View Profile
March 25, 2017, 02:49:51 AM
 #189

An extension of this post :

   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.
David Rabahy
Hero Member
*****
Offline Offline

Activity: 707



View Profile
March 25, 2017, 04:50:22 AM
 #190

One word; hurry.

Oh, and also, hire a good public relations team.
tenletters
Jr. Member
*
Offline Offline

Activity: 31


View Profile
March 25, 2017, 05:37:04 AM
 #191

One word; hurry.

Oh, and also, hire a good public relations team.

For my part, I will ramp up the marketing once we have 2 or 3 working branched clients (or implementations that don't require client changes) that have been subjected to extensive peer review, and hopefully some libraries+documentation to ease the transition for 3rd party service providers like light wallets and exchanges. Until then, it might not be necessary (or wise).

Actually, the work being done by the devs in this thread has already been covered by a good number of major outlets ([1], [2], [3], [4]).
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1862


WARNING FOR NOOBS: Dash is an Instamined scam coin


View Profile WWW
March 25, 2017, 09:52:26 AM
 #192

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?

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


Let's change PoW so that anyone with moderate amount of capital can attack us, sounds like a great idea!

Agreed. You can hate ASICs, but they do provide a very robust network, very expensive to attack. Change of PoW would do more harm than good.

Right now, to attack Bitcoin you only need to bamboozle Jihan.  Not very expensive.  Cheesy

If Bitcoin is in danger due to such an attack, it's nice to have fully prepared contingency plans ready to deploy.

But the socioeconomic consensus will allow Roger and Jihan to initiate aggression before it reacts with overwhelming retaliatory force.


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1862


WARNING FOR NOOBS: Dash is an Instamined scam coin


View Profile WWW
March 25, 2017, 12:01:59 PM
 #193

A change of PoW as a quickfix (to fool currently manufactured ASICS) without too much risk of bugs can be as follows:

Instead of checking for n zero bits, implement checking for n one bits instead.

If you are bold, you can have the sequence of leading bits to check to be dependant on the trailing bits of the previous block.

Your first suggestion seems to be the simplest thing which would actually work.

But I also like the 2nd one!


An automatic full PoW switch trigger on extremely anomalous conditions.

An option worth considering on all doomsday machines....

https://en.wikipedia.org/wiki/Dead_Hand_%28nuclear_war%29


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
Andre_Goldman
Sr. Member
****
Online Online

Activity: 280

/* https://gnupg.org/donate */


View Profile
March 26, 2017, 06:12:17 AM
 #194

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.


GnuPG is not only used to encrypt email. GnuPG protects software updates for nearly all free software operating systems, which power two-thirds of all servers on the Internet.
pinkflower
Sr. Member
****
Offline Offline

Activity: 420



View Profile
March 26, 2017, 09:28:15 AM
 #195

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?

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



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.



         ▄▄██████████▄▄
      ▄█████████████████                                ▄▄▄▄     ▄▄▄▄     ▄▄▄▄
    ▄███████▀▀   ▀▀██████                              ██████   ██████   ██████
   ▄██████▀        ██████                              ▀████▀   ▀████▀   ▀████▀
  ▐██████          ▀▀▀▀▀▀
  ██████
 ▐██████
 ██████      ███████████▌    ████████▄▄       ▄███▌     ▄██████████ ███████████▌
▐██████      ███████████    ▐███   ▀███▌     ▄████▌     ███▌           ▐███
██████▌          ██████▌    ███▌    ███▌    ███▀███     ███            ███▌
██████▌          ██████    ▐███▄▄▄▄███▀    ███  ███    ▐█████████      ███
███████         ███████    ████▀▀▀███▄    ███   ███▌   ███▀▀▀▀▀▀      ▐███
 ▀███████▄▄▄▄▄████████    ▐███     ███  ▄██████████▌  ▐███            ███▌
  ▀████████████████▀      ███▌    ▐███ ▄███     ▐███  ███▌           ▐███
     ▀▀███████▀▀▀         ▀▀▀     ▀▀▀▀ ▀▀▀       ▀▀▀  ▀▀▀            ▀▀▀▀

║▮
║▮
║▮

▮║
▮║
▮║



                 ▄████▄▄    ▄
██             ████████████▀
████▄         █████████████▀
▀████████▄▄   █████████████
▄▄█████████████████████████
██████████████████████████
  ▀██████████████████████
   █████████████████████
    ▀█████████████████▀
      ▄█████████████▀
▄▄███████████████▀
   ▀▀▀▀▀▀▀▀▀▀▀



       ▄▄▄▄▄▄
    ▄████████
    █████▀▀▀▀
   ▐████
   ▐████
████████████
████████████
   ▐████
   ▐████
   ▐████
   ▐████
   ▐████




                      ▄▄████
                ▄▄▄████████▌
          ▄▄▄███████▀▄█████
     ▄▄█████████▀▀ ▄██████▌
▄▄███████████▀  ▄█████████
 ▀▀▀█████▀    ▄██████████▌
       ██   █████████████
        █▄ █████████████▌
        ▐█▄███▀▀████████
         ███▀    ▀▀████▌
                    ▀▀█


                   ▄▄▄    ▄▄██▄▄
                   ██▀▀██████████
                  ██     ████████
                 ▐█▀      ▀████▀
   ▄▄▄▄    ▄▄██████████▄▄    ▄▄▄▄
 ▄████████████████████████████████▄
▐██████████████████████████████████▌
▐██████████   ▀██████▀   ███████████
 █████████▌    ██████    ██████████
  ▀██████████████████████████████▀
   ▀████████▀▀████████▀▀████████▀
     ▀███████▄        ▄████████▀
       ▀████████████████████▀
          ▀▀▀▀█████████▀▀▀▀
mmgen-py
Member
**
Offline Offline

Activity: 95


View Profile WWW
March 26, 2017, 01:24:38 PM
 #196

Wont this make difficulty rise and fall like a wave?

Each algorithm would have its own difficulty I would imagine.
BitUsher
Hero Member
*****
Offline Offline

Activity: 840


View Profile
March 26, 2017, 05:24:48 PM
 #197

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
Legendary
*
Offline Offline

Activity: 1848



View Profile
March 26, 2017, 07:11:44 PM
 #198

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?

Vires in numeris
mmgen-py
Member
**
Offline Offline

Activity: 95


View Profile WWW
March 26, 2017, 07:27:21 PM
 #199

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.

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.

Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
March 26, 2017, 09:15:03 PM
 #200

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
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!