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

[Jorge Timón via bitcoin-dev]

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 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 PM, Gregory Maxwell  wrote:
>
>> 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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Russell O'Connor via bitcoin-dev]

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

Bob going to spend Alice's UTXO by generating random values s0, k0 and R0
:= k0*G and thus creating a random signature for it, [R0, s0].  Now clearly
this signature isn't going to be valid by itself because it is just random.
Bob's goal will be to make a transaction with other inputs such that, while
the individual signatures are not valid, the aggregated signature will be
valid.

To do this Bob generates a set of random public keys P1 ... P_n of the form
P_i := P0 + r_i*G, and a bunch of random k1 ... k_n with R1 := k1*G ... R_n
:= k_n*G, such that

h(m1, R1, P1) + ... + h(m_n, R_n, P_n) = -h(m0, R0 P0) (modulo the
order of the elliptic curve)

I understand that this can be done efficiently with Wagner's Generalized
Birthday attack.

The RHS aggregated signature equation on the private side is

k0 + k1 + ... k_n - h(m0, R0, P0)x0 - h(m1, R1, P1)(x0 + r1) - ... -
h(m_n, R_n, P_n)(x0 + r_n)

with x0 unknown to Bob.  Rearranging the terms we get

k0 + k1 + ... k_n - [h(m0, R0, P0) + h(m1, R1, P1) + ... + h(m_n, R_n,
P_n)]*x0 - [h(m1, R1, P1)*r1 + ... + h(m_n, R_n, P_n)*r_n]

However [h(m0, R0, P0) + h(m1, R1, P1) + ... + h(m_n, R_n, P_n)] is 0 so
cancelling that we are left with

k0 + k1 + ... k_n - [h(m1, R1, P1)*r1 + ... + h(m_n, R_n, P_n)*r_n]

which no longer depends on the unknown value x0, so that is good.  Bob
knows what this value is.

Bob creates a set UTXOs by spending to the set of public keys P1 .. P_n.
Bob don't know what the private keys are for these public keys, but that is
going to be okay.

Bob creates a final transaction that takes as input the UTXO of Alice's
funds he wants to steal, with public key P0, and also his newly created
UTXOs with public keys P1 ... P_n.
For the signature on Alice's input he uses [R0,s0].  For the rest of the
signature he picks s1 ... s_n such that

s0 + s1 + ... + sn = k0 + k1 + ... k_n - [h(m1, R1, P1)*r1 + ... +
h(m_n, R_n, P_n)*r_n] (which is equal to k0 + k1 + ... k_n - h(m0, R0,
P0)x0 - h(m1, R1, P1)(x0 + r1) - ... - h(m_n, R_n, P_n)(x0 + r_n)).

and uses signatures [R1, s1] ... [R_n, s_n] on his other inputs.

Thus, while none of the individual signatures are valid, the aggregated
signature does validate.

One wrinkles in this argument is that Bob needs to pick m1 ... m_n before
he knows what the transaction will be.  I think this can be mitigated by
using some combination of SIGHASH_ANYONECANPAY, but I'm not sure if that
works.  Even if my argument doesn't actually work, I think it is close
enough to be pretty scary.

Thanks goes to Pieter Wuille for helping explain things to me; however any
errors above are my own.

On Sun, May 7, 2017 at 2:45 AM, adiabat via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If / when Schnorr signatures are deployed in a future witness version, it
> may be possible to have non-interactive partial aggregation of the
> signatures on a per-block basis.  This could save quite a bit of space.  It
> *seems* not to have any security problems but this mailing list is very
> good at finding vulnerabilities so that type of feedback is the main reason
> I'm writing :) (A quick explanation of why this is horribly broken could
> save me lots of time!)
> (also sorry if this has been discussed; didn't see anything)
>
> Quick recap / context of Schnorr sigs:
>
> There are a bunch of private keys x1, x2, x3...
> multiply by generator G to get x1G = P1, x2G = P2, x3G = P3
>
> Everyone makes their sighash m1, m2, m3, and their random nonces k1, k2,
> k3.
>
> To sign, people calculate s values:
>
> s1 = k1 - h(m1, R1, P1)x1
> s2 = k2 - h(m2, R2, P2)x2
>
> (adding the P2 into the e hash value is not in most literature /
> explanations but helps with some attacks; I beleive that's the current
> thinking.  Anyway it doesn't matter for this idea)
>
> Signature 1 is [R1, s1].  Verifiers check, given P1, m1, R1, s1:
>
> s1G =? R1 - h(m1, R1, P1)P1
>
> You can *interactively* make aggregate signatures, which requires
> co-signers to build an aggregate R value by coming up with their own k
> values, sharing their R with the co-signers, adding up the R's to get a
> summed R, and using that to sign.
>
> Non-interactively though, it seems like you can aggregate half the
> signature.  The R values are unique to the [m, P] pair, but the s's can be
> summed up:
>
> s1 + s2 = k1 + k2 - h(m1, R1, P1)x1 - h(m2, R2, P2)x2
>
> (s1 + s2)G = R1 + R2 - h(m1, R1, P1)P1 - h(m2, R2, P2)P2
>
> To use this property in Bitcoin, when making transactions, wallets can
> sign in the normal way, and the signature, consisting of [R, s] goes into
> the witness stack.  When miners generate a block, they remove the s-value
> from all compatible 

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

[Christopher Jeffrey via bitcoin-dev]

> 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 programs. Segwit
isn't activated yet, and segwit-capable wallets aren't as widely
deployed for production. Not to mention, they're all going to require
further development anyway: the address serialization for witness
programs only became a BIP this week. No segwit wallets should ever be
planning to receive money to naked witness programs right now, since
addresses are for it aren't even available.

I think we have the benefit of timing here. The state of segwit wallet
development incidentally creates a window of time where this maturity
rule can be implemented.

On Wed, May 10, 2017 at 01:56:28AM +0800, Johnson Lau wrote:
> 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 
> between the bitcoin and xbitcoin. Only services with high liquidity 
> (exchanges, payment processors) would need to occasionally settle between the 
> chains.
>
>
> > On 9 May 2017, at 08:56, Christopher Jeffrey  wrote:
> >
> > Johnson,
> >
> > Yeah, I do still see the issue. I think there are still some reasonable
> > ways to mitigate it.
> >
> > I've started revising the extension block specification/code to coexist
> > with mainchain segwit. I think the benefit of this is that we can
> > require exiting outputs to only be witness programs. Presumably segwit
> > wallets will be more likely to be aware of a new output maturity rule
> > (I've opened a PR[1] which describes this in greater detail). I think
> > this probably reduces the likelihood of the legacy wallet issue,
> > assuming most segwit-supporting wallets would implement this rule before
> > the activation of segwit.
> >
> > What's your opinion on whether this would have a great enough effect to
> > prevent the legacy wallet issue? I think switching to witness programs
> > only may be a good balance between fungibility and backward-compat,
> > probably better all around than creating a whole new
> > addr-type/wit-program just for exits.
> >
> > [1] https://github.com/tothemoon-org/extension-blocks/pull/16 
> > 
> >
>

--
Christopher Jeffrey (JJ) 
CTO & Bitcoin Menace, purse.io
https://github.com/chjj


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Network-layer attacks

[Eric Voskuil via bitcoin-dev]

-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 of encryption 
> to secure communications between nodes looks like low hanging
> fruit.

I draw a very different conclusion.

The paper states:

“Our work underscores the importance of proposed modifications which
argue for encrypting Bitcoin traffic or traffic exchanged among miners.”

The phrase, “encrypting ... traffic exchanged among miners,” is not
merely about encryption, since if one cannot identify the peer as the
intended miner it could just as well be an attacker. This is about
(presumably encrypted) authenticated connections.

Indeed, encryption of traffic among miners is referred to again here:

“Finally, an attacker cannot intercept (possibly encrypted) private
connections, corresponding to peering agreements between mining pools.
- From the attacker’s point of view, these connections can be treated as
intra-pool connections and the corresponding pair of pools can be
considered as one larger pool.”

So the encryption-based defense for miners is to use authentication to
create, “one larger pool,” consisting of, “private connections.”

Additionally it states, “we show that hijacking fewer than 100
prefixes is enough to isolate a large amount of the mining power due
to Bitcoin’s centralization.”

In other words the proposed solution, to what is largely a problem of
miner centralization, is to create one miner. The paper doesn’t
attempt to investigate the downside to that apparent centralization
spiral.

The paper investigates routing attacks on the p2p protocol,
specifically partitioning and delay. Regarding traffic encryption it
*stresses* the caution:

“Yet, we stress that not all routing attacks will be solved by such
measures since attackers can still disrupt connectivity and isolate
nodes by dropping Bitcoin packets instead of modifying them.”

In other words it recognizes that encryption is both centralizing and
ineffective. Along these lines it also observes:

* A smaller set of nodes will be easier to isolate for extended periods.
* All incoming connection slots can be occupied by connections from
attacker nodes.
* Outgoing connections can be biased via a traditional eclipse attack.

Notice that none of these issues are mitigated by encryption, since in
each case the encrypted connection may just as easily be the attacker.
The presumed powerful attacker (one with the ability to modify
Internet routing tables) is not deterred by encryption. Instead of
modifying or dropping packets he can simply redirect traffic to his
own node(s) and carry on the attack on an encrypted connection with
the victim. As such all calls for encryption in the P2P protocol
ultimately end in calls for authentication.

It is true that if all connections are authenticated these attacks are
mitigated. But as the “one larger pool” discussion shows, this is
simply a regression to a private network.

As for the two scenarios analyzed, the summary on delay attacks includes
:

* Delay attackers intercepting 50% of a node’s connection can waste
63% of its mining power.
* Due to pools multi-homing, Bitcoin (as a whole) is not vulnerable to
delay attackers, even powerful ones.
* Even a small degree of multi-homing is enough to protect Bitcoin
from powerful attackers.

Furthermore, the delay attack scenario explicitly relies on, “the fact
that a [Core] Bitcoin node waits for 20 minutes after having requested
a block from a peer before requesting it again from another peer.” The
waste of mining power above is a function of that delay. So delay is
not a material concern for the entire network, and there are
mitigations that hang much lower than making the network private.

Regarding partitioning, clearly neither encryption nor authentication
can ensure that one is seeing the strongest chain unless the network
is fully private (and trustworthy). The paper states, “Increase
partition persistence: ... Intuitively, the attacker needs to suppress
the effect of churn in order to keep the victim nodes isolated.” In
other words, simply rotating connections is presumed to be effective.

There are other useful countermeasures listed in the paper:

* Increase the diversity of node connections
* Select Bitcoin peers while taking routing into account
* Monitor round-trip time (RTT)
* Monitor additional statistics
* Embrace churn
* Use gateways in different ASes
* Prefer peers hosted in the same AS and in /24 prefixes
* Use distinct control and data channels
* Use UDP heartbeats
* Request a block on multiple connections

The single recommendation that includes encryption is heavily qualified:

* Encrypt Bitcoin Communication and/or adopt MAC
"While encrypting Bitcoin connections would not prevent adversaries
from dropping packets, it would prevent 

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

[Sergio Demian Lerner via bitcoin-dev]

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 PM, Gregory Maxwell  wrote:

> 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

[Gregory Maxwell via bitcoin-dev]

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

[Matt Corallo via 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 size (though have come around to caring a bit less
about that thanks to all the work in FIBRE and other similar systems
over the past year or two), but rapidly realized that just reducing the
Segwit discount wasn't really the right solution here.

You might as well take the real win and reduce the cost of the input
prevout itself so that average inputs are less expensive than outputs
(which SegWit doesn't quite achieve due to the large prevout size - 40
bytes). This way you can reduce the discount, still get the SegWit goal,
and get a lower ratio between worst-case and average-case block size,
though, frankly, I'm less interested in the last one these days, at
least for reasonable parameters. If you're gonna look at hard forks,
limiting yourself to just the parameters that we can tweak in a soft
fork seems short-sighted, at beast.

Matt

On 05/09/17 19:30, Gregory Maxwell wrote:
> 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 basically gutting the
> most of the gain from weight, making something incompatible, etc.
> 
> I'm not sure what to explain-- even that page on segwit.org explains
> that the values are selected to balance worst case costs not to
> optimize one to the total exclusion of others. Raw size is not very
> relevant in the long run, but if your goal were to optimize for it
> (which it seems to be), then the limit should be pure size.
> 
___
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

[Sergio Demian Lerner via bitcoin-dev]

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: (let WITNESS_SCALE_FACTOR=2)
n*2+n*1.7 = 4,000,000
n = 4,000,000/ 3.7 = 1.08M
Average block size = 1.08M*(1+1.7)=2.9 Mbytes
Maximum block size = 4 MBytes

The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
block size is the same.


On Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:

>
>>
>> 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 what a HF could do to optimize the balance, and I
> forgot I was in the context of a SF.
>
>
>
___
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

[Sergio Demian Lerner via bitcoin-dev]

>
>
>
> 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 what a HF could do to optimize the balance, and I
forgot I was in the context of a SF.
___
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

[Matt Corallo via bitcoin-dev]

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 analysis on worst-case vs
normal-case blocks also seems flawed - there is a single limit, and not
a separate, secondary, witness limit.

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. If you set the max block weight to 2.7 with a 1.7x
discount, you have a hard fork. If you set the discount to 2.7x with a
2.7 weight limit, you dont get 2.7MB average-sized blocks, but smaller,
and still have the potential for padding blocks with pure-witness data
to create larger blocks.

Additionally, note that by padding blocks with larger witness data you
lose some of the CPU cost to validate as you no longer have as many
inputs (which have a maximal validation cost).

Further, I'm not sure why you're arguing for a given witness discount on
the basis of a future hardfork - it seems highly unlikely the community
is in a position to pull something like that off, and even if it were,
why set the witness discount with that assumption? If there were to be a
hardfork, we should probably tweak a bunch of parameters (see, eg, my
post from February of last year at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html).

Maybe you could clarify your proposal a bit here, because the way I read
it you seem to have misunderstood SegWit's discount system.

On 05/09/17 13:49, Sergio Demian Lerner via bitcoin-dev wrote:
> 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 does not prevent it, but on the contrary leaves a lot
> of extra witness space for spam.
> 
> If the maximum block weight is set to 2.7M, each byte of non-witness
> block costs 1.7, and each byte of witness costs 1, then a normal filled
> block would be 2.7M bytes (1.7+1), and there will be no need to create
> ever a 4 Mbyte block. The worst case would be the average case, and the
> transaction rate would be the maximum possible.
> 
> The current 75% discount can only achieve more transactions per second
> if the type of transactions change. Therefore the current 75% discount
> only makes the block size worst case worse (4 Mbytes when it should be
> 2.7 Mbytes).
> 
> 80% of all inputs/outputs are P2PKH. The only way to make use of the
> extra witness 
> space If most P2PKH transactions are replaced by multisigs (typically
> for LN).
> 
> 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
> without a HF. 
> But it's a bad idea if we end up doing, for example, a 2X blocksize
> increase HF in the future. In that case it's much better to use a 50%
> witness discount, and do not make scaling risky by making the worse case
> block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> 
> I've uploaded the code here:
> https://github.com/SergioDemianLerner/SegwitStats
> 
>  [1] https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
> .
> 
> 
> On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev
>  > wrote:
> 
> 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 imply that those blocks, with SegWit used
> where possible, would result in blocks of ~1.8MB.
> 
> 
> 
> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev
>  > wrote:
> 
> 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 that other types of transactions will
> not be modified by Segwit (e.g. OP_RETURN outputs, 

Re: [bitcoin-dev] Network-layer attacks

[Greg Sanders via bitcoin-dev]

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 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
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Network-layer attacks

[Raystonn . via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Johnson Lau via bitcoin-dev]

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 
between the bitcoin and xbitcoin. Only services with high liquidity (exchanges, 
payment processors) would need to occasionally settle between the chains.


> On 9 May 2017, at 08:56, Christopher Jeffrey  wrote:
> 
> Johnson,
> 
> Yeah, I do still see the issue. I think there are still some reasonable
> ways to mitigate it.
> 
> I've started revising the extension block specification/code to coexist
> with mainchain segwit. I think the benefit of this is that we can
> require exiting outputs to only be witness programs. Presumably segwit
> wallets will be more likely to be aware of a new output maturity rule
> (I've opened a PR[1] which describes this in greater detail). I think
> this probably reduces the likelihood of the legacy wallet issue,
> assuming most segwit-supporting wallets would implement this rule before
> the activation of segwit.
> 
> What's your opinion on whether this would have a great enough effect to
> prevent the legacy wallet issue? I think switching to witness programs
> only may be a good balance between fungibility and backward-compat,
> probably better all around than creating a whole new
> addr-type/wit-program just for exits.
> 
> [1] https://github.com/tothemoon-org/extension-blocks/pull/16 
> 
> 

___
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

[James Hilliard via bitcoin-dev]

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 transactions/second in practice, the exact amount depends
on the real world usage of course though.

On Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> 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
> November, then for the next Segwit attempt I would choose a more
> conservative 50% discount.
>
>
>
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  wrote:
>>
>>
>> > 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 without a HF.
>> > But it's a bad idea if we end up doing, for example, a 2X blocksize
>> > increase HF in the future. In that case it's much better to use a 50%
>> > witness discount, and do not make scaling risky by making the worse case
>> > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>> >
>>
>> As we could change any parameter in a hardfork, I don’t think this has any
>> relation with the current BIP141 proposal. We could just use 75% in a
>> softfork, and change that to a different value (or completely redefine the
>> definition of weight) with a hardfork later.
>>
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
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

[Johnson Lau via bitcoin-dev]

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 2017, at 00:19, Sergio Demian Lerner  
> wrote:
> 
> 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 
> November, then for the next Segwit attempt I would choose a more conservative 
> 50% discount.
> 
> 
> 
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  > wrote:
> 
> > 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 without a 
> > HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize 
> > increase HF in the future. In that case it's much better to use a 50% 
> > witness discount, and do not make scaling risky by making the worse case 
> > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> >
> 
> As we could change any parameter in a hardfork, I don’t think this has any 
> relation with the current BIP141 proposal. We could just use 75% in a 
> softfork, and change that to a different value (or completely redefine the 
> definition of weight) with a hardfork later.
> 
> 
> 


___
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

[Sergio Demian Lerner via bitcoin-dev]

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
November, then for the next Segwit attempt I would choose a more
conservative 50% discount.



On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  wrote:

>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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 without a
> HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize
> increase HF in the future. In that case it's much better to use a 50%
> witness discount, and do not make scaling risky by making the worse case
> block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> >
>
> As we could change any parameter in a hardfork, I don’t think this has any
> relation with the current BIP141 proposal. We could just use 75% in a
> softfork, and change that to a different value (or completely redefine the
> definition of weight) with a hardfork later.
>
>
>
___
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

[Johnson Lau via bitcoin-dev]

> 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 without a HF. 
> But it's a bad idea if we end up doing, for example, a 2X blocksize increase 
> HF in the future. In that case it's much better to use a 50% witness 
> discount, and do not make scaling risky by making the worse case block size 8 
> Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> 

As we could change any parameter in a hardfork, I don’t think this has any 
relation with the current BIP141 proposal. We could just use 75% in a softfork, 
and change that to a different value (or completely redefine the definition of 
weight) with a hardfork later.


___
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

[James Hilliard via bitcoin-dev]

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 little impact on the UTXO size compared with 1MB
non-witness blocks. UTXO size is a bigger issue than blockchain size
since full nodes can't prune the UTXO set.

The discount of 75% for the SegWit softfork doesn't really have any
effect on future hard forks as it can always be adjusted as needed
later on as part of a HF.

On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> 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 does not prevent it, but on the contrary leaves a lot of
> extra witness space for spam.
>
> If the maximum block weight is set to 2.7M, each byte of non-witness block
> costs 1.7, and each byte of witness costs 1, then a normal filled block
> would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
> Mbyte block. The worst case would be the average case, and the transaction
> rate would be the maximum possible.
>
> The current 75% discount can only achieve more transactions per second if
> the type of transactions change. Therefore the current 75% discount only
> makes the block size worst case worse (4 Mbytes when it should be 2.7
> Mbytes).
>
> 80% of all inputs/outputs are P2PKH. The only way to make use of the extra
> witness
> space If most P2PKH transactions are replaced by multisigs (typically for
> LN).
>
> 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 without a HF.
> But it's a bad idea if we end up doing, for example, a 2X blocksize increase
> HF in the future. In that case it's much better to use a 50% witness
> discount, and do not make scaling risky by making the worse case block size
> 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>
> I've uploaded the code here:
> https://github.com/SergioDemianLerner/SegwitStats
>
>  [1]
> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>
>
> On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev
>  wrote:
>>
>> 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 imply that
>> those blocks, with SegWit used where possible, would result in blocks of
>> ~1.8MB.
>>
>>
>>
>> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev
>>  wrote:
>>>
>>> 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 that other types of transactions will not be
>>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>>> take into account that LN transactions may affect the current state,
>>> increasing the segwit/nosegwit ratio.
>>>
>>> Among a lot of information, I've got the following real world results...
>>>
>>> acMainChainSpace =352608924
>>> acSegwitSpace =599400403
>>> Ratio segwit/nosegwit=1.6999
>>>
>>> This implies that the 75% that discount is not the best option to prevent
>>> witness spam in a block of 4 MB, as stated in
>>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>>>
>>> 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.
>>>
>>> The Bitcoinj source code is available for anyone to review. I encourage
>>> anyone to re-compute this with another utility to cross-check. Maybe Antoine
>>> Le Calvez (p2sh.info) would like to double-check.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> ___
>> 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

[Sergio Demian Lerner via bitcoin-dev]

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 does not prevent it, but on the contrary leaves a lot of
extra witness space for spam.

If the maximum block weight is set to 2.7M, each byte of non-witness block
costs 1.7, and each byte of witness costs 1, then a normal filled block
would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
Mbyte block. The worst case would be the average case, and the transaction
rate would be the maximum possible.

The current 75% discount can only achieve more transactions per second if
the type of transactions change. Therefore the current 75% discount only
makes the block size worst case worse (4 Mbytes when it should be 2.7
Mbytes).

80% of all inputs/outputs are P2PKH. The only way to make use of the extra
witness
space If most P2PKH transactions are replaced by multisigs (typically for
LN).

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 without a
HF.
But it's a bad idea if we end up doing, for example, a 2X blocksize
increase HF in the future. In that case it's much better to use a 50%
witness discount, and do not make scaling risky by making the worse case
block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.

I've uploaded the code here:
https://github.com/SergioDemianLerner/SegwitStats

 [1] https://segwit.org/why-a-discount-factor-of-4-why-not-
2-or-8-bbcebe91721e.


On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 imply that
> those blocks, with SegWit used where possible, would result in blocks of
> ~1.8MB.
>
>
>
> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 that other types of transactions will not be
>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>> take into account that LN transactions may affect the current state,
>>  increasing the segwit/nosegwit ratio.
>>
>> Among a lot of information, I've got the following real world results...
>>
>> acMainChainSpace =352608924
>> acSegwitSpace =599400403
>> Ratio segwit/nosegwit=1.6999
>>
>> This implies that the 75% that discount is not the best option to prevent
>> witness spam in a block of 4 MB, as stated in
>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
>> .
>>
>> 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.
>>
>> The Bitcoinj source code is available for anyone to review. I encourage
>> anyone to re-compute this with another utility to cross-check. Maybe
>> Antoine Le Calvez (p2sh.info) would like to double-check.
>>
>>
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev