Secure Sharedrop Protocol

in gridcoin •  7 years ago  (edited)

This protocol extends on the idea by @cm-steem to transfer Gridcoin to new codebase and blockchain. It has been show by Martin Grothe that some private information can be recovered from the blockchain and since we can't just change a data in a blockchain (a Hash List) we need to somewhat transfer the account balances to new chain. This protocol aims to do this process securely, that is without a single entity governing the process. Instead, the users of Gridcoin will have a share on validating the whole transition.

Edit: This is an developer note, an Idea for discussion. Not something to be promoted to top of Gridcoin feed.

Logo_new

From some block, two chains will run in parallel. The new chain will start with genesis as normal coins do. But the mint mechanism on the new chain will be absolutely new thing. No PoW not PoS, but blocks on the new cahin will be secured by blocks from the old. Blocks on the old chain are signed by the same key as coinstake kernel input. How the new blocks will be created:

User A founds a kernel on the old chain, he will:

  • create empty block Bold for the old chain and Bnew for the new
  • include transactions from mempool into BOld using standard mechanism
  • copy and transcode transactions from BOld into BNew using Sharedrop method
  • add and transcode more unspent transactions from old chain to BNew
  • put height of BOld in BNew
  • sign BNew by the kernel key
  • put height and hash of BNew in BOld
  • sign BOld with the kernel key
  • publish both blocks

Conflict resolution:

  1. blocks on new chain that don't satisfy rules are rejected
  2. if hash of this bad block ends up in block on old chain, it is ignored, but the block is still let in the old chain (as nodes that don't run this dual-chain would fork with higher weight)
  3. if block on new chain is signed by different key than corresponding block (by heigh) on the old chain, then it is rejected
  4. Rule 2 must be enforced even for existing blocks on new chain, as the old can experience reorganizing

Sharedrop is a process of translating unspent transactions from the old chain in the new blocks. Since the old chain continues to run, this new transactions must be translated too. Transactios on new chain have different hash than on old, some lookup table must be used.
When transcoding a new transaction:

  • it's hashboinc is cleared
  • for each input:
    • if corresponding transaction is in the new chain, the input hash is replaced by corresponding new transaction hash
    • othervise the input is marked as generated
  • output scripts are unchanged
  • the old_trxid is blacklisted from future transcoding
  • the new-old, old-new mapping is recored into lookup table

For sharedropping old UTXOs:

  • Miner can select any transaction from the old chain that is
    • not blacklisted from prefious transcoding
    • has at least one, nonzero onspent output
  • the transaction is transcoded as described above
  • this process repeats until the block size limit is reached or the
    transaction pool was exhausted

When all the transactions from old chain will be transcoded, both chains will continue running for a while. By some event the new chain will switch from this sharedrop minting protocol to classic PoS protocol and transaction transcoding will be disabled. At this point the old chain will become independent and should be abandoned.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

How much work is needed to implement this? Sounds like a huge project...

I estimate it as Dynamic Witness Participation and Secure Account Association combined. By doing all three in one go, I estimate work saving of 15%.

Wouldn't it be easier to just take a snapshot of all UXTO at the sharedrop date, and users just import their private keys from there - any additional coins created on the research chain aren't included in the new blockchain.

Though the above would be unstable for POS until a sufficient quantity of users had claimed their stake and begun staking..

In your scenario the problem could be solved by initial PoW period.

Which wouldn't be the end of the world to be honest, as long as it wasn't ASIC/GPU mineable and it didn't add serious sync time like the initial scrypt blocks do within the research client (at least that's the common complaint I've heard about the research init blocks).

Wouldn't it be easier to just take a snapshot of all UXTO

How are you going to do it? This article is about how to do this bit secure and fair.

yo send me good stuff yo !
thks

What is your address?

is any one there?

no, disappeared yet?

  ·  7 years ago Reveal Comment

hey still there ? are you a alien from outerspace?

can you seeend me some abstract of your work??? plz
what is you adress?
who are you
what's your name how much do you weigth?

rue 14 kagenec 67000 stbg

Sorry, I can't send Grdcoins to that address.

ok no probleme we keep in touch
i send you every thing you need , back up here it comes !!!
http://labourseauquotidien.fr/