I'm not advocating. I'm mediating.
This is out of
On Wed, May 10, 2017 at 1:39 PM, Matt Corallo
wrote:
> I highly disagree about the "not shit" part. You're advocating for
> throwing away one of the key features of Segwit, something that is very
> important for Bitcoin's long-term reliability
I highly disagree about the "not shit" part. You're advocating for throwing
away one of the key features of Segwit, something that is very important for
Bitcoin's long-term reliability! If you think doing so is going to somehow help
get support in a divided community, I don't understand how - m
Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It has
always been good enough. And at the beginning it was quite simple. Simple
enough it allowed gradual improvements that anyone with some technical
background could understand. Now we need a full website to explain an
improvem
I'm highly unconvinced of this point. Sure, you can change fewer lines
of code, but if the result is, lets be honest, shit, how do you believe
its going to have a higher chance of getting acceptance from the broader
community? I think you're over-optimizing in the wrong direction.
Matt
On 05/09/1
If there's a better factor than 0.25 I would change it now before deploying
segwit instead of leaving it to be changed later with a hf.
On 9 May 2017 10:59 pm, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I agree with you Matt.
> I'm artificially limiti
I agree with you Matt.
I'm artificially limiting myself to changing the parameters of Segwit as it
is..
This is motivated by the idea that a consensual HF in the current state
would have greater chance of acceptance if it changes the minimum number of
lines of code.
On Tue, May 9, 2017 at 5:13
On Tue, May 9, 2017 at 7:42 PM, Matt Corallo wrote:
> at beast.
Rawr.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
There is something in between throwing the SegWit goals out the window
(as Sergio seems to be advocating for) and having a higher discount
ratio (which is required for the soft fork version to be useful).
When I first started looking at the problem I very much wanted to reduce
the worst-case block
On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev
wrote:
> The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
> block size is the same.
And the UTXO bloat potential is twice as large and the cost of that
UTXO bloat is significantly reduced. So you're ba
Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.
Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)
n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000
Then n=4,000,000 / 5.7 = 701K
Average block size = 701K*(1+1.7)=1.8 Mbytes
Maximum block size = 4 MBytes
Segwit with 50% discount + 2MB HF
>
>
>
> You suggested "If the maximum block weight is set to 2.7M, each byte of
> non-witness block costs 1.7", but these numbers dont work out - setting
> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
> fork), not 2.7MB.
Yes. In a soft-fork is true.
I was thinking about w
I'm not sure who wrote segwit.org, but I wouldn't take it as
authoritative reasoning why we must do X over Y.
You seem to be claiming that there is not cost for a miner to fill
"extra witness space", but this is very untrue - in order to do so they
must forgo fees on other transactions. Your analy
Doing a second soft-fork from 50% to 75% sounds more difficult since
that's going from a more restrictive ruleset to less restrictive, you
might be able to hack around it but it wouldn't be a fully backwards
compatible change like going from 75% to 50% would be. 50% vs 75% does
affect max transacti
No, changing from 50% to 75% is a hardfork. (75 -> 50 is a softfork). Unless
you make it pre-scheduled, or leave a special “backdoor” softfork to change the
discount.
And that would certainly reduce the max tx/s with 50% discount, also reduce the
incentive to spend witness UTXO.
> On 10 May 2
Thanks Johnson and Hampus for the clarifications.
However, I would rather do the opposite: soft-fork to 50% now, and
soft-fork again to 75% discount later if needed, because it doesn't affect
the max transactions/second.
Segwit as it is today should be activated. However if it is not before
Novemb
> On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev
> wrote:
>
>
> So it seems the 75% discount has been chosen with the idea that in the future
> the current transaction pattern will shift towards multisigs. This is not a
> bad idea, as it's the only direction Bitcoin can scale
The discount is designed to reduce UTXO bloat primarily, witness spam
data would not make it into the UTXO set. The discount brings the fee
of a transaction more in line with the actual costs to the network for
the transaction. A miner spamming the network with 4MB witness blocks
would have very li
This [1] article says the current discount prevents witness spam. Witness
spam is free space in the witness part of the block that can be filled by
miners to create bigger blocks with almost no cost for the benefit a
cluster of miners with low latency, increasing centralization.
The 75% discount d
Sergio,
I'm not sure what the data you present has to do with the discount. A 75%
discount prevents witness spam precisely because it is 75%, nothing more.
The current usage simply gives a guideline on how much capacity is gained
through a particular discount. With the data you show, it would im
On Mon, May 8, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev
wrote:
> The non-witness data weight factor should not be 4 but 2.35. The closest
> integer value is 2, which leads to a 50% witness discount.
Sergio, You've provided absolutely no information to qualify your
"should be". It s
I have processed 1000 blocks starting from Block #461653.
I computed several metrics, including the supposed size of witness data and
non-witness data (onchain), assuming all P2SH inputs/outputs are converted
to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
This takes into account
21 matches
Mail list logo
