Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Per-block non-interactive Schnorr signature aggregation

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

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

> 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

Re: [bitcoin-dev] Network-layer attacks

-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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

> > > > 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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Network-layer attacks

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

[bitcoin-dev] Network-layer attacks

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

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

> 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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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