public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Patrick Sharp <psharp.x13@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] idea post: bitcoin side chain implementation
Date: Mon, 25 Sep 2017 15:53:30 -0600	[thread overview]
Message-ID: <CAES+R-q6v=Qc2zZgczNfKhrBtZ0kCt0Um90miAMGB0npp4zAKQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4444 bytes --]

Hello Devs,

I am Patrick Sharp. I just graduated with a BS is computer science. Forgive
my ignorance.

As per bip-0002 I have scoured each bip available on the wiki to see if
these ideas have already been formally proposed and now as per bip-0002
post these ideas here.

First and foremost I acknowledge that these ideas are not original nor new.

Side Chains:

Bip-R10 offers a mechanism to assign custody or transfer coins from one
chain to another. However I did not find a bip that proposed a formal
bitcoin side chain.

My proposal

   - They are officially supported, tracked and built by official bitcoin
   software meaning that they are not an external chain
   - each chain has an identifier in the block header i.e. main chain: 0,
   first chain: 1, second chain: 2...
   - the number of chains including the main chain that exists is always a
   power of 2, this power will also be included in the block header.
   - each address is assigned to a chain via chain = (address) mod (number
   of chains)
      - to be valid an addresse's next transaction will first send their
      coins to their chain if they are not already there
      - if the address they are sending to is outside their chain their
      transaction will be submitted to both chains and transaction fee will be
      split between chains
   - They come into being via a fork or split
      - every 2016 blocks (upon recalculation of difficulty) if some
      percentage (lets say 10%) of blocks on any chain are larger than some
      specified amount (lets say 750 KB) then all chains are called to
increment
      their power value and fork on their block.
         - miner of chain x creates genesis block for chain x+2^previous
         power
         - upon fork, the difficulty of the old chain and the new chain
         will be half the next difficulty
      - if every chain has gone 2016 block without surpassing some amount
      (lets say 250 KB) at least some percentage of the time (lets say 10%) all
      chains will be called to join, decrement their power and double their
      difficulty
         - given miner of chain x, if x not less than 2^new power, chain
         will be marked dead or sleeping
         - miners who mine blocks on the chain that was joined (the chain
         with the smaller identifier) may have to make a block for the sleeping
         chain if transactions include funds that fully or partially
originate from
         the sleeping chain
         - dead chain are revived on next split.
      - each block's reward outside of transaction fees will be the
      (current bounty / 2^fork power) except obviously for dead blocks who's
      reward is already included in their joined block
   - benefits
      - dynamically scales to any level of usage, no more issues about
      block size
      - miners have incentive to keep all difficulties close to parity
      - if miners are limited by hard drive space they don't have to mine
      every chain (though they should have trusted peers working on
other chains
      to verify transactions that originate off their chains, faulty block will
      still be unaccepted by the rest of the miners)
      - though work will still grow linearly with the number of chains due
      to having to hash each separate header, some of the overhead may remain
      constant and difficulty and reward will still be balanced.
      - transactions are pseudo equally distributed between chains.
      - rewards will be more distributed (doesn't' really matter, except
      that its beautiful)
   - cons
      - because most transactions will be double recorded the non-volatile
      memory foot print of bitcoin doubles (since miners do not need
all chains i
      believe this solution not only overcomes this cost but may decrease the
      foot print per miner in the long run overall)
      - transactions will hang in limbo until both chains have picked them
      up, a forever limboed transaction could result in lost coins, as
long as a
      transaction fee has been included this risk should be mitigated.

I believe this idea is applicable to the entire community. I would like
your thoughts and suggestions. I obviously think this is a freaking awesome
idea. I know it is quite ambitious but it is the next step in evolution
that bitcoin needs to take to be a viable competitor to visa.

I come to you to ask if this has any chance of acceptance.

-Patrick

[-- Attachment #2: Type: text/html, Size: 5605 bytes --]

             reply	other threads:[~2017-09-25 21:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25 21:53 Patrick Sharp [this message]
2017-09-25 22:58 ` [bitcoin-dev] idea post: bitcoin side chain implementation CryptAxe
2017-09-26  0:07   ` Patrick Sharp
2017-09-26  0:35     ` ZmnSCPxj
2017-09-26  1:15       ` Patrick Sharp
2017-09-26  0:01 ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAES+R-q6v=Qc2zZgczNfKhrBtZ0kCt0Um90miAMGB0npp4zAKQ@mail.gmail.com' \
    --to=psharp.x13@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox