New Sidechain Concept

[a63ntsm1th]

Asymmetric Co-Dependant Cipherblock Sidechain

http://goo.gl/O1cww

Attached is an improved solution for bitcoin sidechains. I believe that some type of flexible sidechain framework could expand bitcoin considerably. The inspiration for this paper comes from both the Namecoin and DIANNA projects.

http://bot-bit.org
http://dianna-project.org/wiki/

Under current conditions this framework is not workable and as such has not been fully developed. However it will work if you assume the following:

The ability of bitcoin transactions related to sidechain transactions to be disseminated over the bitcoin network, could be restricted.

Given that, this sidechain framework attempts to do the following:

Develop (a) sidechain framework that

    Does not require seperate currencies
    Does not need full or significant adoption by the bitcoin network
    Does not mirror the bitcoin blockchain block for block
    Uses and is dependant on bitcoin

I post this here in hopes that there are further improvements possible to this framework, or saving that, it may inspire development of related project or ideas.

TLDR:

If you made a sidechain out of broken transactions and blocks with missing keys, and placed those keys in the bitcoin blockchain, you could make the sidechain dependant on bitcoin.

If you broke bitcoin transactions in the same way, placing keys to them in the sidechain transactions or blockchain, then you could make bitcoin transactions dependant on the sidechain.

If you could do both those things then sidechain blocks wouldn't have to mirror the blockchain, you wouldn't need a seperate currency, you wouldn't need proof of work, it wouldn't need significant acceptance, and it would be immune to takeover by the bitcoin network.

[1714789831]

1714789831

[1714789831]

1714789831

[1714789831]

1714789831

[ripper234]

This should be moved to Development & Technical Discussion.

Also, linking to PDF with just diagrams, no explanations, isn't really saying much.

Please TL;DR the idea and explain it.

[a63ntsm1th]

Ha, that was fast, sorry for wrong link. Is working now. Dont know how to really TLDR it...

Edit: Added TLDR to OP

[Ente]

Sidechain?
Uhm.. like.. transferring bitcoin outside the blockchain, i.e. anonymously?
I don't fully get your proposal, I fear.

Ente

[a63ntsm1th]

The example used is a Distrubted DNS, it could be used for that, or any time you wanted to register any other type of data in exchange for bitcoin.

It is ideally suited to the registration of publicly verifiable, yet still private/anonymous ownership of, any data you wanted.

[rjk]

Sounds like you just mean merged mining with no independent mining possible. Dianna project was going to do something like that, but pent got lost in an MMM scam and we haven't heard from him since.

[Ente]

The example used is a Distrubted DNS, it could be used for that, or any time you wanted to register any other type of data in exchange for bitcoin.

It is ideally suited to the registration of publicly verifiable, yet still private/anonymous ownership of, any data you wanted.

..Like Namecoin, for example, but with its blockchain interwoven with the Bitcoin blockchain?
And more general altogether, so for other projects besides Namebitcoin too..?

Sounds great! Now, that we have the technology, what will be the killerapp? :-)
*somewhat reminded of Bitcoin as a whole*

Ente

[a63ntsm1th]

..Like Namecoin, for example, but with its blockchain interwoven with the Bitcoin blockchain?And more general altogether, so for other projects besides Namebitcoin too..?

That is a good way of putting it.
Also this framework if used for a DDNS would not create a seperate currency or require a sudechain block for every bitcoin block as Namecoin currently does.

[a63ntsm1th]

If you were looking for a killer app, here are some things that could be done with a framework like this:

DDNS
Corporate registry
OTC corporate shares exchange (subchain of corp chain)
Voter registry
Land registry
Corporate Bonds/Debt (repayment unenforceble?)
Local voting (out of the box independant and verifiable etc.)
Payment Reciepts (?)
Insurance (?)

Thats what comes to mind, any other ideas?

[a63ntsm1th]

Please ,do not be so "diversified" 
instead -- pick up one or two of these goals
and implement such a sidechain in your favorite language.

Or at least write a whitepaper 

I thank you very much for your suggestions and I will indeed continue to seek out solutions to the problems.

The goal is to be diversified in developing the framework. As it stands currently this framework cannot be implemented as I stated in OP.

I guess mostly I was wanting to see if people thought this was barking up the wrong tree or if there was something to it. To this point it seems like mostly positive feedback which I am very grateful for!

[Ichthyo]

If you were looking for a killer app, here are some things that could be done with a framework like this:

.....

Thats what comes to mind, any other ideas?

To put it in a more abstract, general way: you can use it as network or transport layer for any kind of administrative act.

Think of the layered architecture of our current networks. All kinds of services can be built on top of such a viable service layer.


Obviously it should be combined with asymmetric cryptography, and the kinds of protocols which can be built with that. Handshakes and exchange of unique tokens. A bitcoin-like foundation can fill in here exactly what these protocols are lacking: a provable ordering of interactions.

The following example (just one of thousand possibilities) might underpin my point:

Anonymous insurance.
You pay and acquire insurance tokens in return.
Some incident happens, forcing you to draw on your insurance: now you contact a survey report service, which confirms the incident/damage and signs a sufficient amount of insurance tokens. These signed insurance+survey tokens now allow you to receive payment by a cooperating service. Note: none of the involved entities need to know and store the full disclosure of what happened


Bottom line: please don't try to build specific services.
Rather concentrate on creating an administrative transport layer on top of the bitcoin/sidechain network layer.

this will allow others to build peer-to-peer administrative facilities on top, without the need of central, controlling authorities.

[a63ntsm1th]

Great ideas Ichthyo !

I was beginning to think along your lines as well, that an administrative layer is needed.

Some people found the idea interesting and bitcoin 2012, so I will continue to think of ways to improve the design!

[Mike Hearn]

I didn't see this post originally, but all the goals cited in the first post can be met with the design that has been on the alternative chains wiki page for over a year:

https://en.bitcoin.it/wiki/Alternative_Chains

[Come-from-Beyond]

From the attached PDF-document:

The proof of work functions are primarily used in delaying the generation of blocks to facilitate the synchronizing of the blockchain over the network, and restricting the issuance of currency.

Not 100% true. Proof-of-work is used to reach consensus which is more important than delaying.

We shouldn't add extra data into Bitcoin's blockchain. It grows very fast. Imagine how much data it'll be necessary to transmit when Bitcoin usage reach 100.000 transaction per day.

[jgarzik]

We shouldn't add extra data into Bitcoin's blockchain. It grows very fast. Imagine how much data it'll be necessary to transmit when Bitcoin usage reach 100.000 transaction per day.

Adding extra data to the coinbase transaction found in every block is just fine.  That is how merged mining is accomplished today, and it is a scalable method of adding unlimited amounts of data to each block.

[a63ntsm1th]

I didn't see this post originally, but all the goals cited in the first post can be met with the design that has been on the alternative chains wiki page for over a year:

https://en.bitcoin.it/wiki/Alternative_Chains

Thank you Mike, I had read that and there were a couple of things I found undesirable about the method mentioned in the wiki, hence my attempt.

First, requiring payment after the registration has been made is a potential solution, but is not as desirable an arrangement as merely paying straight up front for the registration.

Secondly keeping funds in deposit as collateral is an interesting way of addressing the issue of doing the initial registration, however again it is not a desirable arrangement financially or economically. It is economically inefficient as the cost of registering a domain far outweighs the reward to those providing the service. Of course the values could be swapped but lowering the deposit amount creates different problems (one I can think of would be easier domain registration DOS attacks).

Also any sidechain using this method of adding incentive to registration and processing of that sidechain would be essentially taking money out of circulation of the economy. Theoretically services using this method could potentially put all bitcoin out of circulation, especially if it were deemed more valuable at the time to do so. In addition, generally the amount of economic activity facilitated by a given amount of currency is usually many multiples of the base value of the currency in even just a year. So removing this currency would have a magnified effect on the wider economy. Simply put, this is truly deflationary.

I am attempting to bring the data transaction (in this case registration of a domain name) as close as possible to a real world exchange.You simply pay in bitcoin to the miner to have your sidechain transaction processed.

I am also thankful for getting such great feedback in this thread! I work toward solving the flaws in this design. I was trying to think of a way of making a bitcoin transaction "unsharable" or local only. Some way to make all other miners reject the transaction but it still be valid for the local node to process it...

[freequant]

Create co-dependancy:
The other dependancy needed to be created is the dependancy of bitoin transactions upon sidechain transactions. We perform the same operation as above in that when the bitcoin transaction is created alongside the sidechain transaction, data from the sidechain transaction is included prior to its authentication, biut removed after authentication.
The concept here is to restrict the processing of the bitcoin transaction associated to sidechain transactions, to those who have the sidechain.

If regular clients can't process the transaction, they will drop the block and you'll get a fork...

[thomkaufmann]

Sounds great! Now, that we have the technology, what will be the killerapp? :-)
Ente

How about a decentralized torrent tracker for a killer app?

[jgarzik]

Sounds great! Now, that we have the technology, what will be the killerapp? :-)
Ente

How about a decentralized torrent tracker for a killer app?

Someone wrote that a long time ago: the DHT.

[Ente]

How about.. a Ripple style p2p exchange?
It seems like several people are thinking about ripple, and it's place in the Bitcoin universe, right now..

Ente