Actually, I have to think about this merge-mining thing a bit more. I'm
starting to think it's better to do without merge-mining at all. As I
explained in the forum post, the parent will put the hashes of its children
headers as transactions inside its blocks. Thus parents will have an
incentive to
On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd wrote:
> Merge-mined sidechains are not a scaling solution any more than SPV is a
> scaling solution because they don't solve the scaling problem for
> miners.
>
> Some kind of treechain like sidechain / subchains where what part of the
> tree miners ca
On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote:
> On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille
> wrote:
>
> > It's simple: either you care about validation, and you must validate
> > everything, or you don't, and you don't validate anything. Sidechains do
> > not offer you a useful
Let me ask a simpler question. How do you prove the state of the UTXO
database corresponding to your wallet? With my subchain method, all the
addresses in a wallet can be constrained to a path of subchains, so the
proof is O(log n). Yes, I know some people will say that it is not really a
proof bec
Side chains are a way to scale and shard horizontally while still retaining
primary security parameters of the main chain.
The future is an Internet of chains, a forest of chains with bitcoin as the
root chain for: factom / proofofexistence, ChainDB, Blockstream side
chains, merge mined side chain
Pieter: I kind of see your point (but I think you're missing some key
points). You mean just download all the headers and then just verify the
transactions you filter out by using their corresponding merkle trees,
right? But still, I don't think that would scale as well as with the tree
structure I
>
> It's simple: either you care about validation, and you must validate
> everything, or you don't, and you don't validate anything.
>
Pedantically: you could validate a random subset of all scripts, to give
yourself probabilistic verification rather than full vs SPV. If enough
people do it with a
On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille
wrote:
> It's simple: either you care about validation, and you must validate
> everything, or you don't, and you don't validate anything. Sidechains do
> not offer you a useful compromise here, as well as adding huge delays and
> conplexity.
>
As n
If you are fine with the SPV security model, you are much better off by
just increasing the Bitcoin block size and using an SPV client, as those do
not care or even see the full block size by only downloading transactions
they care about. Infinite scalability!
The problem with scaling is that ulti
Hi All,
I talked with Pieter off-list. And I guess the main opposition is that
coins that are coming from chains that you are not directly validating are
not fully validated by you in the sense that you only get an SPV type proof
to prove that miners have accepted those coins. Yes, it's true, but
Pieter,
Am 13.06.2015 um 16:39 schrieb Pieter Wuille:
> We can reasonably assume that different people's wallet will tend to be
> distributed uniformly over several sidechains to hold their transactions (if
> they're not, there is no scaling benefit anyway...). That means that for an
> average
First of all, I added more info to bitcointalk.org:
https://bitcointalk.org/index.php?topic=1083345.0
On Sat, Jun 13, 2015 at 2:39 PM, Pieter Wuille
wrote:
>
> In your proposal, transactions go to a chain based the addresses involved.
> We can reasonably assume that different people's wallet wil
On Wed, May 20, 2015 at 4:55 AM, Andrew wrote:
> Hi
>
> I briefly mentioned something about this on the bitcoin-dev IRC room. In
> general, it seems experts (like sipa i.e. Pieter) are against using
> sidechains as a way of scaling. As I only have a high level understanding
> of the Bitcoin proto
On Wed, May 27, 2015 at 9:16 PM, Andrew wrote:
> You should also keep in mind the big picture when it comes to
> decentralization. If the hard drives (or tapes) can only be produced by a
> small number of large companies like Western Digital or Seagate, then you
> can't really count those for a d
Hi All
I discussed this idea with some other core developers (on IRC) and they
generally seem to agree that it can be done.
It may be equivalent to an idea called "blockchain extensions" but when I
looked it up on bitcointalk.org I didn't see exactly the same proposal I am
making.
One person sug
Hi Andrew,
Your belief that Bitcoin has to be constrained by the belief that hardware
will never improve is extremist, but regardless, your concerns are easy to
assuage: there is no requirement that the block chain be stored on hard
disks. As you note yourself the block chain is used for building/
Hi
I briefly mentioned something about this on the bitcoin-dev IRC room. In
general, it seems experts (like sipa i.e. Pieter) are against using
sidechains as a way of scaling. As I only have a high level understanding
of the Bitcoin protocol, I cannot be sure if what I want to do is actually
defin
17 matches
Mail list logo