Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Mark Friedenbach via bitcoin-dev]

There are many reasons to support segwit beyond it being a soft-fork. For
example:

* the limitation of non-witness data to no more than 1MB makes the
quadratic scaling costs in large transaction validation no worse than they
currently are;
* redeem scripts in witness use a more accurate cost accounting than
non-witness data (further improvements to this beyond what Pieter has
implemented are possible); and
* segwit provides features (e.g. opt-in malleability protection) which are
required by higher-level scaling solutions.

With that in mind I really don't understand the viewpoint that it would be
better to engage a strictly inferior proposal such as a simple adjustment
of the block size to 2MB.

On Thu, Dec 17, 2015 at 1:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are at least 2 proposals on the table:
>
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
> equals to 2MB actual limit
>
> 2. BIP102: 2MB actual limit
>
> Since the actual limits for both proposals are approximately the same, it
> is not a determining factor in this discussion
>
> The biggest advantage of SWSF is its softfork nature. However, its
> complexity is not comparable with any previous softforks we had. It is
> reasonable to doubt if it could be ready in 6 months
>
> For BIP102, although it is a hardfork, it is a very simple one and could
> be deployed with ISM in less than a month. It is even simpler than BIP34,
> 66, and 65.
>
> So we have a very complicated softfork vs. a very simple hardfork. The
> only reason makes BIP102 not easy is the fact that it's a hardfork.
>
> The major criticism for a hardfork is requiring everyone to upgrade. Is
> that really a big problem?
>
> First of all, hardfork is not a totally unknown territory. BIP50 was a
> hardfork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was
> released on 18 March, which only gave 2 months of grace period for everyone
> to upgrade. The actual hardfork happened on 16 August. Everything completed
> in 5 months without any panic or chaos. This experience strongly suggests
> that 5 months is already safe for a simple hardfork. (in terms of
> simplicity, I believe BIP102 is even simpler than BIP50)
>
> Another experience is from BIP66. The 0.10.0 was released on 16 Feb 2015,
> exactly 10 months ago. I analyze the data on https://bitnodes.21.co and
> found that 4600 out of 5090 nodes (90.4%) indicate BIP66 support.
> Considering this is a softfork, I consider this as very good adoption
> already.
>
> With the evidence from BIP50 and BIP66, I believe a 5 months
> pre-announcement is good enough for BIP102. As the vast majority of miners
> have declared their support for a 2MB solution, the legacy 1MB fork will
> certainly be abandoned and no one will get robbed.
>
>
> My primary proposal:
>
> Now - 15 Jan 2016: formally consult the major miners and merchants if they
> support an one-off rise to 2MB. I consider approximately 80% of mining
> power and 80% of trading volume would be good enough
>
> 16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80%
> of hashing power
>
> 1 Jun 2016: the first day a 2MB block may be allowed
>
> Before 31 Dec 2016: release SWSF
>
>
>
> My secondary proposal:
>
> Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016
>
> 1 Jun 2016: release SWSF
>
> What if the deadline is not met? Maybe pushing an urgent BIP102 if things
> become really bad.
>
>
> In any case, I hope a clear decision and road map could be made now. This
> topic has been discussed to death. We are just bringing further uncertainty
> if we keep discussing.
>
>
> Matt Corallo via bitcoin-dev 於 2015-12-16 15:50 寫到:
>
>> A large part of your argument is that SW will take longer to deploy
>> than a hard fork, but I completely disagree. Though I do not agree
>> with some people claiming we can deploy SW significantly faster than a
>> hard fork, once the code is ready (probably a six month affair) we can
>> get it deployed very quickly. It's true the ecosystem may take some
>> time to upgrade, but I see that as a feature, not a bug - we can build
>> up some fee pressure with an immediate release valve available for
>> people to use if they want to pay fewer fees.
>>
>>  On the other hand, a hard fork, while simpler for the ecosystem to
>> upgrade to, is a 1-2 year affair (after the code is shipped, so at
>> least 1.5-2.5 from today if we all put off heads down and work). One
>> thing that has concerned me greatly through this whole debate is how
>> quickly people seem to think we can roll out a hard fork. Go look at
>> the distribution of node versions on the network today and work
>> backwards to get nearly every node upgraded... Even with a year
>> between fork-version-release and fork-activation, we'd still kill a
>> bunch of nodes and instead of reducing their security model, lead them
>> to be outright robbed.
>>
>>
> ___
>
> bitcoin

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Anthony Towns via bitcoin-dev]

On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote:
> There are at least 2 proposals on the table:
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
>equals to 2MB actual limit
> 2. BIP102: 2MB actual limit

I think there's a few variants of (2) -- there's "just 2MB", "2MB now,
4MB in a while, 8MB after that", "1MB for a while longer, then 2MB,
then 4MB" (halved from 2/4/8 since segwit gives 1.6x-2x benefit), and
variations of those with different dates, whether or not to smooth out
the increases to avoid economic shocks, and how to determine activation
(flag day? miner consensus? combination?).

> Since the actual limits for both proposals are approximately the same, it is
> not a determining factor in this discussion

That's true on the benefit side (both give about double the number of
ordinary transactions per block; though segregated witness has other
benefits). On the cost side, the limits are different:

 * worst case block data size is 2x for BIP102, 4x for segwit (affecting
   bandwidth, latency and storage costs for nodes)

 * worst case sigops is 2x for BIP102, but the same as today for segwit
   (affecting block validation time)

 * worst case bytes to hash a block is 4x for BIP102 (doubling block
   size and sigops), but the same as today for segwit (again affecting
   block validation time)

 * worst case UTXO bloat is 2x for BIP102, but the same as today for
   segwit (affecting memory usage, and validation time)

In the "expected" case (where people aren't attacking the blockchain)
I think they're the same on all these metrics. But increasing the
limits could easily make attacks more common, especially if it makes
them more effective.

I think the main attack vector of these is that increasing block
validation time via too many (active) sigops or too many bytes hashed
allows a selfish mining attack, but I'm not clear enough on how that
would work exactly to estimate where the boundary between acceptable and
unacceptable risk is (and how feasible non-consensus-level countermeasures
might be).

But at 1x sigops, you can already (accidently!) construct blocks that
take minutes to verify; and at 4x you can probably already construct a
block that takes 10 minutes to verify, which would probably be pretty
bad... But I'm not sure this isn't already exploitable, so maybe we're
already assuming a certain level of altruism and making things worse
doesn't actually make them worse?

I think it would be good for BIP102 or similar to include an evaluation
of that risk before being deployed [0].

> The major criticism for a hardfork is requiring everyone to upgrade. Is that
> really a big problem?

Yes. That doesn't mean it's not worth it, though.

(The 2-month timeline for the BIP50 accidental hardfork to be accepted
on the network seems persuasive to me that it's possible to roll out a
deliberate, SPV-compatible, hardfork on today's network in 3-6 months)

> My primary proposal:
> 1 Jun 2016: the first day a 2MB block may be allowed
> 
> My secondary proposal:
> 1 Jun 2016: release SWSF

I think it makes sense to just do both of these independently; ie:

 * release segwit via softfork ASAP (perhaps targetting March or April
   to get it included in bitcoin, activation a month or three
   afterwards?), with virtual block size calculated as proposed and
   capped by MAX_BLOCK_SIZE [1]

 * increase MAX_BLOCK_SIZE via hardfork to 2MB after block 420,000
   (phased in gradually? with future scheduled increases to 4MB or 8MB?)

If segwit gets delayed because it's complicated, that's okay; if
it comes out earlier, that's okay too. If the hardfork gets delayed
because miners aren't ready or because it's better to introduce it in a
staggered fashion, or because there's no clear evaluation of the risks,
that's okay too.

But more importantly, it allows evaluate the pros and cons of each
implementation separately and on its own merits, rather than arguing
against working on one just because you're in favour of doing the
other ASAP.


They have benefits if you combine them too; for instance, if the
MAX_BLOCK_SIZE increase is phased in rather than done as a step increase
(ie block x's limit is 1MB, block x+1's limit is 1.005MB or similar,
and block x+2's limit is 1.01MB, etc) having segwit available in parallel
could provide a helpful escape valve: if an individual bitcoin user has
been dying for more capacity, they can spend the time/effort to update
their software for segwit and get it immediately without having to wait
as the consensus limits rise.

Conversely, having both segwit and a phased increase to MAX_BLOCK_SIZE
means that miners generally won't be immediately mining 2MB (or 4MB)
blocks halfway through the year, which should avoid both technological
shocks (bandwidth just doubled!) or economic shocks (supply has increased
so fees have plummeted), which could be good.


FWIW, the worst case scenarios are:

 * block data size:
 BIP102:  2x   (worst/avg)

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Marcel Jamin via bitcoin-dev]

Maybe we should first gather concrete estimates about and roughly agree on

- how long SW (SF) development will probably take

- how long the ecosystem needs to prepare for a hardfork (SW (HF) or a
simple can kicking block size increase)

Opinions differ wildly from what it looks like, but maybe we can get to
estimates that the majority here can accept.

---

Personally, I think that the disclaimer "Bitcoin is an experiment" is
pervasive. It's still a pre-release, even with a $6bn vote of confidence.
If you don't follow developments in this phase, don't upgrade and then have
an elevated risk of losing money by getting scammed, then that's a little
bit your fault. I'd absolutely support a change in mentality on that once
1.0.0 arrives, but until then is bitcoin a work-in-progress experiment and
a high risk investment.

A planned hard-fork is an experiment that needs to be run anyway. When do
we want to do that, if not now?


2015-12-16 21:50 GMT+01:00 Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
> On December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> 1. Summary
>>
>> Segregated Witness (SegWitness, SW) is being presented in the context of
>> Scaling Bitcoin.  It has useful attributes, notably addressing a major
>> malleability vector, but is not a short term scaling solution.
>>
>>
>> 2. Definitions
>>
>> Import Fee Event, ECE, TFM, FFM from previous email.
>>
>> Older clients - Any software not upgraded to SW
>>
>> Newer clients - Upgraded, SW aware software
>>
>>
>> Block size - refers to the core block economic resource limit ed by
>> MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.
>> Requires a hard fork to change.
>>
>> Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not
>> changed by SW.
>>
>>
>> Extended transaction - Newer, upgraded version of transaction data format.
>>
>> Extended block - Newer, upgraded version of block data format.
>>
>>
>> EBS - Extended block size.  Block size seen by newer clients.
>>
>>
>> 3. Context of analysis
>>
>> One proposal presents SW *in lieu of* a hard fork block size increase.
>> This email focuses directly on that.
>>
>> Useful features outside block size context, such as anti-malleability or
>> fraud proof features, are not covered in depth.
>>
>>
>> 4.1.  Observations on data structure formats and views
>>
>> SW creates two *views* of each transaction and block.  SW has blocks and
>> extended blocks.  Similarly, there exists transactions and extended
>> transactions.
>>
>> This view is rendered to clients depending on compatibility level.  Newer
>> clients see extended blocks and extended transactions.  Older clients see
>> blocks (limit 1M), and do not see extended blocks.  Older clients see
>> upgraded transactions as unsigned, anyone-can-pay transactions.
>>
>> Each extended transaction exists in two states, one unsigned and one
>> signed, each of which passes validation as a valid bitcoin transaction.
>>
>>
>> 4.2.  Observations on behavior of older transaction creation
>>
>> Transactions created by older clients will not use the extended
>> transaction format.  All data is stored the standard 1M block as today.
>>
>>
>> 4.3.  Observations on new block economic model
>>
>> SW complicates block economics by creating two separate, supply limited
>> resources.
>>
>> The core block economic resource is heavily contended.  Older clients use
>> core blocks exclusively.  Newer clients use core block s more
>> conservatively, storing as much data as possible in extended blocks.
>>
>> The extended block economic resource is less heavily contended, though
>> that of course grows over time as clients upgrade.
>>
>> Because core blocks are more heavily con

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[jl2012 via bitcoin-dev]

I know my reply is a long one but please read before you hit send. I 
have 2 proposals: fast BIP102 + slow SWSF and fast SWSF only. I guess no 
one here is arguing for not doing segwit; and it is on the top of my 
wish list. My main argument (maybe also Jeff's) is that segwit is too 
complicated and may not be a viable short term solution (with the 
reasons I listed that I don't want to repeat)


And also I don't agree with you that BIP102 is *strictly* inferior than 
segwit. We never had a complex softfork like segwit, but we did have a 
successful simple hardfork (BIP50), and BIP102 is very simple. (Details 
in my last post. I'm not going to repeat)


Mark Friedenbach 於 2015-12-17 04:33 寫到:

There are many reasons to support segwit beyond it being a soft-fork.
For example:

* the limitation of non-witness data to no more than 1MB makes the
quadratic scaling costs in large transaction validation no worse than
they currently are;
* redeem scripts in witness use a more accurate cost accounting than
non-witness data (further improvements to this beyond what Pieter has
implemented are possible); and
* segwit provides features (e.g. opt-in malleability protection) which
are required by higher-level scaling solutions.

With that in mind I really don't understand the viewpoint that it
would be better to engage a strictly inferior proposal such as a
simple adjustment of the block size to 2MB.


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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jameson Lopp via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik  wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> >
> > This circles back to Problem #1:   Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3:  If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>

Indeed, because I sometimes find these statements to be confusing as well -
I can completely understand what you mean if you're speaking from a moral
standpoint. If you're saying that it's unacceptable for the Bitcoin Core
developers to force consensus changes upon the system, I agree. But
thankfully the design of the system does not allow the developers to do so.
Developers can commit amazing code or terrible code, but it must be
voluntarily adopted by the rest of the ecosystem. Core developers can't
decide these changes, they merely propose them to the ecosystem by writing
and releasing code.

I agree that Core developers have no authority to make these decisions on
behalf of all of the network participants. However, they are in a position
of authority when it comes to proposing changes. One of my takeaways from
Hong Kong was that most miners have little interest in taking
responsibility for consensus changes - they trust the Core developers to
use their expertise to propose changes that will result in the continued
operation of the network and not endanger their business operations.

A non-trivial portion of the ecosystem is requesting that the Core
developers make a proposal so that the network participants can make a
choice. Jeff noted that we can expect for the economic conditions of the
network to change significantly in 2016, barring higher throughput
capacity. If the year+ deployment timeframe for hard forks proposed by Matt
on another thread is what we can expect for any proposed consensus change,
then it should be non-contentious to announce that there will be no hard
fork in 2016. This will give clarity to the rest of the ecosystem as to how
they should prepare.


> --
> Pieter
> ___
> 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] Segregated Witness in the context of Scaling Bitcoin

[Jameson Lopp via bitcoin-dev]

On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
>
Over a year seems to be an extraordinarily long time frame is for deploying
a hard fork. It looks like  75%
of reachable nodes have upgraded in the past 6 months while as much as 25%
may not have been upgraded in over a year. However, viewing historical
stats of version upgrades doesn't seem to be an appropriate comparison
because node operators have never been faced with the same incentive to
upgrade. We can point to unintentional forks in the past that have been
resolved fairly quickly by reaching out to miners, but it's also a poor
comparison. Unfortunately, we have no way of knowing what percentage of
nodes are economically important - a great deal of them may be running and
not even be used by the operators.

Perhaps it would be better if we were to formalize the expectations for
full node operators, but it seems to me that node operators have a
responsibility to keep themselves informed and decide when it is
appropriate to update their software. I'm not so sure that it's the rest of
the ecosystem's responsibility to wait around for laggards.

- Jameson

On December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> 1. Summary
>>
>> Segregated Witness (SegWitness, SW) is being presented in the context of
>> Scaling Bitcoin.  It has useful attributes, notably addressing a major
>> malleability vector, but is not a short term scaling solution.
>>
>>
>> 2. Definitions
>>
>> Import Fee Event, ECE, TFM, FFM from previous email.
>>
>> Older clients - Any software not upgraded to SW
>>
>> Newer clients - Upgraded, SW aware software
>>
>>
>> Block size - refers to the core block economic resource limit ed by
>> MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.
>> Requires a hard fork to change.
>>
>> Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not
>> changed by SW.
>>
>>
>> Extended transaction - Newer, upgraded version of transaction data format.
>>
>> Extended block - Newer, upgraded version of block data format.
>>
>>
>> EBS - Extended block size.  Block size seen by newer clients.
>>
>>
>> 3. Context of analysis
>>
>> One proposal presents SW *in lieu of* a hard fork block size increase.
>> This email focuses directly on that.
>>
>> Useful features outside block size context, such as anti-malleability or
>> fraud proof features, are not covered in depth.
>>
>>
>> 4.1.  Observations on data structure formats and views
>>
>> SW creates two *views* of each transaction and block.  SW has blocks and
>> extended blocks.  Similarly, there exists transactions and extended
>> transactions.
>>
>> This view is rendered to clients depending on compatibility level.  Newer
>> clients see extended blocks and extended transactions.  Older clients see
>> blocks (limit 1M), and do not see extended blocks.  Older clients see
>> upgraded transactions as unsigned, anyone-can-pay transactions.
>>
>> Each extended transaction exists in two states, one unsigned and one
>> signed, each of which passes validation as a valid bitcoin transaction.
>>
>>
>> 4.2.  Observations on behavior of older transaction creation
>>
>> Transactions created by older clients will not use the extended
>> transaction format.  All data is stored the standard 1M block as today.
>>
>>
>> 4.3.  Observations on new block economic model
>>
>> SW complicates block economics by creating two separate, supply limited
>> resources.
>>
>> The core block economic resource is heavily contended.  Older clients use
>> core blocks exclusively.  Newer clients use core block s more
>> conservatively, storing as much data as possible in

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Corey Haddad via bitcoin-dev]

A planned hardfork, similar to certain softforks, leaves users with some
reduction in security.  It does not leave them defenseless.  Consider the
following:

1: Hard to be robbed on the basis of hashpower.

In reality the old chain will see mining all but stop, and blocks would be
hours to days apart even if a couple percentage points of hashpower failed
to switch over.  Six confirmations would certainly take days.  If the fork
can be scheduled at the beginning of a difficulty period, the old chain
would almost certainly not even ever make it to the next retargeting.

2: Hard to be robber on the basis of awareness.

Expect there to be fairly widespread coverage in the Bitcoin press, and as
the fork draws near, maybe coverage in business and tech publications.
Further, the alert keys will certainly be used, so node operators will get
the message directly.

3: There still needs to be a targeted attack by a fraudster on an unaware
node operator.

To fall victim, one needs to give up something of value to an attacker in
exchange for Bitcoins (on the old chain).  The typical uninitiated
full-node user (probably a small subset anyway) is typically going to be
buying bitcoin from a trusted source, and then saving or spending them, or
perhaps gambling.  They are not, typically, going to be providing a service
or selling goods in exchange for Bitcoin unless they are at least somewhat
aware of what is going on in the Bitcoin space.  It's possible, of course,
but we are talking about small numbers here of people who fit the above.

All three parts of the above would have to go perfectly wrong for someone
to loose out.  Someone somewhere will probably get scammed as a result of a
hardfork.  That stinks, and we should make reasonable efforts to help them
avoid that fate.  But at this point in Bitcoin's development, it is still
in beta, it's still an economic experiment, and we can't allow the software
to become hamstrung out of fear that some inattentive user might bungle
their security.  If they merely waited for 6 confirmations, as is the
standard advice, they would be waiting for days.  If that along doesn't
give them a hint that something is wrong, it might still be too early days
for them to be playing with Bitcoin for anything important.

I support a hardfork deployment that takes 80% of hashpower activate + a
4-month delay.

On Wed, Dec 16, 2015 at 9:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are at least 2 proposals on the table:
>
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
> equals to 2MB actual limit
>
> 2. BIP102: 2MB actual limit
>
> Since the actual limits for both proposals are approximately the same, it
> is not a determining factor in this discussion
>
> The biggest advantage of SWSF is its softfork nature. However, its
> complexity is not comparable with any previous softforks we had. It is
> reasonable to doubt if it could be ready in 6 months
>
> For BIP102, although it is a hardfork, it is a very simple one and could
> be deployed with ISM in less than a month. It is even simpler than BIP34,
> 66, and 65.
>
> So we have a very complicated softfork vs. a very simple hardfork. The
> only reason makes BIP102 not easy is the fact that it's a hardfork.
>
> The major criticism for a hardfork is requiring everyone to upgrade. Is
> that really a big problem?
>
> First of all, hardfork is not a totally unknown territory. BIP50 was a
> hardfork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was
> released on 18 March, which only gave 2 months of grace period for everyone
> to upgrade. The actual hardfork happened on 16 August. Everything completed
> in 5 months without any panic or chaos. This experience strongly suggests
> that 5 months is already safe for a simple hardfork. (in terms of
> simplicity, I believe BIP102 is even simpler than BIP50)
>
> Another experience is from BIP66. The 0.10.0 was released on 16 Feb 2015,
> exactly 10 months ago. I analyze the data on https://bitnodes.21.co and
> found that 4600 out of 5090 nodes (90.4%) indicate BIP66 support.
> Considering this is a softfork, I consider this as very good adoption
> already.
>
> With the evidence from BIP50 and BIP66, I believe a 5 months
> pre-announcement is good enough for BIP102. As the vast majority of miners
> have declared their support for a 2MB solution, the legacy 1MB fork will
> certainly be abandoned and no one will get robbed.
>
>
> My primary proposal:
>
> Now - 15 Jan 2016: formally consult the major miners and merchants if they
> support an one-off rise to 2MB. I consider approximately 80% of mining
> power and 80% of trading volume would be good enough
>
> 16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80%
> of hashing power
>
> 1 Jun 2016: the first day a 2MB block may be allowed
>
> Before 31 Dec 2016: release SWSF
>
>
>
> My secondary proposal:
>
> Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016
>

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jorge Timón via bitcoin-dev]

Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.

BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?

1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation

2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.

Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).

Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[sickpig--- via bitcoin-dev]

On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> equivalent to the 2-4-8 "compromise" proposal (which by the way I never
> liked, because I don't think anybody should be in a position to
> "compromise" anything and because I don't see how "let's avoid an
> unavoidable economic change for a little bit longer" arguments can
> reasoably claim that "we need to kick the can down the road exactly 3 more
> times" or whatever is the reasoning behind it).
>

isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5.

4x is theoric gain you get in case of 2-2 multisig txs.

am I missign something obvious?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Tier Nolan via bitcoin-dev]

On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We are not avoiding a choice. We don't have the authority to make a choice.
>

This is really the most important question.

Bitcoin is kind of like a republic where there is separation of powers
between various groups.

The power blocs in the process include

- Core Devs
- Miners
- Exchanges
- Merchants
- Customers

Complete agreement is not required for a change.  If merchants and their
customers were to switch to different software, then there is little any of
the other groups could do.

Consensus is nice, certainly, and it is a good social norm to seek
widespread agreement before committing to a decision above objection.
Committing to no block increase is also committing to a decision against
objections.

Having said that, each of the groups are not equal in power and
organisation.

Merchants and their customers have potentially a large amount of power, but
they are disorganised.  There is little way for them to formally express a
view, much less put their power behind making a change.  Their potential
power is crippled by public action problems.

On the other extreme is the core devs. Their power is based on legitimacy
due to having a line of succession starting with Satoshi and respect gained
due to technical and political competence.  Being a small group, they are
organised and they are also more directly involved.

The miners are less centralised, but statements supported by the majority
of the hashing power are regularly made.  The miners' position is that they
want dev consensus.  This means that they have delegated their decision
making to the core devs.

The means that the two most powerful groups in Bitcoin have given the core
devs the authority to make the decision.  They don't have carte blanche
from the miners.

If the core devs made the 2MB hard-fork with a 75% miner threshold, it is
highly likely that the other groups would accept it.

That is the only authority that exists in Bitcoin.  The check is that if
the authority is abused, the other groups can simply leave (or use
checkpointing)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Anthony Towns via bitcoin-dev]

On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote:
> On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
> > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> > equivalent to the 2-4-8 "compromise" proposal [...]
> isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5.

Segwit as proposed gives a 75% *discount* to witness data with the
same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up
of 650kB of base block data plus 1.4MB of witness data; where 650kB +
1.4MB/4 = 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus
2.8MB of witness, for 1.3MB+2.8MB/4 = 2MB at a 2MB limit.

> 4x is theoric gain you get in case of 2-2 multisig txs.

With segregated witness, 2-2 multisig transactions are made up of 94B
of base data, plus about 214B of witness data; discounting the witness
data by 75% gives 94+214/4=148 bytes. That compares to about 301B for
a 2-2 multisig transaction with P2SH rather than segwit, and 301/148
gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed
to get the numbers above.

You get further improvements with, eg, 3-of-3 multisig, but to get
the full, theoretical 4x gain you'd need a fairly degenerate looking
transaction.

Pay to public key hash with segwit lets you move about half the
transaction data into the witness, giving about a 1.6x improvement by
my count (eg 1.6MB = 800kB of base data plus 800kB of witness data,
where 800kB+800kB/4=1MB), so I think a gain of between 1.6 and 2.0 is
a reasonable expectation to have for the proposed segwit scheme overall.

Cheers,
aj

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik  wrote:

> SW presents a blended price and blended basket of two goods.  You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
> A different set of economic actors uses one resource, and/or both.  There
> are explicit incentives to shift actors from solely using one resource to
> using both.
>

Illustration:  If SW is deployed via soft fork, the count of nodes that
validate witness data is significantly lower than the count of nodes that
validate non-witness data.  Soft forks are not trustless operation, they
depend on miner trust, slowly eroding the trustless validation of older
nodes over time.

Higher security in one data area versus another produces another economic
value distinction between the two goods in the basket, and creates a "pay
more for higher security in core block, pay less for lower security in
witness" dynamic.

This economic distinction is not present if SW is deployed via hard fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Thu, Dec 17, 2015 at 1:46 PM, jl2012  wrote:

> This is not correct.
>
> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
> are less secure than others? I don't think so. Since one invalid CLTV tx
> will make the whole block invalid. Having more nodes to fully validate
> non-CLTV txs won't make them any safer. The same logic also applies to SW
> softfork.
>


Yes - the logic applies to all soft forks.  Each soft fork degrades the
security of non-upgraded nodes.

The core design of bitcoin is that trustless nodes validate the work of
miners, not trust them.

Soft forks move in the opposite direction.  Each new soft-forked feature
leans very heavily on miner trust rather than P2P network validation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[jl2012 via bitcoin-dev]

This is not correct.

As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx 
are less secure than others? I don't think so. Since one invalid CLTV tx 
will make the whole block invalid. Having more nodes to fully validate 
non-CLTV txs won't make them any safer. The same logic also applies to 
SW softfork.


You may argue that a softfork would make the network as a whole less 
secure, as old nodes have to trust new nodes. However, the security of 
all content in the same block must be the same, by definition.


Anyway, I support SW softfork at the beginning, and eventually (~2 
years) moving to a hardfork with higher block size limit and better 
commitment structure.


Jeff Garzik via bitcoin-dev 於 2015-12-17 13:27 寫到:



Illustration:  If SW is deployed via soft fork, the count of nodes
that validate witness data is significantly lower than the count of
nodes that validate non-witness data.  Soft forks are not trustless
operation, they depend on miner trust, slowly eroding the trustless
validation of older nodes over time.

Higher security in one data area versus another produces another
economic value distinction between the two goods in the basket, and
creates a "pay more for higher security in core block, pay less for
lower security in witness" dynamic.

This economic distinction is not present if SW is deployed via hard
fork.


___
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] Block size: It's economics & user preparation & moral hazard

[Peter Todd via bitcoin-dev]

On Thu, Dec 17, 2015 at 04:58:02PM +, Tier Nolan via bitcoin-dev wrote:
> This is really the most important question.
> 
> Bitcoin is kind of like a republic where there is separation of powers
> between various groups.
> 
> The power blocs in the process include
> 
> - Core Devs
> - Miners
> - Exchanges
> - Merchants
> - Customers
> 
> Complete agreement is not required for a change.  If merchants and their
> customers were to switch to different software, then there is little any of
> the other groups could do.

If Bitcoin remains decentralized, miners have veto power over any
blocksize increases. You can always soft-fork in a blocksize reduction
in a decentralized blockchain that actually works.

-- 
'peter'[:-1]@petertodd.org
01bd68962863e6fa34e9776df361d4926912f52fc5f4b618


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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Eric Lombrozo via bitcoin-dev]

Doesn't a good soft fork signaling mechanism along with an activation warning 
system for non-upgraded nodes (i.e. BIP9, or even block version ISM for that 
matter) essentially fix this? I don't quite get why this should be an issue.

On December 17, 2015 10:52:39 AM PST, Jeff Garzik via bitcoin-dev 
 wrote:
>On Thu, Dec 17, 2015 at 1:46 PM, jl2012  wrote:
>
>> This is not correct.
>>
>> As only about 1/3 of nodes support BIP65 now, would you consider CLTV
>tx
>> are less secure than others? I don't think so. Since one invalid CLTV
>tx
>> will make the whole block invalid. Having more nodes to fully
>validate
>> non-CLTV txs won't make them any safer. The same logic also applies
>to SW
>> softfork.
>>
>
>
>Yes - the logic applies to all soft forks.  Each soft fork degrades the
>security of non-upgraded nodes.
>
>The core design of bitcoin is that trustless nodes validate the work of
>miners, not trust them.
>
>Soft forks move in the opposite direction.  Each new soft-forked
>feature
>leans very heavily on miner trust rather than P2P network validation.
>
>
>
>
>___
>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] Segregated Witness in the context of Scaling Bitcoin

[Adam Back via bitcoin-dev]

While it is interesting to contemplate moving to a world with
hard-fork only upgrades (deprecate soft-forks), now is possibly not
the time to consider that.  Someone can take that topic and make a
what-if sketch for how it could work and put it on the wishlist wiki
if its not already there.

We want to be pragmatic and constructive to reach consensus and that
takes not mixing in what-ifs or orthogonal long standing problems into
the mix, as needing to be fixed now.

Adam


On 17 December 2015 at 19:52, Jeff Garzik via bitcoin-dev
 wrote:
>
>
> On Thu, Dec 17, 2015 at 1:46 PM, jl2012  wrote:
>>
>> This is not correct.
>>
>> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
>> are less secure than others? I don't think so. Since one invalid CLTV tx
>> will make the whole block invalid. Having more nodes to fully validate
>> non-CLTV txs won't make them any safer. The same logic also applies to SW
>> softfork.
>
>
>
> Yes - the logic applies to all soft forks.  Each soft fork degrades the
> security of non-upgraded nodes.
>
> The core design of bitcoin is that trustless nodes validate the work of
> miners, not trust them.
>
> Soft forks move in the opposite direction.  Each new soft-forked feature
> leans very heavily on miner trust rather than P2P network validation.
>
>
> ___
> 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] On the security of softforks

[Pieter Wuille via bitcoin-dev]

Hello all,

For a long time, I was personally of the opinion that soft forks
constituted a mild security reduction for old full nodes, albeit one
that was preferable to hard forks due to being far less risky, easier,
and less forceful to deploy.

After thinking more about this, I'm not convinced that it is even that anymore.

Let's analyze all failure modes (and feel free to let me know whether
I've missed any specific ones):

1) The risk of an old full node wallet accepting a transaction that is
invalid to the new rules.

The receiver wallet chooses what address/script to accept coins on.
They'll upgrade to the new softfork rules before creating an address
that depends on the softfork's features.

So, not a problem.

2) The risk of an old full node wallet accepting a transaction whose
coins passed through a script that depends on the softforked rules.

It is reasonable that the receiver of a transaction places some trust
in the sender, and on the basis of that, decides to reduce the number
of confirmations before acceptance. In case the transaction indirectly
depends on a low-confirmation transaction using softforked rules, it
may be treated as an anyone-can-spend transaction. Obviously, no trust
can be placed in such a transactions not being reorged out and
replaced with an incompatible one.

However, this problem is common for all anyonecanspend transactions,
which are perfectly legal today in the blockchain. So, if this is a
worry, we can solve it by marking incoming transactions as "uncertain
history" in the wallet if they have an anyonecanspend transaction with
less than 6 confirmations in its history. In fact, the same problem to
a lesser extent exists if coins pass through a 1-of-N multisig or so,
because you're not only trusting the (indirect) senders, but also
their potential cosigners.

3) The risk of an SPV node wallet accepting an unconfirmed transaction
which is invalid to new nodes.

Defrauding an SPV wallet with an invalid unconfirmed transaction
doesn't change with the introduction of new consensus rules, as they
don't validate them anyway.

In the case the client trusts the full node peer(s) it is connected to
to do validation before relay, nodes can either indicate (service bit
or new p2p message) which softforks are accepted (as it only matters
to SPV wallets that wish to accept transactions using new style script
anyway), or wallets can rely on the new rules being non-standard even
to old full nodes (which is typically aimed for in softforks).

4) The risk of an SPV node wallet accepting a confirmed transaction
which is invalid to new nodes

Miners can of course construct an invalid block purely for defrauding
SPV nodes, without intending to get that block accepted by full nodes.
That is expensive (no subsidy/fee income for those blocks) and more
importantly it isn't in any way affected by softforks.

So the only place where this matters is where miners create a block
chain that violates the new rules, and still get it accepted. This
requires a hash rate majority, and sufficiently few economically
important full nodes that forking them off is a viable approach.

It's interesting that even though it requires forking off full nodes
(who will notice, there will be an invalid majority hash rate chain to
them), the attack only allows defrauding SPV nodes. It can't be used
to bypass any of the economic properties of the system (as subsidy and
other resource limits are still enforced by old nodes, and invalid
scripts will either not be accepted by old full nodes wallets, or are
as vulnerable as unrelated anyonecanspends).

Furthermore, it's easily preventable by not using the feature in SPV
wallets until a sufficient amount of economically relevant full nodes
are known to have upgraded, or by just waiting for enough
confirmations.



So, we'd of course prefer to have all full nodes enforce all rules,
but the security reduction is not large. On the other hand, there are
also security advantages that softforks offer:

A) Softforks do not require the pervasive consensus that hardforks
need. Soft forks can be deployed without knowing when all full nodes
will adopt the rule, or even whether they will ever adopt it at all.

B) Keeping up with hard forking changes puts load on full node
operators, who may choose to instead switch to delegating full
validation to third parties, which is worse than just validating the
old rules.

C) Hardfork coordination has a centralizing effect on development. As
hardforks can only be deployed with sufficient node deployment, they
can't just be triggered by miner votes. This requires central
coordination to determine flag times, which is incompatible with
having multiple independent consensus changes being proposed. For
softforks, something like BIP9 supports having multiple independent
softforks in flight, that nodes can individually chose to accept or
not, only requiring coordination to not choose clashing bit numbers.
For hardforks, there is effectively no choice

Re: [bitcoin-dev] On the security of softforks

[Jonathan Toomim via bitcoin-dev]

On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
 wrote:

> 1) The risk of an old full node wallet accepting a transaction that is
> invalid to the new rules.
> 
> The receiver wallet chooses what address/script to accept coins on.
> They'll upgrade to the new softfork rules before creating an address
> that depends on the softfork's features.
> 
> So, not a problem.


Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob runs the 
old rules. Bob creates a p2pkh address for Mallory to use. Mallory takes 1 BTC, 
and creates an invalid SegWit transaction that Bob cannot properly validate and 
that pays into one of Mallory's wallets. Mallory then immediately spends the 
unconfirmed transaction into Bob's address. Bob sees what appears to be a valid 
transaction chain which is not actually valid.

Clueless Carol is one of the 4.9% of miners who forgot to upgrade her mining 
node. Carol sees that Mallory included an enormous fee in his transactions, so 
Carol makes sure to include both transactions in her block.

Mallory gets free beer.

Anything I'm missing?


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Eric Lombrozo via bitcoin-dev]

First of all, that's an expensive beer!

Second of all, any consensus rule change risks non-full-validating or 
non-upgraded nodes seeing invalid confirmations...but assuming a large 
supermajority (i.e. > 95%) of hashing power is behind the new rule, it 
is extremely unlikely that very many invalid confirmations will ever be 
seen by anyone. The number of confirmations you require depends on your 
use case security requirements...and especially during a new rule 
activation, it is probably not a good idea for non-validating nodes or 
non-upgraded nodes to accept coins with low confirmation counts unless 
the risk is accounted for in the use case (i.e. a web hosting provider 
that can shut the user out if fraud is later detected).


Third of all, as long as the rule change activation is signaled in 
blocks, even old nodes will be able to detect that something is fishy 
and warn users to be more cautious (i.e. wait more confirmations or 
immediately upgrade or connect to a different node that has upgraded, 
etc...)


I honestly don't see an issue here - unless you're already violating 
fundamental security assumptions that would make you vulnerable to 
exploitation even without rule changes.


- Eric

-- Original Message --
From: "Jonathan Toomim via bitcoin-dev" 


To: "Pieter Wuille" 
Cc: "Bitcoin Dev" 
Sent: 12/17/2015 6:47:14 PM
Subject: Re: [bitcoin-dev] On the security of softforks



On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
 wrote:



1) The risk of an old full node wallet accepting a transaction that is
invalid to the new rules.

The receiver wallet chooses what address/script to accept coins on.
They'll upgrade to the new softfork rules before creating an address
that depends on the softfork's features.

So, not a problem.


Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob 
runs the old rules. Bob creates a p2pkh address for Mallory to use. 
Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob 
cannot properly validate and that pays into one of Mallory's wallets. 
Mallory then immediately spends the unconfirmed transaction into Bob's 
address. Bob sees what appears to be a valid transaction chain which is 
not actually valid.


Clueless Carol is one of the 4.9% of miners who forgot to upgrade her 
mining node. Carol sees that Mallory included an enormous fee in his 
transactions, so Carol makes sure to include both transactions in her 
block.


Mallory gets free beer.

Anything I'm missing?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[jl2012 via bitcoin-dev]

Jonathan Toomim via bitcoin-dev 於 2015-12-17 21:47 寫到:

Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
runs the old rules. Bob creates a p2pkh address for Mallory to use.
Mallory takes 1 BTC, and creates an invalid SegWit transaction that
Bob cannot properly validate and that pays into one of Mallory's
wallets. Mallory then immediately spends the unconfirmed transaction
into Bob's address. Bob sees what appears to be a valid transaction
chain which is not actually valid.

Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
mining node. Carol sees that Mallory included an enormous fee in his
transactions, so Carol makes sure to include both transactions in her
block.

Mallory gets free beer.

Anything I'm missing?


You miss the fact that 0-conf is not safe, neither 1-conf. What you are 
suggesting is just a variation of Finney attack.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille 
wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>  wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.




> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>

Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.

1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.

2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.

There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption.  Users of the Service can still drift randomly
and unpredictably into a Fee Event.

SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear

Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.

As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jorge Timón via bitcoin-dev]

On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
 wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.

You can always schism hardfork miners out...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Jorge Timón via bitcoin-dev]

To me it's getting clearer and clearer that th frintier between
softforks and hardforks it's softer than we thought.
Aoftforks should start having a minimum median time deplayment day (be
it height or median time, I don't care, just not header.nTime).
TYDGFHdfthfg64565$%^$

On Fri, Dec 18, 2015 at 4:10 AM, jl2012 via bitcoin-dev
 wrote:
> Jonathan Toomim via bitcoin-dev 於 2015-12-17 21:47 寫到:
>>
>> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
>> runs the old rules. Bob creates a p2pkh address for Mallory to use.
>> Mallory takes 1 BTC, and creates an invalid SegWit transaction that
>> Bob cannot properly validate and that pays into one of Mallory's
>> wallets. Mallory then immediately spends the unconfirmed transaction
>> into Bob's address. Bob sees what appears to be a valid transaction
>> chain which is not actually valid.
>>
>> Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
>> mining node. Carol sees that Mallory included an enormous fee in his
>> transactions, so Carol makes sure to include both transactions in her
>> block.
>>
>> Mallory gets free beer.
>>
>> Anything I'm missing?
>
>
> You miss the fact that 0-conf is not safe, neither 1-conf. What you are
> suggesting is just a variation of Finney attack.
>
> ___
> 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] On the security of softforks

[Anthony Towns via bitcoin-dev]

On Fri, Dec 18, 2015 at 10:47:14AM +0800, Jonathan Toomim via bitcoin-dev wrote:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
>  wrote:
> > 1) The risk of an old full node wallet accepting a transaction that is
> > invalid to the new rules.
> > The receiver wallet chooses what address/script to accept coins on.
> > They'll upgrade to the new softfork rules before creating an address
> > that depends on the softfork's features.
> > So, not a problem.
> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
> runs the old rules. Bob creates a p2pkh address for Mallory to
> use. Mallory takes 1 BTC, and creates an invalid SegWit transaction
> that Bob cannot properly validate and that pays into one of Mallory's
> wallets. [...]
> Clueless Carol is one of the 4.9% of miners who forgot to upgrade
> her mining node. Carol sees that Mallory included an enormous fee in
> his transactions, so Carol makes sure to include both transactions in
> her block.

For it to be a "safe" soft fork, the "invalid segwit transaction" should
look non-standard to Carol, and as such she should refuse to mine it.

I think the attack has to go like this:

 * segwit activates; 5% of miners fail to upgrade however

 * Mallory creates a transaction paying to a segwit script
   (ie scriptPubKey is just a 33 byte push) [0]

 * non-upgraded nodes and miners will refuse to forward or mine
   this transaction (a non-p2sh scriptPubKey that just pushes data is
   non-standard) but the upgraded nodes and miners will forward and mine
   it. it will be included in the blockchain by upgraded miners fairly
   soon, and will then be in the UTXO set of non-upgraded miners and
   nodes too.

 * Mallory creates a segwit-invalid spend back to himself (or directly
   to Bob for the 1BTC), ie provides empty scriptSig, but no
   witness data. Upgraded miners and nodes reject the transaction,
   but non-upgraded nodes will relay and mine it afaics.

I *think* that transaction will fail the AreInputsStandard() test on
non-upgraded nodes, and thus still won't be accepted to the mempool
or mined by non-upgraded nodes, and thus no one will see it, or any
descendent transactions. (Upgraded nodes will reject it because it's
segwit invalid, of course)

If it is accepted by some old nodes, that transaction won't ever get many
confirmations -- if Carol mines it, her block will be orphaned by the
upgraded mining majority after the next two or three blocks are found.
With only 5% of hashpower, it will take around three hours for Carol
and friends to find a block in general.

Also, the fact that segwit outputs are "anyone can spend" maybe mitigates
this further -- you could have a vigilante node that creates invalid
segwit txns for every segwit output that just spends the entire thing
to fees. Even if the vigilante's transactions get rejected by nodes who
see Mallory's attempt first, that should still be enough to trigger any
sort of double-spend alerts I can think of, at least if anyone at all
is altruistic enough to run a vigilante node like that in the first place.

> Mallory gets free beer.
> Anything I'm missing?

So I think the only way Mallory gets free beer from you with segwit
soft-fork is if:

 - you're running out of date software and you're ignoring warnings to
   upgrade (block versions have bumped)
 - you've turned off standardness checks
 - you're accepting low-confirmation transactions
 - you're not using any double-spend detection service

If you're not accepting zero-confirmation transactions straight from
the mempool, (ie you require 1 or 2 confirmations) you also need:

 - some non-upgraded miners who have turned off standardness checks
 - your business is setup that an attacker can happily wait hours for
   the transaction to be included in a block before trying to get beer
   from you

In general (IMO), just leaving standardness checks turned on (and waiting
for 6 confirmations before accepting any non-standard transaction) should
be enough to keep you safe from any attack a soft-fork might enable.

Upgrading your software regularly should also be enough to keep you safe
for any soft-fork, and also for any hard-fork, obviously.

Cheers,
aj

[0] Actually, for this attack Mallory could use *any* segwit payment, it
doesn't have to be his bitcoins to start with, he just has to make
it look like they finish up with him, which is trivial if segwit
looks like anyone can spend. Having it be his segwit payment in the
first place makes it a little easier to ensure his payment is seen
as the original and not the doublespend though.

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille via bitcoin-dev]

On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik  wrote:
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
> Diverging from the satoshi block size change plan[1] and current economics
> would seem to require a high level of months-ahead communication to users.

I don't see any plan, but will you say the same thing when the subsidy
dwindles, and mining income seems to become uncertain? It will equally
be an economic change, which equally well will have been predictable,
and it will equally well be treatable with a hardfork to increase the
subsidy.

Yes, I'm aware the argument above is a straw man, because there was
clear expectation that the subsidy would go down asymptotically, and
much less an expectation that the blocksize would remain fixed
forever.

But I am not against a block size increase hard fork. My talk on
segregated witness even included proposed pursuing a hard fork at a
slightly later stage.

But what you're arguing for is that - despite being completely
expected - blocks grew fuller, and people didn't adapt to block size
pressure and a fee market, so the Core committee now needs to kick the
can down the road, because we can't accept the risk of economic
change. That sounds very much like a bailout to me.

Again. I am not against growth, but increasing in response to fear of
economic change is the wrong approach. Economic change is inevitable.

> Segregated Witness does not kick the can, it solves none of the problems #1,
> #3 - #8 explicitly defined and listed in email #1.
>
> 1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
> will be no Fee Event, because the core block size is still heavily contended
> -- 100% contended at time out SW rollout.

That is an assumption. I expect demand for transactions at a given
feerate to stop growing at a certain contention level (and we've
reached some level of contention already, with mempools not being
cleared for significant amounts of time already).

> SW mitigates this
> - only after several months

That is assuming a hard fork consensus forming, deployment,
activation, ... goes faster than a softfork.

> - only assuming robust adoption rates by up-layer ecosystem software, and

That's not required. Everyone who individually switches to new
transactions gets to do 1.75x more transactions for the same price
(and at the same time gets safer contracts, better script
upgradability, and more security models at their disposal), completely
independent of whether anyone else in the ecosystem does the same.

> - only assuming transaction volume growth is flat or sub-linear

The only question is how many transactions for what price. Contention
always happens at a specific feerate level anyway.

> Those conditions must go as planned to fulfill "SW kicked the can" -- a lot
> of if's.
>
> As stated, SW is orthogonal to the drift-into-uncharted-waters problem
> outlined in email #1, which a short term bump does address.

Both SW and a short bump (which is apparently not what BIP102 does
anymore?) increase capacity available per price, and yes, they are
completely orthogonal.

My only disagreement is the motivation (avoiding economic change, as
opposed to aiming for safe growth) and the claim that a capacity
increase hardfork is easier and safe(r) to roll out quickly than
sortfork SW.

Apart from that, we clearly need to do both at some point.

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