Bitcoin side chains bios

Maybe it has a faster block confirmation interval and a richer scripting language. You have Bitcoins already. So developers get the opportunity to experiment with different types of cryptocurrency rules without needing to create their own currency. We now have a way to move coins from Bitcoin onto another platform a sidechain and move them back again. 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 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.

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. I thought it was a genius idea at the time and it will allow experimenting. 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: Reblogged this on Global-hardware. Reblogged this on Maverisk and commented: 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.

Frankly, secure implementation of Bitcoin is already a pain in the ass.. 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. However, I am wondering about one thing. The expected time before the next block is always 10 minutes.

Richard- Sidechains appear to be an awkward implementation of Ripple gateways. My view is that counterparties e. 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.

Despite best technical efforts, human problems remain within the realm of probability. The effects of a public herd mentality at the time of the [insert catastrophe here] are depicted, all too recognizably, as unstoppable. Reblogged this on Insufficiently Edited Ty Danco. However, the technical breakthrough that is the blockchain really is a historical break. Sticking only to the historical, tried-and-true surface-crawling after the invention of heavier-than-air man-made flying in the early s would be missing the fundamentally new possibility uncovered: I need to read more about Ripple.

Some concerns with the article: There is something similar going on here with dollars. The fact that printed dollars have serial numbers tends to confuse this notion.

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. But for any user, they would need to be both considered and understood.

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. But how that happens is a matter for the sidechain.

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. I think sidechains become a huge security hole that might corpse whole Bitcoin eco-system. But the situation is no different than a firm today that offers bitcoin safekeeping services, right?

Am I missing something? 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. 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. It all comes down to the table I drew in this post: 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….

Security is so bad, employees are so untrustworthy, etc. But they are both problematic. Any thoughts on how one might do this? As blockchain ecosystem grows all kinds of data transformation tools will appear e. Inside blockchain could be tuned to be less PoW intensive and to cut blocks faster. 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. 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. 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: 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.

My team is working on the following preliminary identity design right now: 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. 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.

What are you storing? The hash of the JSON object? The JSON object itself? 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.

A whole different group has released an early draft of a radical new proposal called the Lightning Network , which would, in principle, move the vast majority of Bitcoin transactions off the blockchain, without sacrificing any verifiability or security. I know, I know. There is no counterparty risk: These in-channel payments would be instant, unlike current Bitcoin payments, which require an hour to be fully verified on the blockchain.

However, the Lightning Network would, again, require a change to the existing Bitcoin protocol. Sidechains Elements Alpha The distributed Bitcoin mining network performs quadrillions of calculations every second that maintain the integrity of its blockchain. Confidential Transactions — At present, all Bitcoin transactions are completely public, albeit pseudonymous.

Confidential Transactions , as the name implies, conceal the amount being transferred to all except the sender, the recipient, and others they designate. Mind you, Zerocash would require an esoteric invocation ritual to initiate its network. Segregated Witnesses — The current Bitcoin transaction signature algorithm is complicated and flawed, leading to a problem known as transaction malleability.

Segregated witnesses would eliminate that, improving the efficiency of much Bitcoin software considerably … and making much more significant innovations such as the Lightning Network see below possible. New opcodes — Every Bitcoin transaction is actually a program written in a scripting language.