From: creighto@sdf.org
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Con-peg sidechain model
Date: Wed, 15 Nov 2017 02:13:31 -0000 [thread overview]
Message-ID: <5d7cceb34b3d49a0fc9822450e42c750.squirrel@mx.sdf.org> (raw)
I posted the following on bitcointalk.org and slack bitcoinunlimited.
This isn't a technical paper, just fleshing out my thoughts and hoping for
some help & feedback. I understand bitcoin as well as any non-programer
realisticly could, but I am not a programmer, so if this isn't feasible,
someone please let me know why.
-MoonShadow
Con-Peg Sidechain Model
I know that this is going to sound similar to the Fed-Peg model, so don't
whine about that. It's not the Fed-Peg model, not quite, and the
differences are critical, I believe.
Every proposal that I've seen so far require some kind of soft or hard
fork to the current bitcoin model, but I think that I've come up with a
way to make a sidechain work without new modifications to the running
bitcoin protocol.
I think I will call it the Confederation-Peg model.
Imagine a confederation of large corporations, all of which would benefit
from the ability to process a large number of bitcoin transactions for net
zero or near zero transaction fees.
These corporations would, most likely, have to have the following
characteristics...
1) Multi-national in scope, with employee bases in several different
nations using several different fiat currencies.
2) Have a rather large employee base.
3) Not in direct competition with each other
4) and not dependent upon any particular government.
With just a bit of google-fu, I will use the following corporations in
this example...
Wal-Mart, with more than 2 million employees worldwide.
Volkswagon, with more than half a million employees worldwide.
General Electric, with about 300K employees worldwide.
and Johnson & Johnson, with More than 100K.
Let's call these corporations the confederation sponsors. These sponsors
would decide most of the sidechain's rules by consensus amongst
themselves, but let me lay out, in general, how I think that such a
sidechain can be set up so that the sidechain is secure while also
contributing to the overall security of the main blockchain.
First, these sponsors agree upon a deposit/escrow amount that they will
each commit to a multi-sig address on the main blockchain; for a round
number, let's say they all contribute 10 BTC to the cause. Next, they all
agree that they must each either build or contract out bitcoin mining
capability of a minimum standard; high enough that the collection of
sponsors can mine a block on a regular interval. Let's say once each day.
But when they mine a main blockchain block, they place into the 100 byte
large "2nd nonce" space of the coinbase transaction the following data.
1) a code that identifies the sponsor who mined this block to the other
sponsors,
2) the merkle tree root hash of the sidechain block that the sponsor is
about to release on the sidechain network.
3) a cryptographic signing of the two prior pieces of data. (this might be
unnecessary, I'm not sure)
Once a sponsor's mining agent releases this block to the network, and it's
accepted as valid by the main blockchain, The sponsor then releases the
sidechain block to the other sponsors. This block can be of an arbitrarily
large size; enough to accommodate all of the transactions that all of the
sponsors (and their clients) have produced in the past day. Since it's
likely that every sponsor has seen every valid transaction, this block
might only include the merkle tree created by the most recent mining
sponsor.
This looks a lot like merged mining, but it's not, because the side chain
doesn't use proof-of-work, and doesn't require it. It uses
proof-of-authority. Specifically, releasing a valid block onto the main
blockchain is the proof of the authority to release the next sidechain
block. This achieves several things for the sponsors.
1) It contributes mining power to the main blockchain, thus supporting
main chain security regardless of the profitability for those sponsor
miners, since their incentive is to reduce the costs of their own
transactions, not win mining rewards or fees.
2) It creates a definate timeline of the blockchain of the sidechain,
without need for cryptographic proof-of-work, by tying each sidechain
block to a known main chain block. Thus leveraging the main chain's
security model without needing to attract miners willing to drop the main
chain work to mine the sidechain.
3) It establishes a definitive authority amonst the sponsors about who has
the right to publish the next block, as well as claim any sidechain
transaction fees.
4) It allows all sponsors to keep each other honest, because if any
sponsor were to cut back on their main chain mining responsibilities, they
would all be able to tell.
5) It allows the sponsors to chose to accept as many free transactions as
they like, which may or may not benefit themselves,
6) as well as keep any transaction fees that might have been issued on the
sidechain, for which odds are high that they would have had to pay. Thus
transaction fees most likely travel in a circle (for the sponsors, not the
clients)
In order to add btc to this sidechain, a main chain bitcoiner would have
to send funds to one of the sponsors, after acquiring their agreement to
issue sidechain coins using a special sidechain coinbase transaction
that...
1) creates or destroys sidechain bitcoins
2) references the main chain transaction that would permit it
3) and identifies the sponsor creating the sidechain funds
In this way, bitcoins can flow into the sidechain, and each of the
sponsors can watch the other sponsors to make certain that they aren't
creating more sidechain funds than their main chain holding would permit.
I would imagine that the rule would be that a sponsor can't issue more
side chain bitcoins than it has in it's public main chain addresses, and
if that were to be violated, the other sponsors would automatically ignore
their (otherwise valid) sidechain blocks.
This security model requires more trust than the trustless model of the
main blockchain, but permits the sidechain to structure itself in any way
necessary to permit safe referencing of unconfirmed transactions, thereby
permitting nearly instant follow-up transactions. Sponsors could also
detect, and potentially punish, double spend attemps. Any other rapid
transaction model, such as the Lightening Network, could be permitted to
work on the sidechain; but I doubt they would be necessary.
Sponsors could attract "clients" by a number of incentives. For example,
Wal-mart could offer free sidechain transactions to any paying customer,
as well as a limited number of main chain transactions to their own
employees; whereas Johnson & Johnson might only offer free transactions to
their employees and associated businesses. I can even imagine a deposit &
(fully BTC reserve backed) sidechain credit system, complete with interest
rates.
Paid for transaction fees could be based upon whatever the sponsors agree
to, including a transaction fee based upon a percentage of the transfer
value instead of the byte-size of a transaction. This would make the fee
model much closer to how current day credit card transfer fees work, but
would almost certainly be less.
Getting BTC back out of the sidechain (via the main chain) would work like
a sponsor's coinbase transaction with a negative value, also referencing a
valid transaction (which may or may not be confirmed yet) that can be seen
on the main bitcoin network. Alternatively, in a world where several such
sidechains exist, sponsors of one sidechain could be clients on another,
potentially permitting value to transfer from one sidechain directly to
another without creating a main blockchain transaction at all. The details
of the rules of both sidechains would matter in this possibility.
Since declaring weeknesses of one's own ideas is a convention in the
cryptocurrency world, let me begin...
Since this is a some-trust model; i.e. individuals have to trust an
institution, at least a little bit, in order to get onto the sidechain.
It's possible that a sponsor might take your main chain BTC and claim you
never sent them, but you'd still have the transaction you produced, so
you'd still have recourse through traditional courts.
Moving funds in the other direction, it's possible for your leaving
transaction to be blocked, but only if all of the sponsors refuse to deal
with you. Likewise, as a client, your ability to transact on the sidechain
could be hindered or blocked by the sponsors, but only if all of them
blacklist you. But that only risks the possibility that you can't spend
your bitcoins on the sidechain, not that the sponsors could take them from
you without your participation.
This is a move towards some centralization, yes; but not for bitcoin as a
whole. For the most part, "clients" choose whether the lower transaction
costs & convenience at these institutions is worth the re-addition of
trust to some portion of their bitcoin activities. Perhaps employees don't
get a choice about being a client on this sidechain, but they still get to
choose if they work for a sponsor.
This low-trust model depends upon the idea that the sponsors don't
entirely trust one another, and will keep an eye on each other for bad
behavior; much in the same way that the banks of the free banking era
would occasionally challenge one another to produce the gold for the
currencies they issued, either driving them out of business or harming
their businesses should they misbehave. It also depends upon the idea
that, for the "clients", no one on the sidechain has more to lose from
getting caught defrauding a client than the sponsors themselves, because
the integrity of the sidechain and of their own reputations are of great
value to the sponsors. It's possible that all sponsors turn to the dark
side at once, crash the sidechain & steal all of the main chain bitcoins
in their reserve addresses. Since this isn't one trusted authority, but
many in a trust-distrust relationship (and in different industries) this
possibility seems remote to me.
I could also imagine sidechains that were explicitly not worldwide in
scope, such as those limited to a particular nation or economic block.
I.E., there might be a Eurozone specific sidechain, a United States
specific sidechain (but would that be redundant?) and a Francophone
sidechain. There might be a sidechain for Portuguese speaking nations
around the world, or a sidechain just for nations in South America that
don't speak Portuguese.
There could be a sidechain that exists entirely on Tor, using high
anonymity rules; or a sidechain sponsored by governments for the expressed
purpose of paying taxes (but who would join this voluntarily?)
Many people have complained that Bitcoin isn't anonymous, because the
entire transaction history is visible. Sidechains would fix that
immediately, even without improved anonymity rules.
For that matter, since the extra-nonce space available in the coinbase
transaction is 100 bytes, that's enough to record an entire sidechain
block header anyway, so there might not be any reason to record the
headers anyplace else.
reply other threads:[~2017-11-15 2:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=5d7cceb34b3d49a0fc9822450e42c750.squirrel@mx.sdf.org \
--to=creighto@sdf.org \
--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