Could sidechains be the enabler of “semi-decentralised” Bitcoin products and services?
An important paper was published this week:
If you’ve followed Bitcoin for any time, you’ll know this is a seriously eminent group of authors
It describes a way to build “pegged sidechains”. Sidechains themselves are not new – the idea, and how to build them, has been discussed for some time and the key breakthrough was outlined earlier in the year. But this paper gives more detail on the concept and has attracted a lot of comment.
But what are they? And why should anybody care?
A mental model for Bitcoin
The key to understanding most innovations in the Bitcoin space is to make sure you have the right mental model for how Bitcoin itself works. It turns out that most people I speak to don’t really understand how it works and, as a result, have a faulty mental model.
To help with this, I came up with an analogy for Bitcoin earlier in the year, based on thinking of Bitcoin “unspent transaction outputs” as parcels of land. Some people hated the analogy but I still think it has value 🙂
But in this piece, I’ll skip the analogy and net it down to the basics.
First, clear your head of anything related to money, currency or payments. And clear your head of the word ledger, too. The mind-bending secret of Bitcoin is that there actually isn’t a ledger! The only data structures that matter are transactions and blocks of transactions. And it’s important to get this clear in your head if sidechains are going to make sense.
When you “move” Bitcoins, what you’re saying is:
- Hello everybody… I’d like to move these specific Bitcoins, please.
- Here is the proof that I am entitled to move them
- And here is how the recipient will, in turn, prove that they are entitled to move them.
The critical three parts of a Bitcoin transaction
There are several important points here:
- Bitcoins are not perfectly fungible… when you move (or spend) them, you’re spending some specific bitcoins
- In order to spend them, you have to prove you’re entitled to do so. And you do that by providing the solution to a challenge that was laid down when they were sent to you in the first place. This challenge is usually just: “prove to the world that you know the public key that corresponds to a particular Bitcoin address and are in possession of the corresponding private key”. But it can be more sophisticated than that.
- When you send Bitcoins somewhere, you lay down the challenge for the next owner. Usually, you’ll simply specify that they need to know the public and private keypair that correspond to the Bitcoin address the coins were sent to. But it can be more complicated than that. In the general case, you don’t even know who the next owner is… it’s just whoever can satisfy the condition.
Keep saying the three steps to yourself until they’re etched on your memory!
Fine. So the “grammar” of a Bitcoin transaction is clear: “Here are the coins I want to move, here’s the proof I’m entitled to and here’s what the recipient must do, in turn, if they want to spend them”.
This transaction is published into the network, it will eventually find its way into a block and, after other blocks have been built on top, everybody can be pretty sure it won’t be reversed and the world moves on. What more do you need?
The core Bitcoin “grammar” works just fine, mostly…
This three-part structure to a Bitcoin transaction works well and it turns out that you can do some really interesting things with it. For example, you can use the “not-entirely fungible” feature to “tag” coins. This is the basis of the “Colored Coins” and “Smart Property” worlds.
But there are problems, such as:
Bitcoin’s block interval is ten minutes so it takes about
five ten minutes on average for a new transaction to find its way into a block, even if it pays a high fee. This is too slow for some people so they have experimented with alternative cryptocurrencies, based on the Bitcoin code-base, which employ quicker block intervals [UPDATED 2014-10-27 to correct my embarrassing misunderstanding of mathematics…]
The “three-part” transaction structure is very general but it only allows you to transfer ownership of Bitcoins. Some people would like to transmit richer forms of information across these sorts of systems. For example, a decentralized exchange needs a way for participants to place orders. Projects such as Mastercoin, Counterparty, NXT and others either build layers on top of Bitcoin or use entirely different codebases to achieve their goals.
Transaction Transfer Conditions
I said above that you can build sophisticated rules into Bitcoin transactions to specify how ownership is proved. However, the Bitcoin scripting language is deliberately limited and many ideas in the Smart Contracts space are difficult or impossible to implement. So projects such as Ethereum are building an entirely new infrastructure to explore these ideas
One-size-fits-all security model
It doesn’t matter if you’re moving $1bn or 0.01c across the Bitcoin network, you get the same security guarantees. And you pay for this in fees and time. What if you were prepared to trade safety for speed? Today, your only real option is to send the coins to a centralized wallet provider, whom you must trust not to lose or steal your coins. You can then do all the transactions you like on their books, with their other customers and you never need touch the Bitcoin blockchain. But now you lose all the benefits of a decentralized value-transfer network.
One-size fits all doesn’t help if the size doesn’t fit you!
Now, making experimental or rapid changes to Bitcoin is very risky and so change happens slowly. So if the one-size-fits-all architecture of Bitcoin doesn’t suit a particular use-case, you have a problem. You either have to use an entirely different cryptocurrency (or build one!). Or you have to use (or build) a centralized service, which brings new risks.
This is very inconvenient. It creates risk and fragmentation and slows the build-out of products, services and infrastructure.
Centralised Wallet Providers as a “poor-man’s sidechain”?
But there’s an interesting observation we can make. Think about what happens if you send Bitcoins to a centralized wallet such as circle.com for safekeeping.
- You send your coins to a particular Bitcoin address
- They appear inside your circle wallet and are out of your control on the blockchain.
- At some point in the future, you might send your coins back out of your circle wallet to a Bitcoin address you own
- You now have control of some coins on the Bitcoin blockchain again!
From the perspective of the Bitcoin network, Circle is a black box. You had some coins… you sent them to a specific address… some stuff happened that Bitcoin couldn’t see…. And at some point later, you had control of some coins again. It’s as if those coins had been moved from Bitcoin to somewhere else and then back again.
Here’s the Sidechains insight
The key idea behind the sidechains concept is:
What if you could send Bitcoins not only to individuals, addresses and centralized services but to other blockchains?
Imagine there is a Bitcoin-like system out there that you’d like to use. Perhaps it’s litecoin or ethereum or perhaps it’s something brand new. Maybe it has a faster block confirmation interval and a richer scripting language. It doesn’t matter. The point is: you’d like to use it but would rather not have to go through the risk and effort of buying the native tokens for that platform. You have Bitcoins already. Why can’t you use them?
The sidechains ideas is this:
- Send your Bitcoins to a specially formed Bitcoin address. The address is specially designed so that the coins will now be out of your control… and out of the control of anybody else either. They’re completely immobilized and can only be unlocked if somebody can prove they’re no longer being used elsewhere (I’ll explain what I mean by this in a minute). In other words, you’ve used the core bitcoin transaction rules I described above to lay down a specific condition that the future owner – whoever it ends up being – needs to fulfil in order to take control
- Once this immobilisation transaction is sufficiently confirmed, you send a message to the other blockchain – the one you were wanting to use. This message contains a proof that the coins were sent to that special address on the Bitcoin network, that they are therefore now immobilized and, crucially, that you were the one who did it
- If the second blockchain has agreed to be a Bitcoin sidechain, it now does something really special… it creates the exact same number of tokens on its own network and gives you control of them.
- So it’s as if your Bitcoins have been transferred to this second chain. And remember: they’re immobilized on the Bitcoin network… so we haven’t created or destroyed any…. Just “moved” them.
- You can now transact with those coins on that second chain, under whatever rules that chain chooses to implement.
- Perhaps blocks are created faster on that sidechain. Perhaps transaction scripts are “turing complete”. Perhaps you have to pay fees to incent those securing that sidechain. Who knows. The rules can be whatever those running that sidechain want them to be. The only rule that matters is that the sidechain agrees to follow the convention that if you can prove you put some Bitcoins out of reach on the Bitcoin network, the same number will pop into existence on the sidechain.
- And now for the second clever part. The logic above is symmetric. So, at any point, whoever is holding these coins on the sidechain can send them back to the Bitcoin network by creating a special transaction on the sidechain that immobilises the bitcoins on the sidechain. They’ll disappear from the sidechain and become available again on the Bitcoin network, under the control of whoever last owned them on the sidechain.
Sidechains use the standard bitcoin “three-step” transaction to immobilise bitcoins whilst they’re “on” the sidechain
So, to repeat, we’ve used standard Bitcoin transaction functionality to move coins out of reach and we then prove to a second, unrelated chain, that we’ve done this. And when we’re done, whoever owns them on the sidechain can do the same thing and send them back to the bitcoin network.
So developers get the opportunity to experiment with different types of cryptocurrency rules without needing to create their own currency.
And it now becomes possible to do some very interesting things in the Bitcoin space.
Step back from the details for moment and consider what’s been described. We now have a way to move coins from Bitcoin onto another platform (a sidechain) and move them back again. That’s pretty much what we do when we move them to a wallet platform or an exchange. The difference is that the “platform” they’ve been moved to is also a blockchain… so it has the possibility of decentralised security, visibility and to gain from other innovation in this space.
For example, one could imagine a sidechain that is “mined” only by one company. That would be identical to a single-company wallet, but with full visibility of transactions.
Going further, you could imagine a sidechain that is mined by 100 different companies in a loose federation. Not totally decentralized, but harder to censor or subvert than if it were just one.
And there are lots of other possibilities. The key is that you can build these experiments and products and services without also needing to create a new currency or fall back into the old centralised style.
So when I look at sidechains, I’m looking at them as an architecture for building semi-decentralised products and services for Bitcoin that were simply impossible before.
Now there are some serious issues with the scheme. Peter Todd has raised doubts about how secure it might be and it might require a one-off change to Bitcoin.
But it’s early days. I’m looking forward to watching this space develop
I listedned to Adam Back speaking on this concept on the LTB show episode 99. I thought it was a genius idea at the time and it will allow experimenting. The bitcoin community will offer the right amount of critic to see that any flaws/ potential faults are sealed.
THis concept opens up doors to Central banks taking part in the blockchain under a defined set of rules! That might be fun to see unfold.
For now we wait and see.
Hi Richard- How does this concept differ from http://en.wikipedia.org/wiki/Ripple_(payment_protocol)?
How is this like Ripple?
Reblogged this on Global-hardware.
Reblogged this on Maverisk and commented:
Noteworthy. In one sense, a dilution. In another, a move to widespread adoption and acceptance. From which, probably, some unforeseeable, maybe even weird, whole new societal developments may spring.
It’s like Ripple in that Ripple allows IOUs to be issued from individual servers. So when you receive 10BTC IOU you can say “look, I have 10BTC as recorded over there at the server”. It’s basically the same thing in that way.
Frankly, secure implementation of Bitcoin is already a pain in the ass .. adding more complexity just seems like the wrong move at this point. It’s already trying to be a currency, a networking protocol and a client in the same codebase. Adding turing complete (or not) scripts with arbitrary outcomes, multiple versions of the official client cooperating, multiple clients, and now multiple blockchains is basically the nail in the coffin in terms of widespread implementation.
What Bitcoin’s development team is essentially doing through feature-creep is forcing everyone in the non-tech world to use Bitcoin through commercial proxies to avoid all this complexity (crypto-what? security? sidechain?), which effectively results in the loss of security, relative anonymity and decentralized properties that helped to make it interesting in the first place.
This is a sad state of affairs, and one that apparently shows no signs of alleviating.
I have a hard time swallowing that Bitcoin “isn’t a ledger”. That’s like saying “Bitcoin isn’t the blockchain”, and if you take the blockchain away from Bitcoin, you aren’t really left with much (including, sidechains). Perhaps Bitcoin isn’t a ledger *from the perspective* of individual transactions, but by the same logic, nothing that isn’t transaction data is.
Splendid article. However, I am wondering about one thing. You write “Bitcoin’s block interval is ten minutes so it takes about five minutes on average for a new transaction to find its way into a block, even if it pays a high fee”.
Since “solving a block” on the blockchain is a completely random process, I’d expect the distribution of time-to-next-block to follow a Poisson distribution which means that it will take ten minutes on average for a new block to occur, not five.
Please see e.g. http://mahalanobis.twoday.net/stories/3486587/ (the waiting time paradox) and https://en.wikipedia.org/wiki/Poisson_distribution (Poisson distribution).
“Bitcoin’s block interval is ten minutes so it takes about five minutes on average for a new transaction to find its way into a block”
I don’t think this is true. The expected time before the next block is always 10 minutes. The amount of time elapsed since the previous block has no bearing on the expected time from *now* (finding a block is designed to be a Poisson process).
Ouch! And I thought I’d been so clever with the “average of five minutes” comment. I consider myself suitably corrected 🙂
@klaus – thanks… good spot. Very embarrassing!
@quinn – thanks for the comment. I probably didn’t write clearly enough… I was trying to point out that none of the higher-level concepts we’re familiar with (addresses, bitcoins, the “ledger”, etc) actually exist at the protocol level…. it’s just transactions, transaction outputs, unspent transaction outputs, etc… they combine to create the illusion we’re all familiar with.
@welly – good question… I should have addressed that in the article…. it would be interesting to think through whether you could implement a ripple gateway as a sidechain… (or ripple itself)? e.g. could this be a way to issue BTC IOUs onto the ripple system without counterparty risk with respect to whichever gateway issues the BTC liability?
@Richard- Sidechains appear to be an awkward implementation of Ripple gateways. My view is that counterparties (e.g. banks) are necessary. Counterparty risk remains in both versions, and Ripple is designed to automatically mitigate the degree of risk.
That said – I think some camps would strongly disagree – counterparty risk seems like a reasonable price to pay for systemic scalability and stability, especially when the risk can be mitigated with rules and governance that institutions like SWIFT and the Bank of England provide today.
This approach isn’t fool-proof, but it’s not by mistake that the system looks the way it does today (that’s my history degree talking). Despite best technical efforts, human problems remain within the realm of probability. From http://www.nytimes.com/2009/01/15/books/15masl.html: “…blame cannot be easily assigned: not even the most sophisticated economists of the era could accurately predict disaster, let alone guard against it. The effects of a public herd mentality at the time of the [insert catastrophe here] are depicted, all too recognizably, as unstoppable.”
That was a very good explanation. Thanks for this!
@welly – thanks. I was really just musing out loud about whether one could use the SPV-proof/contest period idea at the heart of sidechains to build a bridge between Bitcoin and Ripple.
Reblogged this on Insufficiently Edited | Ty Danco.
@welly: I get the historical Hayekian case for institutional centralization through tried-and-true rules & governance. Hybrid blockchain/institutional solutions might provide interesting surprises.
However, the technical breakthrough that is the blockchain really is a historical break. We simply could NOT do decentralized coordination on such a scale before Bitcoin, so it’s not like these kind of solutions have the weight of history against them.
Sticking only to the historical, tried-and-true surface-crawling after the invention of heavier-than-air man-made flying in the early 1900s would be missing the fundamentally new possibility uncovered: a dramatic redefinition of long-distance in terms of time, cost & safety.
I need to read more about Ripple. Despite several approaches to it, I’ve never felt I get it. I was very intrigued by your describing sidechains as “an awkward implementation of Ripple gateways.”
Some concerns with the article:
1. Re: “1.Bitcoins are not perfectly fungible… when you move (or spend) them, you’re spending some specific bitcoins”.
It may sound nitpicky, but I think that description leaves something to be desired in terms of presenting the “correct” mental model. First, there is no such thing as “a” bitcoin, as I am sure the author would agree. Speaking of spending or moving bitcoins perpetuates the notion of bitcoins as “things”. It might be preferable to say that you are spending or moving “units of the bitcoin protocol”. There is something similar going on here with dollars. The dollars in your bank account aren’t things either, they are units of demand or claim on a currency. The fact that printed dollars have serial numbers tends to confuse this notion. Treating something as a “thing’ which is not a thing is sometimes referred to as the reification fallacy.
2. I have not had a chance to read the original article on side chains, but I am sure they deal with my next problem quite adequately. However it is not addressed in the above article. The primary problem that must be addressed with the notion of side chains, as I see it, would be the issue of the mining required to authenticate transactions and enter them into the block chain. The article mentions that side chain system more or less leaves the issue of verification within the side chain transactions as something of a black box, somewhat implying that they don’t have to be considered. But for any user, they would need to be both considered and understood. Such a process would presumably require mining verification of some kind, (our mental model must include consideration of the somewhat unusual verification method for bitcoin transactions themselves, – as everyone would agree, the verification process is not just a “checklist” of valid transaction strings. The validation process requires mining in much the same sense as mining new coin. None of this is mentioned or discussed in the article. ) As a result, the verification of side chain transactions outside the block chain introduces whole new layers of risk into the Bitcoin model, and new layers of unknowns.
My chief concern is not with the concept of side chains per se (yet). I have still much to learn about how they are being considered. I am only concerned with the way the concept is being presented here. However, I am sure that much of this was due to space restrictions as much as anything. The concept of side chains is an intriguing one. It is also clearly attempting to address a major problem with the whole Bitcoin scheme- namely the verification latency it introduces for transactions. This is only one of the hurdles facing Bitcoins acceptance into the world of commerce, but it is a considerable one.
I look forward to developments on this issue.
@BetweenFriends thanks for the comments.
1) You’re right. I elaborated on this in the post I linked to (“Welcome to Bitcoin Island”). In that piece, I stress that the things you’re spending are Unspent Transaction Outputs (UTXOs) — and it’s the traceability of these that leads to the “not perfectly fungible” claim.
2) Yes – I had to keep things short/simple in this intro article in order to get across the key ideas. But you’re right: the sidechains need to be secured. But how that happens is a matter for the sidechain. If somebody can produce a false “proof” that the locked Bitcoins should be released on the Bitcoin side then that’s a problem for the sidechain, of course (somebody presumably just had their coins stolen!) but it’s irrelevant (at a macro level) on the Bitcoin side.
thank’s for the explanation
Gendal, how do you suppose private chains will be secured? For example, the CEO may decide to adjust history and there is not much stopping him, since he controls all the mining. One approach is the periodic checkpoints sent to the blockchain. Anything else?
I think sidechains become a huge security hole that might corpse whole Bitcoin eco-system.
Side chain means that bitcoin accept the another “coin base” input from side-chains.
coin base input : that is the only way that Bitcoin has created by mining.
sidechain’s security is not certain you know. if you accept side-chacin input as “coin base “, that brings huge problem to Bitcoin; even more to whole crypt currency eco-system.
i will sell all Bitcions if sidechain is real in Bitcion protocol.
@tradle – fair point. But the situation is no different than a firm today that offers bitcoin safekeeping services, right?
@tetsu – not sure what you mean. My reading of the sidechains paper is that the worst case scenario is that an attacker manages to “reanimate” Bitcoins on the main blockchain that had been sent to the sidechain… but that would be the attacker stealing the coins from the rightful owner on the sidechain. From Bitcoin’s perspective, the coins were always going to be reanimated…. so the risk is entirely borne by the holder(s) on the sidechain. Am I missing something?
@gendal I am discussing private chains with prospects, so my interest is not superficial and theoretical. I see the benefits for the organization in using the private chain as another form of internal database, with better security properties. It can also be used where a service bus product would be today, to facilitate integration, conformance, monitoring, audit. Private chain can also, via a two way peg, be connected to the main chain, achieving a form of public/private network divide that routers created for us in the early stages of the Internet development. Anything else on the benefits side that I missed?
Buy what is lost with private chains is non-repudiation of transactions, as PoW can now be manipulated, by the company itself, hackers and the governments. Checkpointing with the main chains is a good start, but is not enough. I am interested in discussing possible solutions to the problem.
@Tradle. Thanks for elaborating. I’m also thinking about these things – and hear lots of other people talk about them – but I *really* struggle with the concept. It all comes down to the table I drew in this post: https://gendal.me/2014/12/19/a-simple-model-to-make-sense-of-the-proliferation-of-distributed-ledger-smart-contract-and-cryptocurrency-projects/
My take is that the Bitcoin architecture is a solution to the problem of how to maintain consensus about a ledger when the participants are unknown and many of them are adversarial (I know this is loose language… computer scientists working in the consensus space are more precise but I think this captures the essence…. i.e. we’re explicitly in a world where there is no “leader” and no identities for those providing the consensus services).
But if you try to apply the technology *within* a firm, I get confused. When I push people on this point, I *think* their arguments come down to one of the following four:
1) Yes – we know the Bitcoin architecture makes no objective sense here but it’s cool and a good way to get funded. We don’t care.
2) Yes – we know the Bitcoin architecture makes no objective sense here but we’re betting a whole ecosystem will grow up around this architecture and so it will likely become dominant, even in domains where it’s not optimal. There’s no point trying to fight the tide
3) No, Richard… you’re missing the point! We *do* have these problems inside the firewall. Security is so bad, employees are so untrustworthy, etc., that the problem statement for Bitcoin applies just as much *within* the firewall! We *really* need some sort of append-only data structure
4) Block chains are magic. Why are you being so difficult?
I have some sympathy with answer 2) and I have a *lot* of sympathy with answer 3). But they are both problematic.
I’m sensing your line of thinking is motivated by a bit of both 2) and 3), right? Assuming so, I think you’re right to highlight the critical question: without a diverse pool of miners, you don’t get any of the security “guarantees” of Bitcoin so securing an “internal” block chain becomes non-trivial. Any thoughts on how one might do this?
yes, 2) and 3), so to elaborate using your numbering scheme:
1) I would not be surprised if herd mentality ends up being the main unspoken motivation to get rolling with a project, after all we are all excited about bitcoin and sometimes irrationally so.
2) Yea, blockchain could be a suboptimal MQ Series, a slower append only persistent wire that has a lot of ready-made tools for audit and security analysis (ecosystem argument). As blockchain ecosystem grows all kinds of data transformation tools will appear (e.g. we are working on such). Inside blockchain could be tuned to be less PoW intensive and to cut blocks faster. Besides, the variations of PoS or a hybrid PoW + PoS scheme are emerging which could use the fact that inside, as you say, all network participants can have clear identities, unlike on the public bitcoin’s blockchain.
3) the argument ‘let’s harden internal IT as if it worked outside the firewall’ makes a ton of sense to me. We need to construct a lot of hoops for hackers to jump through, as permitter defense is not holding up anymore. And we need to make our systems anti-fragile. The blockchain data structure is a good tool, other P2P tools can be used too. Also, the blockchain has initiated a renaissance of crypto tech, like multisig, payment channels., HD wallets, hot-cold storage, and other innovations in key management.
Let’s milk this cow a bit:
– security credentials on-chain, any new clearances on-chain, supported with cryptographic signatures
– identities for equipment, places, people, network nodes, etc. on-chain
– resource allocations on-chain, so that hackers would not be able to use the same resource too many times without detection
– pervasive compartmentalization: store data on-chain encrypted with per-transaction keys. Store only what is necessary for the immediate access in a decrypted form (on encrypted drives) in a database (sort of like cold and hot wallets). When homomorphic encryption matures even DB records could be encrypted.
– hardened authentication techniques, e.g. bitauth, air-gapped via QR codes, etc.
– deterministic software production, some methods are used by bitcoin core devs, others can be found in gitchain project
– make some transactions anonymous so that hacker could not sniff their way around (e.g. Tor, ZeroCash).
– zero knowledge proofs for credentials and computation correctness
– use other P2P tech that proved to operate in presence of massive attacks, like DHT and bittorrent
– harden those P2P technologies with the use of the blockchain (some ideas in S/Kademlia)
– security scripts for the above features run on-chain, so would be harder to bypass
– verify requests based on a chain of prior activities instead of a naked access token (drawing inspiration from bitcoin’s cumulative DMMS, as described in a sidechains whitepaper). Each network participant will incorporate either a full node or an SPV client instead of trusting the access token.
I would submit a 5) to your list, economic software design, inspired by the blockchain:
New organizational structures will emerge that will make inside/outside much less clear. These clear boundaries started to erode with the extranets in the 90s, then with the multi-tenant cloud platforms, and lately with the smartphones and the IoT. As we move forward we will see value chains where participants have multiple roles and affiliations. We will be designing token based systems that produce gains for any participants, internal or external.
@tradles – really thought-provoking… thanks. One clarification… when you say “security credentials on-chain” or “identities… on-chain”, what do you mean? I hear a lot about “block chain for identity”, etc,. but I’m not 100% sure I understand what it means!
@gendal good question. My team is working on the following preliminary identity design right now:
– we provide no uniqueness of names, unlike the domain registrars, social networks, namecoin, onename.io, etc. There is no uniqueness of names in real life either. Instead the identity is just a hash of a [json] object that contains a public key. Identity object can not be modified directly, but a new version of it can be created, pointing to a previous version. The owner of the identity object can optionally connect it with the real life credentials, e.g. the social account, internet domain, email, etc. by proving the proof of ownership of that account the way onetime.io does it, the way Google Analytics does it, etc. This allows a spectrum of identities from fully anonymous to fully disclosed and verified. This also allows a person to have multiple identities, for work, for social, for gaming, for interest-specific forums. To simulate OAUTH2, a new site-specific identity can be created and signed with person’s other identity.
– a collection of identity objects on the blockchain are equivalent to a key management server.
@tradles… OK – so I can create as many identities as I like (each with its own public key) and can associate them with identities on other services….. fine. I’m probably being really dumb – but where does the block-chain fit in to this? What are you storing? The hash of the JSON object? (To what end)? The JSON object itself? Something else?
@gendal good question, short answer is yes, an encrypted hash of an encrypted json object is put on a blockchain while the object itself is put onto another p2p network. Here is the rationale:
Mastercoin and Counterparty are embedded consensus protocols (or meta-protocols) that use the blockchain to store their transactional data. Bitcoin devs, except Peter Todd who was hired by both teams to help them find a proper solution, are very unhappy, to say mildly, about storing the data on the blockchain. Heated discussions on this topic go on for hundreds of pages on bitcointalk and Mastercoin github issue. Mining pools like Eligius started censoring Mastercoin transactions (not sure if they are continuing with this practice right now, but the operators of this pool are adamant that data do not belong to the blockchain).
I think this conservative position without offering an alternative solution, will result in bitcoin ceding the market to Ethereum, much like Apple created an entrance to a much inferior at the time Android by signing an iPhone exclusivity deal with some carriers.
I talked yesterday with Adam Krellenstein of the Counterparty and censorship was threatened, but he said did not yet happen. Yet, as I gathered, it is a remaining concern that can undermine their whole business.
Thus Tradle set out to build a meta-protocol that saves the data in the overlay network, and only puts minimal referencing data on the blockchain. There is a general grumpy consensus among bitcoin core devs and mining pool operators on allowing one small data chunk, a hash, per transaction. Many devs say it is not possible to secure this second overlay network. I agree, unless we use the blockchain to help with the task. We have a partial solution working, and are preparing a new design to improve it (partial, as it can not yet handle all known attacks). We are actively sharing the designs at various meetups (and on the github) and are inviting devs to find attack vectors and propose solutions. Tradle’s protocol not only relieves the pressure on bitcoin’s blockchain but is also able to handle larger transaction sizes than Counterparty and Mastercoin, so it can be used for complex identity, supply chain management and many other applications. It is also capable of handling attachment files, needed in the healthcare and financial industries.
Did I answer your question?
@tradles – thanks for taking the time to explain this. OK – so I get the debate around blockchain bloat and the (grudging) inclusion of OP_RETURN, etc., but what I’m missing is that I can only really see one scenario where embedding any identity data into the blockchain makes sense…. and that’s when I want to *associate* an identity with a transaction I’m performing.
So sure… I could take the identity I want to assert, hash it, stick this in the OP_RETURN, sign the transaction and I’m done.
Except… that doesn’t stop me simply taking *somebody else’s* identity hash.
So there needs to be a way to prove that the identity being asserted really was issued to the owner of the private key associated with the bitcoin transaction that asserts it.
I guess this could work in a world with address reuse. But, in the general case, would it mean you’d need thousands of certificates (one per address you plan to use?). Or am I missing something? Or perhaps there’s some clever maths (building on the math in HD wallets perhaps?)
@gendal, good question. Think of the identity hash as a bitcoin address, it is indeed public. So to assert anything with this identity you need to sign the object you are creating or changing with the identity’s private key. Specifically it is a private key that corresponds to a public key that you published in your identity’s object (json). The signature is not placed on the bitcoin transaction, as OP_RETURN has only 40 bytes. The signature is added to a [json] object that is modified with this identity. If you see any fault with this, please let me know.
There is a whole other issue of identity theft that needs to be addressed. Just a short note here as this is a big subject: If the private key to identity object is stolen, the true owner of the identity needs to have a way to change the key. One approach to that would be to use the private key of the bitcoin transaction that created the first version of the identity object. Another way could be to prove the ownership of other public keys on the identity object, like the one used for encryption (PGP key management suggests a separate key for each purpose, signing, encryption, etc.). Other non-automatic ways could include a trusted third-party, social proof, etc.
@tradles – got it… thanks
thank you this is most informative 🙂
@gendal I led an Identity workshop a day ago at cryptoeconomicon.com and published a design that includes ideas from the workshop participants: https://github.com/tradle/about/wiki/Identity
@tradles – thanks for sharing this… I’ll take a look.
thank you for the clear explanation of this. so in essence, by locking bitcoins to a particular address we’ve created an asset (collateral). then on the other sidechain (marketplace) we get issued shares against the asset, which we can sell. anyone holding a share can then redeem it against the asset. I think that’s an analogy that finance types would get
Richard G. Brown?
You sir, are indeed a LEARNED SOUL!
This is by far the most enlightening post I have ever read! …..of anything to be honest. And I’ve read a lot of posts.
how to get a bitcoin?
New to all this and your blog is so helpful!
Bitcoin will hit $100000 this year, check out the FAQ section of https://bitcoinvest.cc to see why. Since Asia holds the most of the crypto, the price drop in January was because of the Chinese New Year and panic selling.
Have you heard about btctradefarm.com? It is a website where I invested my bitcoins and got a massive profit of about 65% of my investments in less than 7 days. Try it out now and thank me later.
Thats For Sharing Your Information love
kayla erin nude
brittany furlan nude
alahna ly nude
gal gadot sex
xxx vidou school
donlowad bokep barat
sexold girl com
poran hb videos
sonilion sexy video
diana penty xxx.com
xxx daishee girl
daunlowd sexx melayu
xxxxxxxx hd fulll
xxxsixy movie full
teen legal porn
beautiful boobs fuck
kristen scott xxx
hot nagaland sex
xxx behawin hd
sexey hd porn
rape japanese sex
uttara kannada xxx
web.xxx hd video
abg meki mulus
Earning interests for the bitcoins you hold has never been more profitable. You get. to earn as high as 10%. interests for the bitcoins you hold on the AxisOption wallet platform
I dont no what averithing you cant play action…i no..i want my payment money you no…my data not free….im not many more time..dont push my time to understand ..2 years not settle not working..?how about my life story?why your All US canot understand about my realiti humans life surfer??your All take my time my life story…why canot push direct too my acount bank..detail i givefor your team…now ..how about my money???i need …cant your understand????? Very2 Hard….you no…about my setuetion…how long more Quick??i give to your my chair….how your All cant anderstand?????i no..not Good i push the story to Twitter and more story about my problem and your and you team Us@united push my head about my humans story..!!!!??.money not push for me the cases about long time…your no…T.Q to.. firstname.lastname@example.org..this problem i dont no..how I cant take my acount and paswd..dont push my head for understand about more plans at your All team…very2 Good job….t.q