[Bitcoin-segwit2x] segwit2x alpha release code drop

Jared Lee Richardson jaredr26 at gmail.com
Fri Jun 16 19:28:27 UTC 2017


> 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 misunderstood this until just recently.  The reason for the witness
discount is because when making a transaction, inputs are signed now, and
outputs are signed later.  Users and their wallets use short-term thinking
and find it easier to split one output into two (one signature) rather than
combining two or more outputs (two or more signatures).  The current flat
transaction weight calculation takes only raw bytes size into account, and
thus rewards the short term thinking in the short term.

Everyone would benefit if instead all wallets were encouraged to reduce
utxos whenever possible instead of increasing them.

Bandwidth, rather than utxo bloat, is the controlling cost for all node
operational costs I have looked at, but anything that encouraged the
network to(over large averages) decrease total bytes weight instead of
increasing it would be beneficial.

Jared

On Fri, Jun 16, 2017 at 10:46 AM, 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/172a3d16/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list