Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size.

Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size.


  2017-08-16 16:52   ` Nick ODell
  2017-08-16 18:33   ` Luke Dashjr
  
From: Алексей Мутовкин @ 2017-08-16 16:20 UTC (permalink / raw)
  To: bitcoin-dev

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

Let me describe the possible improvement of the bitcoin blockchain database
(BBD)  size in general terms.

We can implement new routine : annual split of the BBD. Reason is that
140gb full wallet unconvinience.

BBD splits in two parts :
1) old blocks before the date of split and
2) new blocks, starting from first technical block with all rolled totals
on the date of split.
    (also possible transfer of tiny totals due to their unprofitability to
the miners, so we cut long tail of tiny holders)
3) old blocks packs into annual megablocks and stores in the side archive
chain for some needs for FBI investigations or other goals.


Thanks for your attention,

Alexey Mutovkin

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

 permalink raw reply	[|nested]
2017-08-16 16:20 ` [bitcoin-dev] Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size Алексей Мутовкин

  2017-08-16 17:37     ` Алексей Мутовкин
  2017-08-16 18:33   ` Luke Dashjr
  
From: Nick ODell @ 2017-08-16 16:52 UTC (permalink / raw)
  To: Алексей
	Мутовкин,
	Bitcoin Protocol Discussion

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

What makes this approach better than the prune option of Bitcoin?

On Wed, Aug 16, 2017 at 10:20 AM, Алексей Мутовкин via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

>
> Let me describe the possible improvement of the bitcoin blockchain
> database (BBD)  size in general terms.
>
> We can implement new routine : annual split of the BBD. Reason is that
> 140gb full wallet unconvinience.
>
> BBD splits in two parts :
> 1) old blocks before the date of split and
> 2) new blocks, starting from first technical block with all rolled totals
> on the date of split.
>     (also possible transfer of tiny totals due to their unprofitability to
> the miners, so we cut long tail of tiny holders)
> 3) old blocks packs into annual megablocks and stores in the side archive
> chain for some needs for FBI investigations or other goals.
>
>
> Thanks for your attention,
>
> Alexey Mutovkin
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

 permalink raw reply	[|nested]
2017-08-16 16:52   ` Nick ODell

  
From: Алексей Мутовкин @ 2017-08-16 17:37 UTC (permalink / raw)
  To: Nick ODell;  Bitcoin Protocol Discussion

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

I read about prune option right now, actually i didn't hear about it before.
Yes this option can save some disk space but afaik first (awful N-days
lasting) synchronization still requires to download full database.
My approach also cuts database and replaces all old blocks (except say last
6 blocks for security reason)
with series of blocks with rolled initial totals and optionally purged from
tiny wallets crap (storing on six thousand current nodes and on the swarm
of full wallets
 information that John have 100 satosi is too expensive for us and we may
annually clear that balance as fee for miners or just delete).

So almost all nodes can hold only the rolled database (i can't estimate
compression ration of the rolled database now, i am not advanced user as
you can see).
 And only much less amount of archive nodes holds full expanded database.












2017-08-16 19:52 GMT+03:00 Nick ODell <nickodell@gmail•com>:

> What makes this approach better than the prune option of Bitcoin?
>
> On Wed, Aug 16, 2017 at 10:20 AM, Алексей Мутовкин via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>
>> Let me describe the possible improvement of the bitcoin blockchain
>> database (BBD)  size in general terms.
>>
>> We can implement new routine : annual split of the BBD. Reason is that
>> 140gb full wallet unconvinience.
>>
>> BBD splits in two parts :
>> 1) old blocks before the date of split and
>> 2) new blocks, starting from first technical block with all rolled totals
>> on the date of split.
>>     (also possible transfer of tiny totals due to their unprofitability
>> to the miners, so we cut long tail of tiny holders)
>> 3) old blocks packs into annual megablocks and stores in the side archive
>> chain for some needs for FBI investigations or other goals.
>>
>>
>> Thanks for your attention,
>>
>> Alexey Mutovkin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

 permalink raw reply	[|nested]
2017-08-16 16:20 ` [bitcoin-dev] Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size Алексей Мутовкин
  2017-08-16 16:52   ` Nick ODell

  
From: Luke Dashjr @ 2017-08-16 18:33 UTC ( / )
  To: bitcoin-dev,
	Алексей
	Мутовкин

To have a BIP, you need to explain not only *why* you want to do something, 
but also *what specifically* to do, and *how* to do it. This concept 
(historically known as "flip the chain" and/or "UTXO commitments") is not new, 
merely complicated to design and implement.

Luke


On Wednesday 16 August 2017 4:20:45 PM Алексей Мутовкин via bitcoin-dev wrote:
> Let me describe the possible improvement of the bitcoin blockchain database
> (BBD)  size in general terms.
> 
> We can implement new routine : annual split of the BBD. Reason is that
> 140gb full wallet unconvinience.
> 
> BBD splits in two parts :
> 1) old blocks before the date of split and
> 2) new blocks, starting from first technical block with all rolled totals
> on the date of split.
>     (also possible transfer of tiny totals due to their unprofitability to
> the miners, so we cut long tail of tiny holders)
> 3) old blocks packs into annual megablocks and stores in the side archive
> chain for some needs for FBI investigations or other goals.
> 
> 
> Thanks for your attention,
> 
> Alexey Mutovkin