* [bitcoin-dev] idea post: bitcoin side chain implementation
@ 2017-09-25 21:53 Patrick Sharp
2017-09-25 22:58 ` CryptAxe
2017-09-26 0:01 ` ZmnSCPxj
0 siblings, 2 replies; 6+ messages in thread
From: Patrick Sharp @ 2017-09-25 21:53 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] idea post: bitcoin side chain implementation
2017-09-25 21:53 [bitcoin-dev] idea post: bitcoin side chain implementation Patrick Sharp
@ 2017-09-25 22:58 ` CryptAxe
2017-09-26 0:07 ` Patrick Sharp
2017-09-26 0:01 ` ZmnSCPxj
1 sibling, 1 reply; 6+ messages in thread
From: CryptAxe @ 2017-09-25 22:58 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Patrick Sharp
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
Have you taken a look at Elements or Drivechains yet by chance?
[-- Attachment #2: Type: text/html, Size: 86 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] idea post: bitcoin side chain implementation
2017-09-25 21:53 [bitcoin-dev] idea post: bitcoin side chain implementation Patrick Sharp
2017-09-25 22:58 ` CryptAxe
@ 2017-09-26 0:01 ` ZmnSCPxj
1 sibling, 0 replies; 6+ messages in thread
From: ZmnSCPxj @ 2017-09-26 0:01 UTC (permalink / raw)
To: Patrick Sharp; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 6969 bytes --]
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: bitcoin-dev@lists•linuxfoundation.org
To: bitcoin-dev@lists•linuxfoundation.org
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: 8093 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] idea post: bitcoin side chain implementation
2017-09-25 22:58 ` CryptAxe
@ 2017-09-26 0:07 ` Patrick Sharp
2017-09-26 0:35 ` ZmnSCPxj
0 siblings, 1 reply; 6+ messages in thread
From: Patrick Sharp @ 2017-09-26 0:07 UTC (permalink / raw)
To: CryptAxe; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
I shamefully was not aware. However familiarized myself with them.
Non official chains suffer from the fact that few if any miners are going
to mine them so they lack security on par with the main chain. And more
over most users aren't going to use them because its not magic.
That being said think they are and will always be a great place to develop
and prove out concepts.
If my ultimate goal is official side chains that include part of the reward
such security is at parity between all chains and that the official
software automatically enable users to distribute their burden, would my
course of action be to build an external proof-of-concept side chain of
side chains?
or do you doubt that official reward splitting chains will ever find their
way into bitcoin core?
On Mon, Sep 25, 2017 at 4:58 PM, CryptAxe <cryptaxe@gmail•com> wrote:
> Have you taken a look at Elements or Drivechains yet by chance?
>
[-- Attachment #2: Type: text/html, Size: 1317 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] idea post: bitcoin side chain implementation
2017-09-26 0:07 ` Patrick Sharp
@ 2017-09-26 0:35 ` ZmnSCPxj
2017-09-26 1:15 ` Patrick Sharp
0 siblings, 1 reply; 6+ messages in thread
From: ZmnSCPxj @ 2017-09-26 0:35 UTC (permalink / raw)
To: Patrick Sharp; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
Good morning Patrick,
>Non official chains suffer from the fact that few if any miners are going to mine them so they lack security on par with the main chain.
That is why most sidechain proposals use some kind of merge mining, where a commitment to another chain's block is published on the Bitcoin chain. Drivechain has "blind" merge mining, my recent "mainstake" proposal publishses entire sidechain block headers on the mainchain. These techniques provide security that is nearer to mainchain security.
>And more over most
>users aren't going to use them because its not magic.
No technology is magic, so I do not understand this sentence.
>If my ultimate goal is official side chains that include part of the reward such security is at parity between all chains and that the official software
>automatically enable users to distribute their burden, would my course of action be to build an external proof-of-concept side chain of side chains?
>or do you doubt that official reward splitting chains will ever find their way into bitcoin core?
I think it would be better to term your system as "sharding" rather than "sidechain".
If and when we are able to actually agree upon some kind of sidechain-enabling proposal that is acceptable to the majority of Bitcoin Core developers, then yes, you should make a sidechain that is capable of sharding. Sharding a distributed ledger while ensuring correct operation is a hard problem; in particular it is almost impossible to protect against double-spending unless you can see all officially-added-to-the-chain transactions.
See: https://petertodd.org/2015/why-scaling-bitcoin-with-sharding-is-very-hard
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 2142 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] idea post: bitcoin side chain implementation
2017-09-26 0:35 ` ZmnSCPxj
@ 2017-09-26 1:15 ` Patrick Sharp
0 siblings, 0 replies; 6+ messages in thread
From: Patrick Sharp @ 2017-09-26 1:15 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
By magic I meant that that it happens all by itself without any extra
configuring.
Thank you for your responses. I have been enlightened. As ZmnSCPxj has
pointed out lightning network and pruning accomplishes everything I set out
to accomplish. And sharding is exactly what I had in mind. I will keep this
in the back of my mind and perhaps even attempt will implement it if it
still seems worth doing later.
You guys are totally awesome!!!
I here by withdraw my proposal for the time being.
-patrick
On Mon, Sep 25, 2017 at 6:35 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning Patrick,
>
>
> >Non official chains suffer from the fact that few if any miners are going
> to mine them so they lack security on par with the main chain.
>
> That is why most sidechain proposals use some kind of merge mining, where
> a commitment to another chain's block is published on the Bitcoin chain.
> Drivechain has "blind" merge mining, my recent "mainstake" proposal
> publishses entire sidechain block headers on the mainchain. These
> techniques provide security that is nearer to mainchain security.
>
> >And more over most
> >users aren't going to use them because its not magic.
>
> No technology is magic, so I do not understand this sentence.
>
> >If my ultimate goal is official side chains that include part of the
> reward such security is at parity between all chains and that the official
> software
> >automatically enable users to distribute their burden, would my course of
> action be to build an external proof-of-concept side chain of side chains?
> >or do you doubt that official reward splitting chains will ever find
> their way into bitcoin core?
>
> I think it would be better to term your system as "sharding" rather than
> "sidechain".
>
> If and when we are able to actually agree upon some kind of
> sidechain-enabling proposal that is acceptable to the majority of Bitcoin
> Core developers, then yes, you should make a sidechain that is capable of
> sharding. Sharding a distributed ledger while ensuring correct operation
> is a hard problem; in particular it is almost impossible to protect against
> double-spending unless you can see all officially-added-to-the-chain
> transactions.
>
> See: https://petertodd.org/2015/why-scaling-bitcoin-with-
> sharding-is-very-hard
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 3400 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-09-26 1:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-25 21:53 [bitcoin-dev] idea post: bitcoin side chain implementation Patrick Sharp
2017-09-25 22:58 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox