From: Andrew <onelineproof@gmail•com>
To: Martin Schwarz <martin.schwarz@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Date: Mon, 15 Jun 2015 17:05:05 +0000 [thread overview]
Message-ID: <CAL8tG=kEv9AfQM+1Rv+tqBujFEjCp+BsjQ-1s7eJC-usogFFqw@mail.gmail.com> (raw)
In-Reply-To: <557D2571.601@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7065 bytes --]
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: 8187 bytes --]
next prev parent reply other threads:[~2015-06-15 17:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 2:55 Andrew
2015-05-25 18:15 ` Mike Hearn
2015-05-28 2:16 ` Andrew
2015-05-28 2:34 ` Bryan Bishop
2015-06-13 14:39 ` Pieter Wuille
2015-06-13 17:55 ` Andrew
2015-06-14 6:55 ` Martin Schwarz
2015-06-15 17:05 ` Andrew [this message]
2015-06-15 17:09 ` Pieter Wuille
2015-06-15 17:15 ` Jeff Garzik
2015-06-16 18:17 ` Peter Todd
2015-06-16 18:43 ` Andrew
2015-06-16 19:04 ` Andrew
2015-06-15 17:18 ` Mike Hearn
2015-06-15 18:00 ` Andrew
2015-06-16 15:23 ` Andrew
2015-06-15 18:01 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL8tG=kEv9AfQM+1Rv+tqBujFEjCp+BsjQ-1s7eJC-usogFFqw@mail.gmail.com' \
--to=onelineproof@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=martin.schwarz@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox