Re: [Bitcoin-development] Scaling Bitcoin with Subchains

[Pieter Wuille <pieter.wuille@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8004 bytes --]

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 ultimately even SPV security relies on
others being able to validate. Both sidechains and larger block sizes make
that harder.

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.
On Jun 15, 2015 7:05 PM, "Andrew" <onelineproof@gmail.com> wrote:

> 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 once
> blocks have been mined, there is nothing you can really do about it.
> Splitting up the transactions into multiple chains doesn't stop someone
> from validating all chains, which results in the same validation workload
> as a full node with one chain and big blocks that store the same number of
> transactions per second. So there is no disadvantage from using this method
> compared with having big blocks, and there are clear advantages. The only
> excuse is laziness to create a proper system.
>
> Martin: I'm not sure if random independent chains would be so useful since
> there are delays with cross chain transfers and you would not be sure if
> those chains will be maintained in the future. My idea is more the idea of
> extension blocks, i.e. synchronised chains.
>
> Also, some people think that CPU speed and memory size are the only
> limitations to running a full node, and they think that it is ok to just
> run a heavily pruned node. Pruned nodes (nodes that have less than 10 years
> of transactions on their hard drives) are bad for the network. Reasons why
> you would want the long term history of transactions on your hard drive:
>
> 1) Your computer could have been compromised when you did the initial
> validation, so you may want to validate and see all the old transactions
> again.
>
> 2) You don't have to spend much time to download transactions that you
> want to analyze but have already pruned.
>
> 3) Risk of denial of service attack from the "archival" nodes.
>
> 4) There is less of an inequality between the big data centers and regular
> people. We can analyze the history of the transactions that are relevant to
> us just as effectively as the data centers. With the pruning model, it will
> be more like NSA-style nodes watching our transaction history, while
> regular people can only see "snapshots". Remember how the Bitcoin community
> was analysing the old Mt Gox transactions using the blockchain? This kind
> of stuff will no longer be possible if most people can only run pruned
> nodes.
>
> 5) The data is more distributed thus more easy for others to download
> (think torrent downloads vs downloading from a central server).
>
> 6) Again being distributed, more eyes will be looking at the long term
> data, thus people can more easily investigate scandals and things like that.
>
> 7) Without the full history of blocks people cannot really give a proof to
> others that what they noticed with their pruned nodes is actually what
> happened (if they spot something interesting).
>
> 8) The time for a new user to start fresh and sync a full node with a long
> term history of transactions is much more accessible (17 days for 100 years
> of transactions with 1 MB blocks on high-end computers). Same with the time
> needed to perform any kind of analysis on the old transactions. And
> remember, any new transactions likely depend on old transactions, so yes
> they are very relevant.
>
> This is not paranoia. These are real security risks. So don't tell me that
> you are really running a full node with the same level of security when you
> are pruning it. Also, don't tell me that the security of running a full
> node remains the same when centralization is increased (like with bigger
> block sizes). Centralisation is a security risk.
>
> Some people think that decentralisation means you have to run a possibly
> noisy desktop in a possible space restricted home, which can be annoying.
> No, you don't have to. You can run a full node (or an almost full node on
> the chains you are interested in) in a shack in the middle of nowhere and
> you can monitor it remotely with cameras or whatever. The point is that it
> is easy for a regular person to run one and they can do so without causing
> attention and without anyone's permission. That is decentralisation. Even
> 10 MB blocks are too much to enable this definition of decentralisation
> (according to my calculations).
>
> If there are people who choose to run Gavin/Mike's hard fork of Bitcoin
> because they are uniformed or mentally challenged or have bad intentions,
> then there is not much I can do (I try to inform but I don't have such a
> high popularity level to be effective there), but I will surely not accept
> any bitcoin that is only valid on blocks with size greater than 1 million
> bytes. Such coins will have 0 or even negative value to me, and I expect
> others to do the same.
>
> In the meantime, I will start the development process of my proposed
> scaling methods using bitcoin-core and possibly the sidechains code from
> Blockstream as a base. I don't have much free time, so progress will likely
> be slow, but if I believe in something, I will keep working on it. I'm
> still seeking more criticism of my proposal, because you know, I don't want
> to waste my time if there's something fundamentally wrong with it.
>
> Cheers
>
> On Sun, Jun 14, 2015 at 6:55 AM, Martin Schwarz <martin.schwarz@gmail.com>
> wrote:
>
>> 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 transaction, you will need a cross-chain transfer in order
>> to get the money to the recipient (as their wallet will usually be
>> associated to a chain that is different from your own).
>>
>> I think we should set the right incentives to invalidate these
>> assumptions. If the fees as well as the security guarantees
>> on the main chain are highest and fees are dropping with the distance
>> from the main chain on each level of side chains,
>> wouldn't communities with many internal transactions create their own
>> side chain with low fees? I'd expect geographic
>> as well as virtual communities to be forming enjoying cheap fees on their
>> 'local' chains and expensive but comparabily rare
>> 'long distance' fees. One would expect geographic chains (e.g.
>> continents) as well as virtual ones (e.g. the Open Bazaar
>> users' chain) to form. To save fees, a typical user would maintain a
>> wallet in each of her communities which are loaded
>> and drained with rare expensive transacations, whereas daily business
>> with many transactions is done cheaply within
>> each community chain. So, indeed, I would argue that side chains equipped
>> with the right cost incentives for cross-chain
>> transactions would lead to a scalable and efficiently self-organizing
>> network of side chains.
>>
>> best regards,
>> Martin
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>

[-- Attachment #2: Type: text/html, Size: 9155 bytes --]