[Bitcoin-segwit2x] segwit2x alpha release code drop

[Jason Dreyzehner]

It's also worth noting that a UTXO-set-less implementation of block
validation exists: https://bitcrust.org/


Rather than reference a UTXO-set, Bitcrust checks a "spend-tree":
https://github.com/tomasvdw/bitcrust/blob/master/doc/bitcrust-db.md


In this model, UTXO-set minimization seems to be much less valuable.

On Fri, Jun 16, 2017 at 1:52 PM Stephen Pair via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> On Fri, Jun 16, 2017 at 12:37 PM, Jameson Lopp via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
>> On Thu, Jun 15, 2017 at 11:52 PM, Jeff Garzik via Bitcoin-segwit2x <
>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>>>
>>> 2) Witness discount/scaling factor
>>>
>>> It is fair to say that this remains an issue of note.  A few WG members
>>> have independently described the witness discount as an arbitrary economic
>>> incentive encoded directly into the software.
>>>
>>> As a thought exercise, removing the scaling factor still retains extra
>>> witness space and therefore retains a natural incentive to stash data
>>> there, while removing a weighting that may or may not be the best ratio.
>>>
>>> Block weight plays into this - if you're not scaling, you don't need an
>>> abstract "weight" unit, just a total size.   For wallets (#1, above), size
>>> is probably more simple to reason and calculate than weight.  Block size is
>>> a well studied attribute, versus block weight.
>>>
>>>
>>> The witness discount is not arbitrary. The economics of spending inputs
>> versus creating outputs is terribly imbalanced and the discount is applied
>> in order to bring it more in balance. It can cost 5X-10X as much (data size
>> & thus fees) to add an input (↓ UTXO set size) vs an output (↑ UTXO set
>> size) to a transaction. It could probably be argued that a 75% discount is
>> actually conservative in terms of trying to rebalance this discrepancy.
>>
>
> I think what you are suggesting is that data that can be pruned (yet still
> allow full, independent validation) should not cost as much as data that
> cannot be pruned.  While the witness discount doesn't give me great
> heartburn and isn't really worth the bike shedding, I think it might be
> premature to assume raw UTXO data cannot be pruned.  A very simple approach
> would be to keep a bitfield for each block to indicate which of the outputs
> has been spent and discard the raw UTXO data (ignoring the complexities of
> branches and re-orgs).  To validate a transaction, you would need to fetch
> the input transactions from somewhere (i.e. another node that stores the
> full block chain).  You would also need the SPV/merkle proof that it was in
> the chain and then you would check your bitfield to verify that it has not
> yet been spent.
>
> I think if you tried hard enough, a pruning node could shed nearly all of
> the raw block chain data and still be able to perform full and independent
> validation going forward.  The operator of the node could then just decide
> how much local storage to use vs relying on other nodes for fetching raw
> data.  And a node that stores the entire block chain would be indifferent
> as to whether that data was a UTXO, a signature, or something else.
>
> In fact, something like this might become very desirable if you had some
> sort of limited, expensive, secure storage that you wanted to take
> advantage of on a full validating node.  The smaller set of essential data
> needed for full validation would reside in this trusted, highly secure
> storage, while the full block chain would reside on a less trusted bulk
> storage device.
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170616/ceb93eeb/attachment-0001.html>