Topic: Bitcoin 2.0 路在何方? 侧链 VS 树链? Bitcoin2.0 技术翻译计划！ (Read 4843 times)

有没稿费我也加入！

是的 目前是我一个人在翻译。

意思是招募志愿翻译人员吗？

这是个好想法，为国人推广其技术理论打好基础。

直接翻译的吗 内容太少了啊

我不懂技术，感觉很难看懂。

coindesk 最新文章：

http://www.coindesk.com/viacoin-team-implements-smart-contract-protocol-built-altcoin-block-chain/


Viacoin Team Implements Smart Contract Protocol Built on Altcoin Block Chain


source:  http://www.coindesk.com/viacoin-team-implements-smart-contract-protocol-built-altcoin-block-chain/

The first decentralized smart contracts protocol built on top of an altcoin block chain is now live.

ClearingHouse, a descendent of Counterparty, was created by the team behind viacoin and has been in active development since the alt first launched last month. The team has attracted top talent in the bitcoin space, most notably Bitcoin Core developer and Coinkite advisor Peter Todd who has been hired to work on his Tree Chains concept.

On 11th August, the viacoin development team announced new details regarding ClearingHouse’s internal currency, XCH, and information on how users can exchange viacoins for the new currency. Notably, a new Web-based client interface that implements the ClearingHouse protocol, Clearwallet, was also made public.

CoinDesk spoke with viacoin developer BTCDrak, who said that because the ClearingHouse protocol is built on top of the viacoin block chain, certain structural and political complications that have previously plagued decentralized contract platforms are largely sidestepped.

He explained:

“Because ClearingHouse and viacoin are part of the same project, the viacoin block chain will always accommodate ClearingHouse’s needs.”


He added that, in the past, the teams behind projects like Counterparty have faced pressure from bitcoin’s development community that ultimately impeded progress. Using viacoin as a basis, ClearingHouse-based projects can avoid these obstacles entirely.

First look at smart contract protocol

Clearwallet is the first implementation of ClearingHouse, giving users a decentralized environment for conducting various contracts. No keys are stored on the server and all transactions happen purely between the two parties.


As shown in the image above, the simple user interface currently offers an asset marketplace, a betting terminal and section for decentralized games. Clearwallet also offers a live chat box, with early adopters already investigating the implementation.

In its original announcement, the viacoin-ClearingHouse development team announced that the exchange rate between VIA and XCH would be 100 XCH per VIA. A 45-day sale period has already begun, with a diminishing exchange rate that will end at 85 XCH for each viacoin.



According to BTCDrak, exchange volume is up and nearly 230,000 viacoins have been converted to XCH, or roughly 143 BTC at press time. Users have already executed several trades in Clearwallet’s VIA/XCH marketplace.



Looking ahead, reputation and identity support will be implemented that add further layers of complexity to how the protocol can be leveraged. As the team noted in the blog post, this includes the creation of decentralized organizations, facilitation of online polls, the sale of goods and services and even the development of new cryptocurrencies.

Decentralized platforms grow in number

The ClearingHouse protocol represents the latest entry in a group of decentralized contract platforms, which also includes Counterparty and the off-block chain decentralized contract network BitHalo. Ripple Labs is also working on its own smart contracts platform, Codius.

Beyond contracts, decentralized platforms are attracting attention for their intrinsic security and appeal to a broad segment of the bitcoin community. It’s this level of grassroots support that has made such projects largely possible.

Among the projects taking shape in this space is BitcoinJ developer Mike Hearn’s decentralized crowdfunding platform Lighthouse. While no date has been given, the platform is expected to launch sometime in the next month.

Commerce has also proved to be a major area for decentralized development. Peer-to-peer marketplace OpenBazaar, created by Brian Hoffman and based on the Toronto Bitcoin Expo Hackathon winner DarkMarket, seeks to bring the principals behind decentralized actions to consumer-to-merchant interaction.

必须膜拜土豆大神，翻译的好，求连载

我真的感觉BTC的技术发展的非常很好

已经完成第二篇翻译，准备有时间发出。

准备自己慢慢翻译了。

侧链技术已经被bitcoin core的开发者证明不会改进现有情况，并且会加剧挖矿的集中化。比较有前途的应该是树链了。

认真看一下文章，你会发现非常容易理解。

这项技术真的好，可以算是侧链的另一种形式，如果成功了真要取代比特币了！

这么专业，图片也需要翻译，还是得由懂技术的人来做。

侧链技术目前还只是理论研究阶段，其对BTC网络的影响风险如何还有待于进一步的评估。

先堆技术名词，到谁也看不懂了的时候，就可以开圈了

https://twitter.com/hashtag/sidechains?src=hash

树链可以解决BTC的致命问题，并且促进基于区块链应用的发展。

越来越深奥了 但是与实际应用有多大的益处呢 守住btc 拭目以待吧

楼主加油！ 我大概知道你是哪位了。    支持你

这个技术原帖发完后 有没有后续的文章什么的。 不会真像我说的只是提理论而已吧.  中文版里真的缺少你这样的技术人才了.我百度过比特币的块链接，基本的我都读不太懂，这篇深奥的技术贴你好理解吗？

本周准备翻译这篇文章！


anybody want to know more details of TreeChains?

here is a article by peter todd:

http://www.mail-archive.com/[email protected]/msg04388.html


Tree-chains preliminary summary

Peter Todd Tue, 25 Mar 2014 05:39:15 -0700

On Sat, Mar 22, 2014 at 12:43:34PM -0700, Mark Friedenbach wrote:
> Btw, any chance we could get a summary description of tree-chains
> posted to bitcoin-development?
sure

1
Introduction
============

Bitcoin doesn't scale. There's a lot of issues at hand here, but the
most fundemental of them is that to create a block you need to update
the state of the UTXO set, and the way Bitcoin is designed means that
updating that state requires bandwidth equal to all the transaction
volume to keep up with the changes to what set. Long story short, we get
O(n^2) scaling, which is just plain infeasible.

So let's split up the transaction volume so every individual miner only
needs to keep up with some portion. In a rough sense that's what
alt-coins do - all the tipping microtransactions on Doge never have to
hit the Bitcoin blockchain for instance, reducing pressure on the
latter. But moving value between chains is inconvenient; right now
moving value requires trusted third parties. Two-way atomic chain
transfers does help here, but as recent discussions on the topic showed
there's all sorts of edge cases with reorganizations that are tricky to
handle; at worst they could lead to inflation.

So what's the underlying issue there? The chains are too independent.
Even with merge-mining there's no real link between one chain and
another with regard to the order of transactions. Secondly merge-mining
suffers from 51% attacks if the chain being merge-mined doesn't have a
majority of total hashing power... which kinda defeats the point if
we're worried about miner scalability.

2 Blocks and the TXO set as a binary radix tree
=============================================

So how can we do better? Start with the "big picture" idea and take the
linear blockchain and turn it into a tree:


Obviously if we could somehow split up the UTXO set such that individual
miners/full nodes only had to deal with subsets of this tree we could
significantly reduce the bandwidth that any one miner would need to
process. Every transaction output would get a unique identifier, say
txoutid=H(txout) and we put those outputs in blocks appropriately.

We can't just wave a magic wand and say that every block has the above
structure and all miners co-ordinate to generate all blocks in one go.
Instead we'll do something akin to merge mining. Start with a linear
blockchain with ten blocks. Arrows indicate hashing:

    a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ⇽ a9

The following data structure could be the block header in this scheme.
We'll simplify things a bit and make up our own; obviously with some
more effort the standard Satoshi structures can be used too:

    struct BlockHeader:
        uint256 prevBlockHash
        uint256 blockContentsHash
        uint256 target
        uint256 nonce
        uint time

For now we'll say this is a pure-proof-of-publication chain, so our
block contents are very simple:

    struct BlockContents:
        uint256 merkleRoot

As usual the PoW is valid if H(blockHeader) < blockHeader.target. Every
block creates new txouts, and the union of all such txouts is the txout
set. As shown previously(1) this basic proof-of-publication
functionality is sufficient to build a crypto-currency even without
actually validating the contents of the so-called transaction outputs.

The scalability of this sucks, so let's add two more chains below the
root to start forming a tree. For fairness we'll only allow miners to
either mine a, a+b, or a+c; attempting to mine a block with both the b
and c chains simultaneously is not allowed.

    struct BlockContents:
        uint256 childBlockHash # may be null
        bool childSide # left or right
        uint256 merkleRoot

Furthermore we shard the TXO space by defining txoid = H(txout) and
allowing any txout in chain a, and only txouts with LSB=0 in b, LSB=1 in
c; the beginning of a binary radix tree. With some variance thrown in we
get the following:




We now have three different versions of the TXO set: ∑a, ∑a + ∑b, and
∑a+∑c. Each of these versions is consistent in that for a given txoutid
prefix we can achieve consensus over the contents of the TXO set. Of
course, this definition is recursive:




Unicode unfortunately lacks 3D box drawing at present, so I've only
shown left-sided child chains.


3 Herding the child-chains
========================



If all we were doing was publishing data, this would suffice. But what
if we want to syncronize our actions? For instance, we may want a new
txout to only be published in one chain if the corresponding txout in
another is marked spent. What we want is a reasonable rule for
child-chains to be invalidated when their parents are invalidated so as
to co-ordinate actions across distant child chains by relying on the
existance of their parents.

We start by removing the per-chain difficulties, leaving only a single
master proof-of-work target. Solutions less than target itself are
considered valid in the root chain, less than the target << 1 in the
root's children, << 2 in the children's children etc. In children that
means the header no longer contains a time, nonce, or target; the values
in the root block header are used instead:

    struct ChildBlockHeader:
        uint256 prevChildBlockHash
        uint256 blockContentsHash

For a given chain we always choose the one with the most total work. But
to get our ordering primitive we'll add a second, somewhat brutal, rule:
Parent always wins.

We achieve this moving the child block header into the parent block
itself:

    struct BlockContents:
       ChildBlockHeader childHeader # may be null (zeroed out)
       bool childSide # left or right
       bytes txout
Let's look at how this works. We start with a parent and a child chain:




to



This behavior is easier to understand if you say instead that the node
learned about block b2', which had more total work than b2 as the sum
total of work done in the parent chain in blocks specifying the that
particular child chain is considered before comparing the total work
done in only the child chain.

It's important to remember that the parent blockchain has and validates
both childrens' block headers; it is not possible to mine a block with
an invalid secret of child headers. For instance with the following:



I can't mine block a5 that says following b2 is b2' in an attempt to
kill off b2 through b7.

4 Token transfer with tree-chains
===============================

How can we make use of this? Lets start with a simple discrete token
transfer system. Transactions are simply:

    struct Transaction:
        uint256 prevTxHash
        script prevPubKey
        script scriptSig
        uint256 scriptPubKeyHash

We'll say transactions go in the tree-chain according to their
prevTxHash, with the depth in the tree equal to the depth of the
previous output. This means that you can prove an output was created by
the existance of that transaction in the block with prefix matching
H(tx.prevTxHash), and you can prove the transaction output is unspent by
the non-existance of a transaction in the block with prefix matching
H(tx).

With our above re-organization rule everything is consistent too: if
block b_i contains tx1, then the corresponding block c_j can contain a
valid tx2 spending tx1 provided that c_j depends on a_p and there is a
path from a_p to b_(i+k). Here's an example, starting with tx1 in c2:



Now that a3 exists, block c2 can only be killed if a3 is, which would
also kill b3 and thus destroy tx2.


5 Proving transaction output validity in a token transfer system
==============================================================
How cheap is it to prove the entire history of a token is valid from
genesis?  Perhaps surprisingly, without any cryptographic moon-math the
cost is only linear!

Remember that a transaction in a given chain has committed to the chain
that it can be spent in. If Alice is to prove to Bob that the output she
gave him is valid, she simply needs to prove that for every transaction
in the histroy of the token the token was created, remained unspent,
then finally was spent. Proving a token remained unspent between blocks
b_n and b_m is trivially possible in linear size. Once the token is
spent nothing about blocks beyond b_m is required. Even if miners do not
validate transactions at all the proof size remains linear provided
blocks themselves have a maximum size - at worst the proof contains some
invalid transactions that can be shown to be false spends.

While certainly inconvenient, it is interesting how such a simple system
appears to in theory scale to unlimited numbers of transactions and with
an appropriate exchange rate move unlimited amounts of value. A possible
model would be for the the tokens themselves to have power of two
values, and be split and combined as required.

6 The lost data problem
=====================

There is however a catch: What happens when blocks get lost? Parent
blocks only contain their childrens' headers, not the block contents.
At some point the difficulty of producing a block will drop sufficiently
for malicious or accidental data loss to be possible. With the "parent
chain wins" rule it must be possible to recover from that event for
mining on the child to continue.

Concretely, suppose you have tx1 in block c2, which can be spent on
chain b. The contents of chain a is known to you, but the full contents
of chain b are unavailable:



The proof of now shows that while a3 and a4 has b-side blocks, by the
time you reach b6 those two lost blocks were in the minority. Of course
a real system needs to be careful that mining blocks and then discarding
them isn't a profitably way to create coins out of thin air - ratios
well in excess of 1:1 are likely to be required.

7 Challenge-response resolution
=============================

Another idea is to say if the parent blockchain's contents are known we
can insert a challenge into it specifying that a particular child block
be published verbatim in the parent. Once the challenge is published
further parent blocks may not reference that children on that side until
either the desired block is re-republished or some timeout is reached.
If the timeout is reached, mining backtracks to some previously known
child specified in the challenge. In the typical case the block is known
to a majority of miners, and is published, essentially allowing new
miners to force the existing ones to "cough up" blocks they aren't
publishing and allow the new ones to continue mining. (obviously some
care needs to be taken with regard to incentives here)

While an attractive idea, this is our first foray into moon math.
Suppose such a challenge was issued in block a2, asking for the contents
of b1 to be published. Meanwhile tx1 is created in block c3, and can
only be spent on a b-side chain:



A proof of tx2 as valid payment would entirely miss fact that the
challenge was published and thus not know that b1' was invalid. While
I'm sure the reader can come up with all kinds of complex and fragile
way of proving fraud to cause chain a to be somehow re-organized, what
we really want is some sub-linear proof of honest computation.  Without
getting into details, this is probably possible via some flavor of
sub-linear moon-math proof-of-execution. But this paper is too long
already to start getting snarky.


8 Beyond token transfer systems
=============================

We can extend our simple one txin, one txout token transfer transactions
with merkle (sum) trees. Here's a rough sketch of the concept:



Where previously a transaction committed to a specific transaction
output, we can make our transactions commit to a merkle-sum-tree of
transaction outputs. To then redeem a transaction output you prove that
enough prior outputs were spend to add up to the new output's value. The
entire process can happen incrementally without any specific
co-operation between miners on different parts of the chain, and inputs
and outputs can come from any depth in the tree provided that care is
taken to ensure that reorganization is not profitable.

Like the token transfer system proving a given output is valid has cost
linear with history. However we can improve on that using
non-interactive proof techniques. For instance in the linear token
transfer example the history only needs to be proven to a point where
the transaction fees are higher than the value of the output. (easiest
where the work required to spend a txout of a given value is well
defined) A similar approach can be easily taken with the
directed-acyclic-graph of mutliple-input-output transactions. Secondly
non-interactive proof techniques can also be used, again out of the
scope of this already long preliminary paper.

1) "Disentangling Crypto-Coin Mining: Timestamping,
   Proof-of-Publication, and Validation",
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html



 

谢谢鼓励

这才是真正的做事情,而不是靠某个新点子就开始IPO圈钱.

这个是的，国内真正关心技术发展的人太少了。

翻译完成后发在这里吧，不要发在国内那些无聊的媒体上面，这里首发，再转发到那里即可。这里才是讨论技术的地方。

个人感觉是侧脸上出新技术

翻译完成后会发表在 巴比特或者比特儿或者比特时代上。

没有翻译，估计国内不少特别关注技术细节。

专业的知识，希望有人抄下慢慢翻译，希望有这个耐心。
另外翻译完后公布下地址

希望你能翻译出来. 度娘和谷哥翻译出来的看的不是很懂.
本来对什么链接块就不是很懂，在看见这英文更头疼了.这都是6月13日的文章了，其他网站没有人翻译吗？

鉴于没有赞助和支持，准备自己翻译。

先从这一篇开始：

http://blog.greenaddress.it/2014/06/13/sidechains-treechains-the-tldr/

0.1 BTC/1000字/词  也不算贵啦~

https://bitcointalksearch.org/topic/english-to-chinese-translation-service-newproof-reading-and-correction-service-651154
人家明码标价0.1 btc / 1000字    你这文章翻译下来可不便宜啊 .
真的是这样？？？
真的是不太懂英文.真的是帮不上忙，

看来没有太多人关注技术细节的问题，准备自己翻译一下。

可以在本帖下面留言哈

确实很专业，一堆中文给我看有的地方我还是不能够理解

粗略查看了下文章，太过专业了，我本身又不是搞技术的，所以没法胜任翻译这样的文章。

翻译了 把译文发哪里！

哈哈 谢谢 酒儿。

加油，~~~

有的，我会找一点赞助。还有资讯媒体的稿费。

你看每一篇文章多少btc合适？

翻译有报酬吗或者有人会捐赠吗？if it does,I am in.

很好，真是新的思想层出不穷。
说明群众的智慧是无穷的。

比特币一定会更好!

谢谢支持。

難得的一個靠譜而又意義的項目，如果有能力真的應該支持一下~

树链解决了bitcoin所面临的的很多问题，相对sidechains也有很大改进。

通过树链技术可以解决51攻击问题，不同链之间的通信问题，并且想当于提供了无穷多的开发接口给各种altcoins和applications.

如果感兴趣可以加入到翻译计划里面。

比特币2.0树链接技术看着是不错的.现在只是提出这一项技术.真的实施恐怕没有说一说这么简单

目前还没有中文译文，要等翻译好了。

这太专业了，我仰望。。。拜读那位老师的译文

3 树链技术和侧链技术总结性文章


Sidechains, Treechains, the TL;DR


（i am not the author of this article, here is the source: http://blog.greenaddress.it/2014/06/13/sidechains-treechains-the-tldr/）





This document is aimed at technical readers and is simply a brief explanation of sidechains and treechains as far as I understand them, based on public information.  Both are obviously still in very preliminary development, but this document is just to introduce the broad concepts, and their consequences. Some people have been asking for something like this, might as well see if this helps.

With GHash is getting nearly 50% of hashing power of the network, this discussion is more timely than ever.

I’ll start with sidechains, since treechains are essentially a specific form of sidechains.

Sidechains:

In the most general, sidechains will use “SPV Proofs” to send satoshis from the regular Bitcoin chain to the sidechain, and allows the sidechain to eventually send the satoshis back to the main chain once the owner of said coin is finished utilizing the sidechain. While in the sidechain, the main chain knows nothing of what’s happening to the coin, the sidechain is the one tracking who owns what at what time.

The side chain can basically have any rules it likes for what a valid block is, block times, etc. Typically the idea is that these chains will be merge mined with the Bitcoin network, to ensure that a reasonable amount of hashing power is protecting the sidechain network from DoS, and outright theft of coins by miners which is possible due to the limitations of the SPV proofs. It’s important to note however, that it has been suggested that the outright theft of coins by miners may be protected against using zk-SNARKs.(https://eprint.iacr.org/2013/507.pdf)

The pros of sidechains appear to be:


1 You don’t need permission to start a new chain with new validation rules, block times, whatever. You could fairly trivially add Zerocash, Ethereum rules, and still have them pegged in satoshis. Also would be a great way to test out new opcodes/communication protocols for the base protocol and codebase.

2 The sidechains would be backed by the hashing power of the Bitcoin network, so given certain conditions(detailed below) it can’t be trivially attacked.


The cons are as far as we know(not counting new zk-SNARK moon math that hasn’t been given to the public):


1 Merge mining also means two things: There is no inherent block reward. Security will most likely be only be from transaction fees. more importantly, you need to convince the large pools to manually activate the merged mining of these chains, otherwise a 51% attack is essentially free. You also have to trust the pools aren’t faking downtime, while secretly mining the chain.

2 Long-term it can contribute to centralization of mining, just in the same way that increasing the block size would. It would be optional to mine these sidechains yes, but if it becomes a sizeable fraction of transaction fees, the economics work in the favor of more centralization.

3 Sending satoshis back and forth  between chains will take days, to ensure that satoshis aren’t being stolen by miners, again due to the aforementioned SPV proofs, which is something that simply can’t happen in vanilla Bitcoin. Most going back and forth will be done using atomic swaps in between users to reduce this waiting period.


Treechains:

I think of treechains as tighter-coupled sidechains. The difference in chain structure is larger than between sidechains and the vanilla Bitcoin protocol, so I’m tackling them in broad brush-strokes.

1 Miners are not required to validate blocks, outside of the PoW difficulty being low enough, and being a proper hash of the block+previous block. If the block header looks legit, miners can start to build on top of this.


2 Starting from the main Bitcoin chain, each chain will have a left and right descendant chain. This builds a binary tree of chains, hence “treechains”. Each chain level has 2^(numlevels-1) chains, doubling the number of the previous level. Each difficulty threshold is also halved. Based on the hash of the transactions, they can only be mined in in specific paths of the tree structure(starting from the first bit of the hash from the root of the tree, ‘0’ means left subtree, ‘1’ means right). Each time satoshis are spent, it will get sent to another chain in the same level based on the previous transaction’s hash(ignoring up/down movement for clarity).
In addition, each path is merge mined, allowing miners to mine one and only one path of the tree using the same hashing work. So for example, 3 layers down, there should on average only be an 8th of the total transactions on any specific chain, as well as only an 8th of the total mining power, resulting in roughly the same block time as higher chains!

3 The chains are linked together more strongly than sidechains to enforce a total ordering of transactions. Every time a miner gets a PoW high enough for a certain level, it “links” that block with all the blocks being mined below together. This enforces the total ordering we want. Transactions on let’s say level 16 will have a higher chance of getting orphaned, but eventually once they “percolate” up to the main chain, they are just as secure as the main chain. The linking also determines when you can spend your satoshis, meaning lower chains will take longer to spend the same outputs again compared to higher chains. To spend your satoshis from chain A to chain B at level C, the previously mined transaction’s block in A must be linked to B’s nearest common ancestor chain, with the only valid paths being forward/up the chains, not backwards.

4 Last important thing to note about the tree structure: Parent chain always wins. If the child chain is in conflict with the parent chain(the links are inconsistent, making total ordering inconsistent), those blocks child blocks are orphaned. Therefore, re-organizations at higher chains can cause reorganizations at lower chains, but not vice versa.


And their consequences/caveats:

1 Since miners aren’t required to validate anything outside of basic PoW, this breaks the need to beg miners for protocol changes. Granted, there will be a base BTC layer that allows things like “miner gets block reward” and “pay .0001 BTC to miner for transaction fee” to incentivize the mining, but outside of this, it allows fairly arbitrary protocols. One could even imagine paying a miner colored coins to get it included in a block, if the miner wanted equity! One thing this can’t do versus sidechains is initialize chains with arbitrary block times. However you might be able to get away with much faster block times than vanilla Bitcoin due to #2. Overall, this will let innovation at the edges happen, without having to agree on everything with Core Devs, or mining pools, or industry, etc. SPV clients won’t be possible, at least in their current form, due to SPV’s assumption that mined blocks are validated by the miners.

2 Proving who owns what when will be more complicated for the client, as they can’t assume miners are validating a certain protocol. Clients will have to hold data outside of their private keys, proving to the payee that these coins exist and control them. This will be more complicated than our SPV clients we have today, but will make running a node with “full node” security tractable, as you don’t care what the contents of most blocks are, just the blocks that prove to you that you own the satoshis you own(a small sample of blocks compared to the whole tree of chains). These proofs will be “compact”, although it remains to be seen how much more compact than linear in block sizes we can get(insert zk-SNARK moon math for sublinear performance?).

3 Combining with consequences from #1, miners will be able to mine as little or as much as they like, with only paying attention to block headers, and block payloads that again, prove to him that they’re actually being paid to mine by fees. A miner could simply keep track of all headers in the treechains, which is trivial, and solo mine 16 levels down, where their variance is 2^(-16) less than the vanilla blockchain mining, due to the sparsity of miners that far down in a branch. If a user is willing to wait a while for the ability to re-spend their outputs, they can approach a solo miner, pay a smaller fee than usual, and wait for the block to get linked higher in the tree.This opens up a true marketplace for fees, as well as allows small pools/solo miners to make a real difference when it comes to block creation. Lastly, this system appears to scale to an infinite amount of transactions, without hurting decentralization.

4 The linking scheme ultimately means that orphan rates will be higher at lower levels, and re-spending outputs will take longer, and will be based on where the next transaction will end up in the tree structure. However, for your coffee money, it enables you to get in a block, and for the merchant to not worry too much that you’ll try and 51% attack 5 levels down as it won’t make economic sense.

In summary(TL;DR’s TL;DR):


A Sidechain, at its most general, is a loosely coupled chain that, in general, uses merged mining to protect the network. These chains are “backed” by BTC from the Bitcoin network, rather than minting their own coin and diluting scarcity. There are some questions about security guarantees versus the Bitcoin network.


A Treechain is a structure of more-tightly coupled sidechains. This structure, in theory, allows miners to mine at arbitrary variance without pooling, scaling of the system far beyond 7tps without asking permission, and other innovation at the edges, all with the same protections of the main Bitcoin network. With the huge caveat that the idea is still half-baked, has no known SPV client support, and is much more complicated than a vanilla blockchain.


Both ideas are interesting ways of tackling some of the important problems that all cryptocurrencies face. We should know more about the actual implementation of sidechains within 3 months, as the company Blockstream will be releasing a white paper and source code. Many of these ideas that aren’t published will be directly applicable to treechains, as they are kin in many ways, including how they will be rolled out initially.

I’m personally biased towards treechains in that I believe the de-coupling of miners and policy is a huge step forward, even just for new fancy opcodes without permission. It may also enable us to be free of begging MegaPool#9 not to 51% attack us, which is already happening. I for one would like to solo-mine on a USB ASIC!

Unfortunately due to its complexity and fundamental difference with Bitcoin proper, it will almost certainly take more time to flesh out and convince others that radical steps need to be taken to keep cryptocurrency decentralized. I look forward to its development.

If you have time on your hands to check out more of the details of treechains,
here is Peter Todd’s initial writeup of many of the ideas: http://www.mail-archive.com/[email protected]/msg04388.html


As well as the Let’s Talk Bitcoin podcast where he goes into much of this detail: here:http://letstalkbitcoin.com/ltb104-tree-chains-with-peter-todd/
(thanks to /u/_Mr_e)

Hope someone finds this helpful,

Greg Sanders
Contributor to Bitcoin.org’s Bitcoin Developer Guide
[email protected]


Peter Todd (https://twitter.com/petertoddbtc)sent us the following:

FWIW there are some concerns raised re: how tree chains handles data
loss at the lowest levels; I’m not sure yet that those concerns can be
resolved. Also Adam Back raised some potential issues re: incentives in
some edge cases. Of course, you did quite correctly describe the idea as
half baked.

又一个新亮点，必须支持

bitcoin2.0 树链技术（treechains technology）翻译计划








树链技术是由 bitcoin core的开发者peter todd 提出的一项技术，相比侧链具有更好理念和发展空间，如果成功实施，可以解决bitcoin的51攻击等很多问题，并且促进整个虚拟行业的蓬勃发展。因此决定实施这个翻译计划，目前有以下文章需要翻译：

1 树链奠基性文章  （peter todd）

http://www.mail-archive.com/[email protected]/msg04388.html

2 树链技术前序（peter todd）

http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html

3 树链技术总结性文章(Greg Sanders)


http://blog.greenaddress.it/2014/06/13/sidechains-treechains-the-tldr/

4 Coindesk 对peter todd的采访（已翻译并发表在巴比特和比特儿）

http://www.coindesk.com/peter-todd-joins-viacoin-development-team-chief-scientist/

翻译：1  http://www.8btc.com/peter-todd-joins-viacoin-development-team-chief-scientist
        2  https://bter.com/article/2187
      

感兴趣的成员可以在帖子下面留言。

翻译后的文章会发表在：

1 巴比特
2 壹比特
3 比特儿
4 比特时代

权利归翻译者本人所有。


欢迎捐赠：

BTC：12LvWk2baFweyd6LunUKMqtJeLHZRifk5r

谢谢大家支持。