[Bitcoin-segwit2x] segwit2x alpha release code drop

[Jameson Lopp]

On Fri, Jun 16, 2017 at 12:12 PM, Jeff Garzik <jeff at bloq.com> wrote:

> On Fri, Jun 16, 2017 at 12:37 PM, Jameson Lopp <jameson.lopp at gmail.com>
> wrote:
>
>> Rough analogy:  Imagine a market where automobiles are sold by weight
>>> (kg).  This market now embarks on an opt-in transition to selling
>>> automobiles based on engine size (cc's), a metric that automobile experts
>>> agree better measures automobile ability.  Result:  Some bidders in the
>>> market buy cars based on weight, others based on cc's.  How does one bid
>>> efficiently in an always-in-transition market?   SegWit is not just a
>>> technology upgrade, it is a market upgrade.
>>>
>>
>> I'm not convinced this analogy fits given that the market completely
>> transitions to all users bidding based upon weight. Users who are driving
>> old, heavy cars will now be incentivized to upgrade to more modern cars
>> manufactured with lightweight materials.
>>
>
> Comments,
>
> C1) I was making a larger point that you have two different resources that
> really do have two different supply and demand rates, and bidding into that
> market is complex.
>
> C2) It is therefore a *simplification* and *assumption* that market users
> will behave a certain way in bidding for witness data area.   Wallets that
> hardcode this assumption may therefore be making non-optimal economic
> decisions on behalf of their users.
>
> C3) It seems unwise to build in *artificial* incentives to transition
> from a known-working system to a new system.  Let that happen naturally.
>
>
>
>
>>
>>
>>>
>>> 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'm not so sure that there is a perfect ratio given the arbitrary
>> complexity that inputs can have. I think you'd need some kind of dynamic
>> weighting that would be much more complex and would require significant
>> development resources to implement. I don't think we should let perfect be
>> the enemy of good given the timeline of this project.
>>
>
>
> The sum of these two paragraphs is: [it's not arbitrary][ok, it's
> arbitrary]   :)
>
> The bigger point, though, is that you cannot just look at the witness
> discount purely through a narrow UTXO lens.
>
> The other side of the artificial incentive, for example, is that you have
> created a direct incentive to put cheap garbage data into this newly
> extended block.  Let's call this Garbage Risk.
>
> This is the risk of not letting the market naturally balance itself out,
> and one of several unintended consequences of inserting an artificial ratio.
>
> I think there has been a mixing of terms with regard to this particular
issue - a 75% discount is an approximation of a common ratio of input to
output sizes (3:1) though it is possible to create more complex
transactions with higher ratios, even as much as 10:1 if not higher. If the
discount was /arbitrary/ rather than /approximate/ then there would be /no/
reasoning behind its selection.

That's an interesting point about Garbage Risk - I'd pose that the Garbage
Risk we have today is pretty bad due to the imbalance in cost of spending
inputs vs creating outputs. As it stands today, we have entities creating
transactions with hundreds and hundreds of tiny value outputs on a regular
basis because it's relatively cheap for them to do so - cloud mining is one
specific example I have personally seen. Then later, when the recipients of
these outputs try to spend them, they are greatly penalized due to the huge
size of their inputs. If such recipients are using SegWit, at least they
won't be paying disproportionately to spend their funds.

Sure, it's not perfect, but I think there's general agreement that it's a
step in the right direction.


> --
> Jeff Garzik
> CEO and Co Founder
> Bloq, Inc.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170616/62fbaf48/attachment-0001.html>