Good morning Patrick,
Your idea seems to focus more on scaling than on what sidechains actually were
originally considered for.
Sidechains were originally designed to add and prototype new features to
Bitcoin. Increasing the effective block size is not what sidechains were
expected to do.
For scaling, Lightning Network is a superior solution, as it keeps most
transactions off-chain.
Features are the important thing that sidechains are supposed to add to Bitcoin.
1. Addresses are not how Bitcoin works under-the-hood. Instead, P2PKH and P2SH
addresses represent 2 kinds of standard output scripts. It is possible in
theory (with a lot of endless debate) to add new standard output scripts, some
of which may not have an equivalent of an address.
2. It is easy to game your system. A miner needs only to send a bunch of
transactions from himself to himself to trigger the splitting condition. It
would even be possible to hide this somewhat by generating new public/private
key pairs.
3. The problem with on-chain scaling is not that the code has this 1Mb limit.
The problem with on-chain scaling is delivering all of the block data to the
rest of the network. Crucially, in the case that block data delivery is slow,
a larger mining pool with more resources and greater ability to handle larger
blocks, will work better than smaller pools or solo miners due to orphan
rate/stale rate. Thus it is in the interest of large mining pools to push for
large blocks and more data per second on-chain, in order to further consolidate
their power and influence over Bitcoin. As the censorship-resistance of
Bitcoin is dependent on there being many small mining pools, larger blocks
destroy censorship-resistance.
4. Disk space is not a problem. It never was the problem. Satoshi even
mistakenly thought it was a problem, but it never was and it never will be.
The problem is that the computations on Bitcoin's security assume that blocks
are delivered in 0 time. That is not true in reality, but the reason why 10
minutes was selected as the block rate is to make block delivery time as close
to 0 (relative to the average block rate) as possible. Increasing block size
makes block delivery time further from the ideal 0 that is the basis of
Bitcon's security.
5. Mining is a random process and once splits occur, you can never assure that
particular chains will synchronize the real-world time of 2016 blocks. I mean,
it would be come possible for one chain to finish in 1 week while another chain
is never worked on. The 2016-blocks schedule is even more likely to misalign
in real time when further splits occur.
Regards,
ZmnSCPxj
-------- Original Message --------
Subject: [bitcoin-dev] idea post: bitcoin side chain implementation
Local Time: September 25, 2017 9:53 PM
UTC Time: September 25, 2017 9:53 PM
From: [email protected]
To: [email protected]
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
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
