Re: [bitcoin-dev] Protocol-Level Pruning

[Marc Bevand via bitcoin-dev]

Ah, thanks, I suspected the idea was too simple and must have been
discussed before, but somehow I missed these proposals. I've got some
reading to do.

-Marc

On Thu, Nov 16, 2017 at 11:14 AM, Bryan Bishop  wrote:

> It's not clear to me if you are have looked at the previous UTXO set
> commitment proposals.
>
> some utxo set commitment bookmarks (a little old)
> http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-
> fraud-proofs.stdout.txt
>
> TXO bitfields
> http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/
> 2017-07-08-bram-cohen-merkle-sets/
>
> delayed TXO commitments
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-May/012715.html
>
> TXO commitments do not need a soft-fork to be useful
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013591.html
>
> rolling UTXO set hashes
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014337.html
>
> lotta other resources available, including source code proposals..
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Protocol-Level Pruning

[Bryan Bishop via bitcoin-dev]

It's not clear to me if you are have looked at the previous UTXO set
commitment proposals.

some utxo set commitment bookmarks (a little old)
http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt

TXO bitfields
http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-08-bram-cohen-merkle-sets/

delayed TXO commitments
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html

TXO commitments do not need a soft-fork to be useful
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html

rolling UTXO set hashes
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html

lotta other resources available, including source code proposals..

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Protocol-Level Pruning

[Marc Bevand via bitcoin-dev]

It occurred to me that we could push the classic concept of pruning even
further: we could significantly shrink the blockchain as well as reduce the
amount of network traffic during initial block download by doing something
I would call protocol-level pruning. This would, as of today, reduce the
size of the blockchain by a factor of 50, hence enabling massive on-chain
scaling.

The idea behind PLP is to serialize the UTXO set in a standardized way, and
publish a hash of it in the block header so that the blockchain commits to
it. Since hashing and verifying it is a moderately intensive operation,
perhaps the UTXO set hash should be published only once every 576 blocks (4
days).

When a new Bitcoin node joins the network, it would download the block
headers only (not the block data), it would identify the most recent block
containing the UTXO set hash, and download the UTXO set from peers. From
that point on, it downloads and verifies all blocks as normal.

Every 576 blocks, nodes serialize and verify that their UTXO set hash
matches the one published in the blockchain. Doing so becomes a new part of
consensus rules. The last 576 blocks could then be permanently discarded as
they are no longer useful.

Today the serialized UTXO set is about 3GB and the blockchain is about
150GB. Therefore PLP would cut down the amount of data stored by full nodes
by a factor of ~50 as they would have to store only the UTXO set plus at
most 576 blocks.

One trivial optimization is possible: to avoid hashing the entire UTXO set
every 576 blocks (which would take multiple seconds even on a fast
machine), the UTXO set serialization could be a sparse merkle tree
 which would allow on-the fly
recomputation of the hash as new blocks are mined: when a UTXO is added to
(or removed from) the tree, only a small number of hash operations are
needed to recalculate the UTXO set merkle tree root hash.

Maybe we don't even need sparse merkle trees, but a regular merkle tree
would suffice: the tree leaves would be small groups of UTXOs (some bits in
the ID/hash of a UTXO would determine which leaf it belongs to.)

Unlike classic pruning mode, *ALL* full nodes on the network could switch
to PLP. There is no need for any node to archive the entire blockchain any
more.

I can think of one downside of PLP: nodes would no longer be able to handle
reorgs that go further back than the last UTXO set hash published on the
chain (since previous blocks have been discarded). So, perhaps keeping
around the last N*576 blocks (N=10?) would be a sufficient workaround.

Thoughts?

-Marc
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] POW - Miner's choice?

[Stikkan83 via bitcoin-dev]

hello list,

would it be possible to have two available POW mining algorithms (like
for example "Double-SHA256" and "Cuckoo Cycle"), and let the miner
choose which one to use for POW?

the two algorithms would have independent difficulties, and after each
difficulty period, the difficulty would be adjusted to aim for 50/50
distribution of the two algorithms (in addition to aim for 10 minutes
block time).

this could be done by only adjusting up difficulty for the algorithm
used in most blocks last period, or only adjusting down difficulty for
the algorithm with the least number of blocks last period (depending
on whether the combined difficulty was to be adjusted up or down).  or
maybe a more sophisticated variant, where both difficulties are
adjusted, based on the relative difference of the number of blocks
where they are used.

the main motivation for this would be:

- increase mining distribution
- continue mining even when one type of miners suddenly jump to mine a
  more profitable altcoin.

not sure if this has been proposed (and rejected) before, but I can't
remember seeing it discussed.

would probably require a hard fork.

SA___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard

[Sjors Provoost via bitcoin-dev]

Can you clarify what you mean by "whitelisting all blocks before the softfork 
block"?

The most conservative approach could be to leave the code in place until the 
very last non-segwit P2SH UTXO from before the soft fork block has been spent. 
But this would never happen if even a single private key is lost.

After making these transactions non-standard and removing the code, 
transactions containing these OP-codes could be considered valid (perhaps still 
checking the signature, etc). Some miners would still run the code and mine 
those transactions, but others wouldn't verify them. This is strictly less bad 
than losing those funds forever, but doesn't seem acceptable either.

Is there a variant of the above scenario where a miner puts up some very large 
deposit (e.g. 10x the size of the UTXO) if they mine such a legacy transaction, 
and can lose that if someone else runs the code and finds the transaction 
invalid?

Sjors

> Op 15 nov. 2017, om 20:54 heeft Mark Friedenbach via bitcoin-dev 
>  het volgende geschreven:
> 
> As good of an idea as it may or may not be to remove this feature from the 
> code base, actually doing so would be crossing a boundary that we have not 
> previously been willing to do except under extraordinary duress. The nature 
> of bitcoin is such that we do not know and cannot know what transactions 
> exist out there pre-signed and making use of these features.
> 
> It may be a good idea to make these features non standard to further 
> discourage their use, but I object to doing so with the justification of 
> eventually disabling them for all transactions. Taking that step has the 
> potential of destroying value and is something that we have only done in the 
> past either because we didn’t understand forks and best practices very well, 
> or because the features (now disabled) were fundamentally insecure and 
> resulted in other people’s coins being vulnerable. This latter concern does 
> not apply here as far as I’m aware.
> 
> On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev 
>  > wrote:
> 
>> In https://github.com/bitcoin/bitcoin/pull/11423 
>>  I propose to make 
>> OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard
>> 
>> I think FindAndDelete() is one of the most useless and complicated functions 
>> in the script language. It is omitted from segwit (BIP143), but we still 
>> need to support it in non-segwit scripts. Actually, FindAndDelete() would 
>> only be triggered in some weird edge cases like using out-of-range 
>> SIGHASH_SINGLE.
>> 
>> Non-segwit scripts also use a FindAndDelete()-like function to remove 
>> OP_CODESEPARATOR from scriptCode. Note that in BIP143, only executed 
>> OP_CODESEPARATOR are removed so it doesn’t have the FindAndDelete()-like 
>> function. OP_CODESEPARATOR in segwit scripts are useful for Tumblebit so it 
>> is not disabled in this proposal
>> 
>> By disabling both, it guarantees that scriptCode serialized inside 
>> SignatureHash() must be constant
>> 
>> If we use a softfork to remove FindAndDelete() and OP_CODESEPARATOR from 
>> non-segwit scripts, we could completely remove FindAndDelete() from the 
>> consensus code later by whitelisting all blocks before the softfork block. 
>> The first step is to make them non-standard in the next release.
>> 
>> 
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
>> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev