public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
To: Adam Tamir Shem-Tov <tshachaf@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
Date: Sun, 27 Aug 2017 01:18:32 -0400	[thread overview]
Message-ID: <0dd361fb-8983-44c4-7f14-cd1e43049feb@aei.ca> (raw)
In-Reply-To: <CACQPdjoqph7RJhk8Ec8B8SiXixdCQ0VQB5B3+U-1pPxyp=hj4g@mail.gmail.com>

How do you trust your <1000 block blockchain if you don't
download/validate the whole thing? (I know it should be easy to spot
that by looking at the blocks/tx or comparing to other nodes, but from a
programmatic point of view this is much harder). You can of course
include a checkpoint in the code to tell which recent block is valid
(which is already done afaik), but you still need all blocks from that
checkpoint to validate the chain (not 10!). If you rely on such
checkpoint, why not just include the UTXO's as well so you can start
mid-way based on code trust?

Indeed pruning doesn't allow you to start mid-way yet but there are much
easier solutions to that than what you propose.

--
Thomas

On 26/08/17 06:32 PM, Adam Tamir Shem-Tov wrote:
> Thank you Thomas for your response.
>
> 1) Implement solution is impossible... I have given a solution in part
> II. By adding a Genesis Account which will be the new sender.
>
> 2)Keeping older blocks: Yes as I said 10 older blocks should be kept,
> that should suffice. I am not locked on that number, if you think
> there is a reason to keep more than that, it is open to debate.
>
> 3) Why 1000? To be honest, that number came off the top of my head.
> These are minor details, the concept must first be accepted, then we
> can work on the minor details.
>
> 4)Finally it's not just the addresses and balance you need to save... 
> I think the Idea of the Genesis Account, solves this issue.
>
> 5) The problem with node pruning is that it is not standardized, and
> for a new node to enter the network and to verify the data, it needs
> to download all data and prune it by itself. This will drastically
> lower the information needed by the full nodes by getting rid of the
> junk.  Currently we are around 140GB, that number is getting bigger
> exponentially, by the number of users and transactions created. It
> could reach a Terrabyte sooner than expected, we need to act now.
>
> On your second email:
> When I say account: I mean private-public key.
> The way bitcoin works, as I understand it, is that the funds are
> verified by showing that they have an origin, this "origin" needs to
> provide a signature, otherwise the transaction won't be accepted.
> If I am proposing to remove all intermediate origins, then the funds
> become untraceable and hence unverifiable. To fix that, a new
> transaction needs to replace old ones. A simplified version: If there
> was a transaction chain A->B->C->D, and I wish to show only A->D, only
> a transaction like that never actually occurred, it would be
> impossible to say that it did without having A's private key, in order
> to sign this transaction. In order to create this transaction, I need
> A's private key. And if I wish this to be publicly implemented I need
> this key to be public, so that any node creating this Exodus Block can
> sign with it. Hence the Genesis Account. And yes, it is not really an
> account.




  reply	other threads:[~2017-08-27  5:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-26 19:21 [bitcoin-dev] Solving the Scalability Problem on Bitcoin Adam Tamir Shem-Tov
2017-08-26 21:31 ` Thomas Guyot-Sionnest
2017-08-26 22:32   ` Adam Tamir Shem-Tov
2017-08-27  5:18     ` Thomas Guyot-Sionnest [this message]
     [not found]     ` <CAN6UTayLR6rqSuHrsyF+7fFM4Fht7vbgXYRWzBRYXw8i43WzBw@mail.gmail.com>
2017-08-27 12:10       ` Leandro Coutinho
2017-08-27  3:52   ` Btc Ideas
2017-08-27  0:27 ` Weiwu
2017-08-27 13:19 Matthew Beton

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=0dd361fb-8983-44c4-7f14-cd1e43049feb@aei.ca \
    --to=dermoth@aei.ca \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tshachaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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