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'm a bit amateur at this sort of thing, but let me try to argue that this
proposal is in fact horribly broken ;)
Suppose Alice has some UTXO with some money Bob wants to steal. Grant me
that the public key P0 protecting Alice's UTXO is public (say because the
public key has been reused elsewhere
> To make it completely transparent to unupgraded wallets, the return outputs
> have to be sent to something that is non-standard today, i.e. not P2PK,
> P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
Johnson,
I feel that's not as much of an issue with v0 witness program
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/09/2017 09:09 AM, Raystonn . via bitcoin-dev wrote:
> This study was released last week, detailing some attacks at the
> network layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of
> the countermeasures discussed in the paper, the use o
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
See https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki and
https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki
On Tue, May 9, 2017 at 12:09 PM, Raystonn . via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This study was released last week, detailing some att
This study was released last week, detailing some attacks at the network layer:
https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of the countermeasures
discussed in the paper, the use of encryption to secure communications between
nodes looks like low hanging fruit.
Raystonn
To make it completely transparent to unupgraded wallets, the return outputs
have to be sent to something that is non-standard today, i.e. not P2PK, P2PKH,
P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
Mainchain segwit is particularly important here, as that allows atomic swap
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
20 matches
Mail list logo
