Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Raystonn . via bitcoin-dev]

Great catch, and a good proposal for a fix.  Pushing the activation height out 
to allow existing hardware to enter obsolescence prior to activation may help 
reduce miner resistance.  It may also avoid legal threats from those currently 
abusing.  If miners still resist, the threat of an earlier activation height is 
a good negotiating tool.

Raystonn

On 5 Apr 2017 2:39 p.m., Gregory Maxwell via bitcoin-dev 
 wrote:
A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.

While most discussion of ASICBOOST has focused on the overt method
of implementing it, there also exists a covert method for using it.

As I explained one of the approaches to inhibit covert ASICBOOST I
realized that my words were pretty much also describing the SegWit
commitment structure.

The authors of the SegWit proposal made a specific effort to not be
incompatible with any mining system and, in particular, changed the
design at one point to accommodate mining chips with forced payout
addresses.

Had there been awareness of exploitation of this attack an effort
would have been made to avoid incompatibility-- simply to separate
concerns.  But the best methods of implementing the covert attack
are significantly incompatible with virtually any method of
extending Bitcoin's transaction capabilities; with the notable
exception of extension blocks (which have their own problems).

An incompatibility would go a long way to explain some of the
more inexplicable behavior from some parties in the mining
ecosystem so I began looking for supporting evidence.

Reverse engineering of a particular mining chip has demonstrated
conclusively that ASICBOOST has been implemented
in hardware.

On that basis, I offer the following BIP draft for discussion.
This proposal does not prevent the attack in general, but only
inhibits covert forms of it which are incompatible with
improvements to the Bitcoin protocol.

I hope that even those of us who would strongly prefer that
ASICBOOST be blocked completely can come together to support
a protective measure that separates concerns by inhibiting
the covert use of it that potentially blocks protocol improvements.

The specific activation height is something I currently don't have
a strong opinion, so I've left it unspecified for the moment.


  BIP: TBD
  Layer: Consensus
  Title: Inhibiting a covert attack on the Bitcoin POW function
  Author: Greg Maxwell 
  Status: Draft
  Type: Standards Track
  Created: 2016-04-05
  License: PD


==Abstract==

This proposal inhibits the covert exploitation of a known
vulnerability in Bitcoin Proof of Work function.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

==Motivation==

Due to a design oversight the Bitcoin proof of work function has a potential
attack which can allow an attacking miner to save up-to 30% of their energy
costs (though closer to 20% is more likely due to implementation overheads).

Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
which they have so far not licensed for free and open use by the public.
They have been marketing their patent licenses under the trade-name
ASICBOOST.  The document takes no position on the validity or enforceability
of the patent.

There are two major ways of exploiting the underlying vulnerability: One
obvious way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol.  The covert mechanism is not
easily detected except through its interference with the protocol.

In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.

Exploitation of this vulnerability could result in payoff of as much as
$100 million USD per year at the time this was written (Assuming at
50% hash-power miner was gaining a 30% power advantage and that mining
was otherwise at profit equilibrium).  This could have a phenomenal
centralizing effect by pushing mining out of profitability for all
other participants, and the income from secretly using this
optimization could be abused to significantly distort the Bitcoin
ecosystem in order to preserve the advantage.

Reverse engineering of a mining ASIC from a major manufacture has
revealed that it contains an undocumented, undisclosed ability
to make use of this attack. (The parties claiming to hold a
patent on this technique were completely unaware of this use.)

On the above basis the potential for covert exploitation of this
vulnerability and the resulting inequality in the mining process
and interference with useful improvements presents a clear and
present danger to the Bitcoin system which requires a

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Oliver Petruzel via bitcoin-dev]

> > One of the things going for us here is that Bitmain has been keeping
ASICBOOST
> > from their own customers - as far as we know they haven't been sharing
it, and
> > thus they're the only ones you can actually use it.
> >
> > So while we're pissing off Bitmain in disabling it, we wouldn't be
affecting
> > anyone else.
> >
> > Equally, mining is a zero-sum game: if no-one can use ASICBOOST, miners
are in
> > the same position as before. ASICBOOST is only relevant to miners like
Bitmain
> > who have access to it while other miners don't.

Peter -
Do we know that for a fact, though? What evidence or intelligence do we
have to indicate Bitmain itself is the only entity using the covert boost?

A few possibilities:
1. They could have already shared it with a limited number of strategic
partners;
2. They could have offered to share it with various parties in exchange for
something (money, support for BU, etc); or
3. They could provide the custom firmware/software to select parties as a
direct response to this disclosure -- which would enhance their defenses
against a soft fork.
4. They could share the firmware/software with EVERY owner of their
equipment in a last-ditch defense against a soft fork. (after all, some
advantage over other equipment manufacturers is still better than no
advantage, right?)

Assumptions could lead to failure, so these are just some things to keep in
mind.

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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Peter Todd via bitcoin-dev]

On Wed, Apr 05, 2017 at 11:23:22PM -0400, David Vorick wrote:
> I urge everybody to realize how difficult something like this is going to
> be to pull off. We are literally talking about invalidating hardware (or at
> least the optimized bits). It's only going to succeed if everybody is
> conclusively on board. As you consider proposals, realize that anything
> which is not the simplest and least contentious is already dead.

One of the things going for us here is that Bitmain has been keeping ASICBOOST
from their own customers - as far as we know they haven't been sharing it, and
thus they're the only ones you can actually use it.

So while we're pissing off Bitmain in disabling it, we wouldn't be affecting
anyone else.

Equally, mining is a zero-sum game: if no-one can use ASICBOOST, miners are in
the same position as before. ASICBOOST is only relevant to miners like Bitmain
who have access to it while other miners don't.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Peter Todd via bitcoin-dev]

On Wed, Apr 05, 2017 at 11:11:53PM -0400, Erik Aronesty wrote:
> If the primary purpose of pow is to destroy value, then a masked proof of
> burn to an expanded address that assigns the private key holder the right

You're talking about proof-of-stake here.

At best it's very difficult for such a "proof-of-burn" to _actually_ be a
proof, as the burn only happens if the consensus mechanism ultimately includes
that burn. Contrast that to proof-of-work's incredibly simple proof: you _know_
energy was destroyed to find a PoW solution, regardless of what consensus is
ultimately reached.

It's the difference between a computer secured from hackers with an anti-virus
scanner, and a computer secured by the fact that it's not connected to the
internet at all.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[David Vorick via bitcoin-dev]

I have a practical concern related to the amount of activation energy
required to get something like this through. We are talking about
implementing something that would remove tens to hundreds of millions of
dollars of mining revenue for miners who have already gambled that this
income would be available to them.

That's not something they are going to let go of without a fight, and we've
already seen this with the segwit resistance. Further, my understanding is
that this makes a UASF a lot more difficult. Mining hardware that has
unique optimizations on one chain only can resist a UASF beyond a simple
economic majority, because they can do more hashes on the same amount of
revenue. Threshold for success is no longer 51%, especially if you are
expecting the miners to struggle (and this is a case where they have a very
good reason to struggle). Any resistance from the hashrate during the early
days of a UASF will inevitably cause large reorgs for older nodes, and is
not much better than a hardfork.

I don't know what the right answer is. But I know that we are not going to
get segwit without a fight. We are not going to invalidate covert asicboost
without a fight. And we are working with a system that actively (and is
demonstrably very effective at doing it) resists changes which are
contentious. This is definitely a contentious change, because an important
part of the community (the miners) is going to be actively resisting it.

I urge everybody to realize how difficult something like this is going to
be to pull off. We are literally talking about invalidating hardware (or at
least the optimized bits). It's only going to succeed if everybody is
conclusively on board. As you consider proposals, realize that anything
which is not the simplest and least contentious is already dead.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Erik Aronesty via bitcoin-dev]

If the primary purpose of pow is to destroy value, then a masked proof of
burn to an expanded address that assigns the private key holder the right
to mine only in the next Nth block would be sufficient.  Expanding the
address space so that addresses can only be proven invalid only with the
private key.  Miners can then not trivially game the system by excluding
tx...without killing the entire system.  ( Like POW ... miners lose many
burns since only one valid proof is deterministically selected. Difficult
adjusted upward based on the number of valid proofs per block.)

The other part of "real POW" is that miners take *time* to mine.  Proof of
destroyed value us not sufficient.  Proof of time spent is critical
something even a masked burn cannot provide.

On Apr 5, 2017 10:49 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Apr 05, 2017 at 07:39:08PM -0700, Bram Cohen wrote:
> > On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <
> > > While I'm in favour of blocking covert usage of ASICBOOST, there's
> every
> > > reason
> > > to block non-covert usage of it as well. In a low margin business like
> > > mining,
> > > the advatange it gives is enormous - quite possibly 10x your profit
> margin
> > > -
> > > and given that barrier free access to being able to purchase ASICs is
> > > already
> > > an archilles heal for Bitcoin there is every reason to eliminate this
> legal
> > > vulnerability. Additionally, it's a technical vulnerability as well: we
> > > want
> > > getting into the ASIC manufacturing and design business to have as low
> > > barriers
> > > to entry as is feasible, and the ASICBOOST exploit significantly
> increases
> > > the
> > > minimum capital requirements to do so.
> > >
> >
> > Asicboost also has the problem that it isn't treating the hashing as a
> > black box, and thus has impacts on what gets mined. In particular it
> > creates an incentive to make blocks smaller. That's a very unwanted
> effect,
> > and anything like it should be engineered out on principle.
>
> Agreed! There's no benefit to Bitcoin for having it - one way or the other
> miners are going to destroy ~12BTC/block worth of energy. Meanwhile it
> appears
> to have lead to something like a year of stupid political bullshit based
> on a
> secret advantage - there's no reason to invite a repeat of this episode.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> ___
> 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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Peter Todd via bitcoin-dev]

On Wed, Apr 05, 2017 at 07:39:08PM -0700, Bram Cohen wrote:
> On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <
> > While I'm in favour of blocking covert usage of ASICBOOST, there's every
> > reason
> > to block non-covert usage of it as well. In a low margin business like
> > mining,
> > the advatange it gives is enormous - quite possibly 10x your profit margin
> > -
> > and given that barrier free access to being able to purchase ASICs is
> > already
> > an archilles heal for Bitcoin there is every reason to eliminate this legal
> > vulnerability. Additionally, it's a technical vulnerability as well: we
> > want
> > getting into the ASIC manufacturing and design business to have as low
> > barriers
> > to entry as is feasible, and the ASICBOOST exploit significantly increases
> > the
> > minimum capital requirements to do so.
> >
> 
> Asicboost also has the problem that it isn't treating the hashing as a
> black box, and thus has impacts on what gets mined. In particular it
> creates an incentive to make blocks smaller. That's a very unwanted effect,
> and anything like it should be engineered out on principle.

Agreed! There's no benefit to Bitcoin for having it - one way or the other
miners are going to destroy ~12BTC/block worth of energy. Meanwhile it appears
to have lead to something like a year of stupid political bullshit based on a
secret advantage - there's no reason to invite a repeat of this episode.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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] Proof-of-Loss

[Erik Aronesty via bitcoin-dev]

Is this the same as proof of burn?

On Apr 5, 2017 5:28 PM, "Mirelo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> With the feedback on Proof-of-Loss (always privately to my email), I
> realized the article was hard to understand for lacking:
>
> * A more explicit definition of transaction rights.
> * An overview of how the algorithm works.
>
> As an abstract could not contain all that, I wrote an introduction with
> examples.
>
> I also adopted a suggestion of including the current block height in the
> proof-of-loss data once I realized:
>
> * Preventing the same proof-of-loss from chaining consecutive blocks was
> not the purpose of the proof-of-loss context, which did it statistically
> rather than logically.
> * The presence of that height in the block header made serial chaining
> easier to enforce, by removing the need to include additional block height
> information.
>
> While revising the algorithm, I made some corrections, mainly to:
>
> * Transaction prioritization (which now uses fees instead of rights).
> * Inactivity fees.
>
> Finally, the new version more aptly derives the design and often has
> better wording.
>
> The new text is available at:
>
> https://proof-of-loss.money/
>
> Mirelo
>
>
>
>  Original Message 
> Subject: Proof-of-Loss
> Local Time: February 4, 2017 10:39 AM
> UTC Time: February 4, 2017 12:39 PM
> From: mir...@deugh-ausgam-valis.com
> To: bitcoin-dev@lists.linuxfoundation.org  linuxfoundation.org>
>
> An alternative consensus algorithm to both proof-of-work and
> proof-of-stake, *proof-of-loss* addresses all their deficiencies,
> including the lack of an organic block size limit, the risks of mining
> centralization, and the "nothing at stake" problem:
>
> *https://proof-of-loss.money/ *
>
>
>
>
>
>
> ___
> 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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Bram Cohen via bitcoin-dev]

On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> While I'm in favour of blocking covert usage of ASICBOOST, there's every
> reason
> to block non-covert usage of it as well. In a low margin business like
> mining,
> the advatange it gives is enormous - quite possibly 10x your profit margin
> -
> and given that barrier free access to being able to purchase ASICs is
> already
> an archilles heal for Bitcoin there is every reason to eliminate this legal
> vulnerability. Additionally, it's a technical vulnerability as well: we
> want
> getting into the ASIC manufacturing and design business to have as low
> barriers
> to entry as is feasible, and the ASICBOOST exploit significantly increases
> the
> minimum capital requirements to do so.
>

Asicboost also has the problem that it isn't treating the hashing as a
black box, and thus has impacts on what gets mined. In particular it
creates an incentive to make blocks smaller. That's a very unwanted effect,
and anything like it should be engineered out on principle.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Peter Todd via bitcoin-dev]

On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote:
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
> 
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.

While I'm in favour of blocking covert usage of ASICBOOST, there's every reason
to block non-covert usage of it as well. In a low margin business like mining,
the advatange it gives is enormous - quite possibly 10x your profit margin -
and given that barrier free access to being able to purchase ASICs is already
an archilles heal for Bitcoin there is every reason to eliminate this legal
vulnerability. Additionally, it's a technical vulnerability as well: we want
getting into the ASIC manufacturing and design business to have as low barriers
to entry as is feasible, and the ASICBOOST exploit significantly increases the
minimum capital requirements to do so.

Remember that the whole purpose of PoW is to destroy value on a level playing
field. Anything that inhibits a level playing field is an exploit. While this
isn't standard crypto - we can't fix every exploit completely - since we're
going to do a technical change to partially mitigate the ASCIBOOST exploit
there is every reason to fully mitigate it.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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] Segwit2Mb - combined soft/hard fork - Request For Comments

[Erik Aronesty via bitcoin-dev]

I personally appreciate the minimal changes, and often encourage
development to be done this way - when it needs to be released quickly.
But does this need to be released quickly?

- maybe the proposal should be renamed segwit 8mb and be discussed solely
in terms of block weights.

- a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.

- miners who currently object to segwit while pretending to like larger
blocks will find some excuse to object to this too.

- Given the challenges miners seem to have in flipping bits, I expect any
fork that requires 95pct hash power to be vaporware.

On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The hard-fork is conditional to 95% of the hashing power has approved the
>> segwit2mb soft-fork and the segwit soft-fork has been activated (which
>> should occur 2016 blocks after its lock-in time)
>>
>
> Miners signalling they have upgraded by flipping a bit in the nVersion
> field has little relevance in a hard fork. If 100% of the hash power
> indicates they are running this proposal, but the nodes don't upgrade, what
> will happen?
>
> For the record, I actually talk a lot about hard forks with various
> developers and am very interested in the research that Johnson in
> particular is pioneering. However, I have failed to understand your point
> about 95% miner signalling in relation to a hard fork, so I am eagerly
> awaiting your explanation.
>
> ___
> 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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Jonathan Toomim via bitcoin-dev]

Just checking to see if I understand this optimization correctly. In order to 
find merkle roots in which the rightmost 32 bits are identical (i.e. partial 
hash collisions), we want to compute as many merkle root hashes as quickly as 
possible. The fastest way to do this is to take the top level of the Merkle 
tree, and to collect a set of left branches and right branches which can be 
independently manipulated. While the left branch can easily be manipulated by 
changing the extranonce in the coinbase transaction, the right branch would 
need to be modified by changing one of the transactions in the right branch or 
by changing the number of transactions in the right branch. Correct so far?

With the stratum mining protocol, the server (the pool) includes enough 
information for the coinbase transaction to be modified by stratum client (the 
miner), but it does not include any information about the right side of the 
merkle tree except for the top-level hash. Stratum also does not allow the 
client to supply any modifications to the merkle tree (including the right 
side) back to the stratum server. This means that any implementation of this 
final optimization would need to be using a protocol other than stratum, like 
getblocktemplate, correct?

I think it would be helpful for the discussion to know if this optimization 
were currently being used or not, and if so, how widely.

All of the consumer-grade hardware that I have seen defaults to stratum-only 
operation, and I have not seen or heard of any hardware available that can run 
more efficiently using getblocktemplate. As the current pool infrastructure 
uses stratum exclusively, this optimization would require significant retooling 
among pools, and probably a redesign of their core algorithms to help discover 
and share these partial collisions more frequently. It's possible that some 
large private farms have deployed a special system for solo mining that uses 
this optimization, of course, but it's also possible that there's a teapot in 
space somewhere between the orbit of Earth and Mars.

Do you know of any ways to perform this optimization via stratum? If not, do 
you have any evidence that this optimization is actually being used by private 
solo mining farms? Or is this discussion purely about preventing this 
optimization from being used in the future?

-jtoomim

> On Apr 5, 2017, at 2:37 PM, Gregory Maxwell via bitcoin-dev 
>  wrote:
> 
> An obvious way to generate different candidates is to grind the
> coinbase extra-nonce but for non-empty blocks each attempt will
> require 13 or so additional sha2 runs which is very inefficient.
> 
> This inefficiency can be avoided by computing a sqrt number of
> candidates of the left side of the hash tree (e.g. using extra
> nonce grinding) then an additional sqrt number of candidates of
> the right  side of the tree using transaction permutation or
> substitution of a small number of transactions.  All combinations
> of the left and right side are then combined with only a single
> hashing operation virtually eliminating all tree related
> overhead.
> 
> With this final optimization finding a 4-way collision with a
> moderate amount of memory requires ~2^24 hashing operations
> instead of the >2^28 operations that would be require for
> extra-nonce  grinding which would substantially erode the
> benefit of the attack.



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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Joseph Poon via bitcoin-dev]

On Thu, Apr 06, 2017 at 01:32:03AM +, Gregory Maxwell wrote:
> On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon  wrote:
> > #bitcoin@freenode:
> >  00:04gmaxwell| lol poon pretending that he isn't complicit in all this 
> > stuff.
> >
> > Are you *fucking* serious? Is this how you resolve all problems? I'm
> > taking you seriously and having second thoughts and want to make public
> > commitments to do the right thing without any evidence and you come out
> > and say *this*?

Apologies to the list.

> I apologize for the glib talk on chat and I hope you understand that
> the tone in such venues is significantly informal; and that my remark
> was a causal one among friends which was not intended in a spirit as
> seriously as you've taken it.

You're still presuming ill-will. I'm seriously offended. I'm not upset
with the glib talk, I'm upset that you think I have ill will.

> That said, two days ago you participated in a highly unusual
> announcement of a protocol change that-- rather than being sent for
> community review in any plausible venue for that purpose-- was
> announced as a done deal in embargoed media announcements.  This
> proposed protocol change seemed custom tailored to preserve covert
> boosting, and incorporated direct support for lightning -- and the
> leading competing theory was that a large miner opposed segwit
> specifically because they wanted to block lightning. Moreover, I have
> heard reports I consider reliable that this work was funded by the
> miner in question.

We specifically told you guys privately and publicly when asked that it
was simply to be able to do it in 2 weeks. Check out the code, it was
much faster to do it that way. The spec wasn't complete and I have
personal biases against doing it on the main-chain since it would
benefit things if there was smart contract proections on the main chain
as well, which I figured would be more controversial. I never said
anything about public commitments to transactions. In fact, I'm pretty
good at figuring things out and tend to cargo-cult things (since culture
is the genetic memory is civlizations), if I saw BIP141/SegWit required
a commitment instead of it being optional, I would've probably thought
about it. Why wasn't this required as part of SegWit? BIP141 is still
vulnerable. Why did you pull this out just now? I'm totally blindsided
here, hence my earlier reply of wanting to resolve it in the Extension
Block proposal.

> In the time since, when people asked for revisions to the proposal to
> not block segwit they received responses from the Bcoin account on
> twitter that "there would be no amendments", and I was sent leaked
> chatlogs of you making considerably hostile statements, claiming that
> if your extension block proposal is "a litmus test for corruption",
> and claimed (before AFAIK anyone had had a chance to comment on it)
> that the Bitcoin project contributors opposed it for "nonsense
> reasons".

I never participated in that, and the specific announcement here
indicates that changes will be happening. The intention was to get it
out as a draft and *working* demo code.

https://medium.com/purse-essays/ready-for-liftoff-a5533f4de0b6

That was specifically after Core developers accused me of publicly
acting in poor form without any understanding of the situation. I was
especially annoyed because all of you are acting with similar secrecy,
even worse, there is specific organization by Core which the public is
not aware of. Think about it from my perspective, you all blocked me out
intentionally for months and then accuse me of going to journalists for
a couple hours before? I'm seriously hurt.

> It is with this in mind that when you tried to pull me into an off the
> record conversation that I responded stating:
> 
> "[...] I am disinclined to communicate with you except in email where I can
> get third party transferable proof of our communication.  I'm
> concerned that you may now be involved in a conspiracy which I do not
> want to be implicated in myself.
> 
> It is my estimation that, for that above reason, it would be in my
> best interest to not communicate with you at all.  But in all your
> prior interactions you appeared to have integrity and sense, so out of
> respect for that history I'm willing to communicate with you, but only
> in public or in email where my end is on gmail."

Nice you cut out the beginning which explains on *why* I didn't reply:

"with an embargoed press release in Forbes.

That's how you roll now, right? :-/"

Why didn't you include your entire message?

That was in reply to my initial message reaching out to you and Adam
Back:
"Hi, would you like a phone call tomorrow?

I am in Thailand right now, I understand if what I did is upsetting, my
goal was not to upset you.

I deeply respect you both technically, but I do believe what I am doing
is right. If you could find a way, I would be extremely grateful if we
could chat sometime."

Replying with a beginning like that with th

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Gregory Maxwell via bitcoin-dev]

On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon  wrote:
> #bitcoin@freenode:
>  00:04gmaxwell| lol poon pretending that he isn't complicit in all this 
> stuff.
>
> Are you *fucking* serious? Is this how you resolve all problems? I'm
> taking you seriously and having second thoughts and want to make public
> commitments to do the right thing without any evidence and you come out
> and say *this*?

I apologize for the glib talk on chat and I hope you understand that
the tone in such venues is significantly informal; and that my remark
was a causal one among friends which was not intended in a spirit as
seriously as you've taken it.

That said, two days ago you participated in a highly unusual
announcement of a protocol change that-- rather than being sent for
community review in any plausible venue for that purpose-- was
announced as a done deal in embargoed media announcements.  This
proposed protocol change seemed custom tailored to preserve covert
boosting, and incorporated direct support for lightning -- and the
leading competing theory was that a large miner opposed segwit
specifically because they wanted to block lightning. Moreover, I have
heard reports I consider reliable that this work was funded by the
miner in question.

In the time since, when people asked for revisions to the proposal to
not block segwit they received responses from the Bcoin account on
twitter that "there would be no amendments", and I was sent leaked
chatlogs of you making considerably hostile statements, claiming that
if your extension block proposal is "a litmus test for corruption",
and claimed (before AFAIK anyone had had a chance to comment on it)
that the Bitcoin project contributors opposed it for "nonsense
reasons".

It is with this in mind that when you tried to pull me into an off the
record conversation that I responded stating:

"[...] I am disinclined to communicate with you except in email where I can
get third party transferable proof of our communication.  I'm
concerned that you may now be involved in a conspiracy which I do not
want to be implicated in myself.

It is my estimation that, for that above reason, it would be in my
best interest to not communicate with you at all.  But in all your
prior interactions you appeared to have integrity and sense, so out of
respect for that history I'm willing to communicate with you, but only
in public or in email where my end is on gmail."

This was two days ago and you did not respond further.

With that in mind I hope you do not find some casual crap-talking on
chat to be especially surprising.

I understand that you didn't intend for the initial message to be
posted in public, so I'm sorry for continuing the thread here-- but I
thought it was useful for people to understand the context behind that
glib remark: Including the point that I do not know for a fact that
you are complicit in anything, but I consider your recent actions to
be highly concerning.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Joseph Poon via bitcoin-dev]

Ahh, sorry all for this public message. :(

On Wed, Apr 05, 2017 at 05:39:00PM -0700, Joseph Poon wrote:
> #bitcoin@freenode:
>  00:04gmaxwell| lol poon pretending that he isn't complicit in all this 
> stuff.
> 
> Are you *fucking* serious? Is this how you resolve all problems? I'm
> taking you seriously and having second thoughts and want to make public
> commitments to do the right thing without any evidence and you come out
> and say *this*?

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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Joseph Poon via bitcoin-dev]

#bitcoin@freenode:
 00:04gmaxwell| lol poon pretending that he isn't complicit in all this 
stuff.

Are you *fucking* serious? Is this how you resolve all problems? I'm
taking you seriously and having second thoughts and want to make public
commitments to do the right thing without any evidence and you come out
and say *this*?

On Thu, Apr 06, 2017 at 12:17:17AM +, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev
>  wrote:
> > This seems to be a serious security problem.  Would it be possible to have
> > a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think 
> > that a trigger
> > 3-6 months from release should be sufficient for enough of the economy to 
> > upgrade,
> > given the severity of the issue.
> 
> Not 0.14.1 because that is in RC already and will hopefully be out in a week.
> 
> I think the speed of adoption depends a lot of the level of support
> from the community. I don't believe there are any technical hurdles to
> implementing this relatively quickly (and I specifically propose using
> the users choice of the segwit commitment or a modified form in order
> to lower the technical complexity and risk).
> 
> > BIP 141 says that the the commitment is optional if there are no SegWit 
> > transactions in
> > the block,  so will today's SegWit-ready miners always produce it even when 
> > optional
> > according to BIP 141, as required by this softfork?
> 
> This is the default behavior as of 0.13.2, but I haven't gone out to
> measure this which is why the backwards compatibility section of the
> BIP isn't written yet.
> 
> 
> While I'm posting, I've had a dozen off-list emails that presented me
> with some FAQ:
> 
> Many people asked what other protocol upgrades beyond segwit could run
> into the same incompatibility.
> 
> Many proposed improvements to Bitcoin require additional
> transaction-dependent commitment data.
> 
> Examples include:
> 
> (1) Segwit.
> (2) UTXO commitments. (non-delayed, at least)
> (3) Committed Bloom filters
> (4) Committed address indexes
> (5) STXO commitments (non-delayed).
> (6) Weak blocks
> (7) Most kinds of fraud proofs
> -- to state a few.
> 
> Unfortunately, putting *any* commitment to data dependent on the right
> hand side of the hash tree in the left hand side (e.g. coinbase) means
> a massive increase in the computation required for covert boosting,
> because it means you can't use the left+right side combinations to
> eliminate most of the hashing.
> 
> It's plausible, in fact, that this extra computation could completely
> nullify the ASICBOOST advantage-- though this depends a lot on the
> fine details of the implementation.
> 
> This proposal does not itself propose nullifying ASICBOOST entirely,
> it proposes severely handicapping the covert form of it, and
> eliminating the differential advantage for boosting miners related to
> the use of transaction-dependent commitments.
> 
> Basically there are two completely separate concerns: that boosting
> can produce a monopoly advantage which could be severely harmful to
> the ecosystem, and that the efficient implementation of _covert_
> boosting can severely harm many useful protocol improvements.   My
> proposal only addresses the second concern, by (I believe) completely
> leveling the playing field so that opposing commitments will not break
> boosting any worse, and by making covert boosting less appealing in
> general.
> 
> Use of the segwit-style commitment even in non-segwit blocks is sufficient
> because the segwit commitment commits to all  transactions  (except
> the coinbase) and not just segwit ones.
> (It was designed this way so that lite clients that needed witness
> data could work with just one tree).
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Gregory Maxwell via bitcoin-dev]

On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev
 wrote:
> This seems to be a serious security problem.  Would it be possible to have
> a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that 
> a trigger
> 3-6 months from release should be sufficient for enough of the economy to 
> upgrade,
> given the severity of the issue.

Not 0.14.1 because that is in RC already and will hopefully be out in a week.

I think the speed of adoption depends a lot of the level of support
from the community. I don't believe there are any technical hurdles to
implementing this relatively quickly (and I specifically propose using
the users choice of the segwit commitment or a modified form in order
to lower the technical complexity and risk).

> BIP 141 says that the the commitment is optional if there are no SegWit 
> transactions in
> the block,  so will today's SegWit-ready miners always produce it even when 
> optional
> according to BIP 141, as required by this softfork?

This is the default behavior as of 0.13.2, but I haven't gone out to
measure this which is why the backwards compatibility section of the
BIP isn't written yet.


While I'm posting, I've had a dozen off-list emails that presented me
with some FAQ:

Many people asked what other protocol upgrades beyond segwit could run
into the same incompatibility.

Many proposed improvements to Bitcoin require additional
transaction-dependent commitment data.

Examples include:

(1) Segwit.
(2) UTXO commitments. (non-delayed, at least)
(3) Committed Bloom filters
(4) Committed address indexes
(5) STXO commitments (non-delayed).
(6) Weak blocks
(7) Most kinds of fraud proofs
-- to state a few.

Unfortunately, putting *any* commitment to data dependent on the right
hand side of the hash tree in the left hand side (e.g. coinbase) means
a massive increase in the computation required for covert boosting,
because it means you can't use the left+right side combinations to
eliminate most of the hashing.

It's plausible, in fact, that this extra computation could completely
nullify the ASICBOOST advantage-- though this depends a lot on the
fine details of the implementation.

This proposal does not itself propose nullifying ASICBOOST entirely,
it proposes severely handicapping the covert form of it, and
eliminating the differential advantage for boosting miners related to
the use of transaction-dependent commitments.

Basically there are two completely separate concerns: that boosting
can produce a monopoly advantage which could be severely harmful to
the ecosystem, and that the efficient implementation of _covert_
boosting can severely harm many useful protocol improvements.   My
proposal only addresses the second concern, by (I believe) completely
leveling the playing field so that opposing commitments will not break
boosting any worse, and by making covert boosting less appealing in
general.

Use of the segwit-style commitment even in non-segwit blocks is sufficient
because the segwit commitment commits to all  transactions  (except
the coinbase) and not just segwit ones.
(It was designed this way so that lite clients that needed witness
data could work with just one tree).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Anthony Towns via bitcoin-dev]

On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote:
> The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
> incriminating a 32-bit nonce 

That should probably be "incrementing"...

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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Joseph Poon via bitcoin-dev]

Hi Greg,

On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote:
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
> 
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
> 
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.
> 
> [...]
> 
> ==New consensus rule==
> 
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
> 
> (See BIP-141 "Commitment structure" for details)
> 
> Existing segwit using miners are automatically compatible with
> this proposal. Non-segwit miners can become compatible by simply
> including an additional output matching a default commitment
> value returned as part of getblocktemplate.
> 
> Miners SHOULD NOT automatically discontinue the commitment
> at the expiration height.

Decentralized systems without patent encumbrance is an important topic
for me. We'd be very interested in adding this into extension blocks.

Claims like these merit serious attention. If you can provide any kind
of proof or documentation of this (doesn't need to be conclusive, just
something), I will provide my word and promise publicly here and now
that I will personally see to it that a commitment which solves this
(albeit possibly using a slightly different format to make it
compatible) is added into the Extension Blocks spec. If there is
evidence, my support and authorship of the Extension Block specification
is contingent upon resolving this issue.

We have added an issue here:
https://github.com/tothemoon-org/extension-blocks/issues/6

I'm interested in a more detailed explanation on how the Merle tree
structure works so we can add it to the spec, I didn't follow exactly
the new consensus rule and its mechanism in those several lines.

We will begin making a pull request adding it into our specification,
but more clarity on how to do it on its own would be helpful. We will
also consider the code exposure change to adding in SegWit on the
Canonical/1MB chain if it is more elegant to implement.

Packaging this into our proposal would not only be important, but
helpful to the end goals of this proposal as it becomes a standard
soft-fork consensus rule which has greater guarantees around
enforcibility than user-actication.

Further, can you provide clarity and confirmation into why this
commitment wasn't required as part of SegWit? 

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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[theymos via bitcoin-dev]

This seems to be a serious security problem.  Would it be possible to have
a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a 
trigger
3-6 months from release should be sufficient for enough of the economy to 
upgrade,
given the severity of the issue.

BIP 141 says that the the commitment is optional if there are no SegWit 
transactions in
the block,  so will today's SegWit-ready miners always produce it even when 
optional
according to BIP 141, as required by this softfork?

On Wed, Apr 5, 2017, at 04:37 PM, Gregory Maxwell via bitcoin-dev wrote:
> A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
> is exploited by ASICBOOST and the various steps which could be used to
> block it in the network if it became a problem.
> 
> While most discussion of ASICBOOST has focused on the overt method
> of implementing it, there also exists a covert method for using it.
> 
> As I explained one of the approaches to inhibit covert ASICBOOST I
> realized that my words were pretty much also describing the SegWit
> commitment structure.
> 
> The authors of the SegWit proposal made a specific effort to not be
> incompatible with any mining system and, in particular, changed the
> design at one point to accommodate mining chips with forced payout
> addresses.
> 
> Had there been awareness of exploitation of this attack an effort
> would have been made to avoid incompatibility-- simply to separate
> concerns.  But the best methods of implementing the covert attack
> are significantly incompatible with virtually any method of
> extending Bitcoin's transaction capabilities; with the notable
> exception of extension blocks (which have their own problems).
> 
> An incompatibility would go a long way to explain some of the
> more inexplicable behavior from some parties in the mining
> ecosystem so I began looking for supporting evidence.
> 
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
> 
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
> 
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.
> 
> The specific activation height is something I currently don't have
> a strong opinion, so I've left it unspecified for the moment.
> 
> 
>   BIP: TBD
>   Layer: Consensus
>   Title: Inhibiting a covert attack on the Bitcoin POW function
>   Author: Greg Maxwell 
>   Status: Draft
>   Type: Standards Track
>   Created: 2016-04-05
>   License: PD
> 
> 
> ==Abstract==
> 
> This proposal inhibits the covert exploitation of a known
> vulnerability in Bitcoin Proof of Work function.
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119.
> 
> ==Motivation==
> 
> Due to a design oversight the Bitcoin proof of work function has a potential
> attack which can allow an attacking miner to save up-to 30% of their energy
> costs (though closer to 20% is more likely due to implementation overheads).
> 
> Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
> which they have so far not licensed for free and open use by the public.
> They have been marketing their patent licenses under the trade-name
> ASICBOOST.  The document takes no position on the validity or enforceability
> of the patent.
> 
> There are two major ways of exploiting the underlying vulnerability: One
> obvious way which is highly detectable and is not in use on the network
> today and a covert way which has significant interaction and potential
> interference with the Bitcoin protocol.  The covert mechanism is not
> easily detected except through its interference with the protocol.
> 
> In particular, the protocol interactions of the covert method can block the
> implementation of virtuous improvements such as segregated witness.
> 
> Exploitation of this vulnerability could result in payoff of as much as
> $100 million USD per year at the time this was written (Assuming at
> 50% hash-power miner was gaining a 30% power advantage and that mining
> was otherwise at profit equilibrium).  This could have a phenomenal
> centralizing effect by pushing mining out of profitability for all
> other participants, and the income from secretly using this
> optimization could be abused to significantly distort the Bitcoin
> ecosystem in order to preserve the advantage.
> 
> Reverse engineering of a mining ASIC from a major manufacture has
> revealed that it contains an undocumented, undisclosed ability
> to make use of t

[bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Gregory Maxwell via bitcoin-dev]

A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.

While most discussion of ASICBOOST has focused on the overt method
of implementing it, there also exists a covert method for using it.

As I explained one of the approaches to inhibit covert ASICBOOST I
realized that my words were pretty much also describing the SegWit
commitment structure.

The authors of the SegWit proposal made a specific effort to not be
incompatible with any mining system and, in particular, changed the
design at one point to accommodate mining chips with forced payout
addresses.

Had there been awareness of exploitation of this attack an effort
would have been made to avoid incompatibility-- simply to separate
concerns.  But the best methods of implementing the covert attack
are significantly incompatible with virtually any method of
extending Bitcoin's transaction capabilities; with the notable
exception of extension blocks (which have their own problems).

An incompatibility would go a long way to explain some of the
more inexplicable behavior from some parties in the mining
ecosystem so I began looking for supporting evidence.

Reverse engineering of a particular mining chip has demonstrated
conclusively that ASICBOOST has been implemented
in hardware.

On that basis, I offer the following BIP draft for discussion.
This proposal does not prevent the attack in general, but only
inhibits covert forms of it which are incompatible with
improvements to the Bitcoin protocol.

I hope that even those of us who would strongly prefer that
ASICBOOST be blocked completely can come together to support
a protective measure that separates concerns by inhibiting
the covert use of it that potentially blocks protocol improvements.

The specific activation height is something I currently don't have
a strong opinion, so I've left it unspecified for the moment.


  BIP: TBD
  Layer: Consensus
  Title: Inhibiting a covert attack on the Bitcoin POW function
  Author: Greg Maxwell 
  Status: Draft
  Type: Standards Track
  Created: 2016-04-05
  License: PD


==Abstract==

This proposal inhibits the covert exploitation of a known
vulnerability in Bitcoin Proof of Work function.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

==Motivation==

Due to a design oversight the Bitcoin proof of work function has a potential
attack which can allow an attacking miner to save up-to 30% of their energy
costs (though closer to 20% is more likely due to implementation overheads).

Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
which they have so far not licensed for free and open use by the public.
They have been marketing their patent licenses under the trade-name
ASICBOOST.  The document takes no position on the validity or enforceability
of the patent.

There are two major ways of exploiting the underlying vulnerability: One
obvious way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol.  The covert mechanism is not
easily detected except through its interference with the protocol.

In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.

Exploitation of this vulnerability could result in payoff of as much as
$100 million USD per year at the time this was written (Assuming at
50% hash-power miner was gaining a 30% power advantage and that mining
was otherwise at profit equilibrium).  This could have a phenomenal
centralizing effect by pushing mining out of profitability for all
other participants, and the income from secretly using this
optimization could be abused to significantly distort the Bitcoin
ecosystem in order to preserve the advantage.

Reverse engineering of a mining ASIC from a major manufacture has
revealed that it contains an undocumented, undisclosed ability
to make use of this attack. (The parties claiming to hold a
patent on this technique were completely unaware of this use.)

On the above basis the potential for covert exploitation of this
vulnerability and the resulting inequality in the mining process
and interference with useful improvements presents a clear and
present danger to the Bitcoin system which requires a response.

==Background==

The general idea of this attack is that SHA2-256 is a merkle damgard hash
function which consumes 64 bytes of data at a time.

The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compression
function run-- one that consumes the f

[bitcoin-dev] Proof-of-Loss

[Mirelo via bitcoin-dev]

With the feedback on Proof-of-Loss (always privately to my email), I realized 
the article was hard to understand for lacking:

* A more explicit definition of transaction rights.
* An overview of how the algorithm works.

As an abstract could not contain all that, I wrote an introduction with 
examples.

I also adopted a suggestion of including the current block height in the 
proof-of-loss data once I realized:

* Preventing the same proof-of-loss from chaining consecutive blocks was not 
the purpose of the proof-of-loss context, which did it statistically rather 
than logically.
* The presence of that height in the block header made serial chaining easier 
to enforce, by removing the need to include additional block height information.

While revising the algorithm, I made some corrections, mainly to:

* Transaction prioritization (which now uses fees instead of rights).
* Inactivity fees.

Finally, the new version more aptly derives the design and often has better 
wording.

The new text is available at:

https://proof-of-loss.money/

Mirelo

 Original Message 
Subject: Proof-of-Loss
Local Time: February 4, 2017 10:39 AM
UTC Time: February 4, 2017 12:39 PM
From: mir...@deugh-ausgam-valis.com
To: bitcoin-dev@lists.linuxfoundation.org 


An alternative consensus algorithm to both proof-of-work and proof-of-stake, 
proof-of-loss addresses all their deficiencies, including the lack of an 
organic block size limit, the risks of mining centralization, and the "nothing 
at stake" problem:

https://proof-of-loss.money/___
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

[Christopher Jeffrey via bitcoin-dev]

Hi Johnson,

Really appreciate the comments. I know this idea is your baby.

> so the authors don’t consider segwit as a consensus-layer solution to
> increase transaction throughput, or not think segwit is safe? But
> logically speaking if segwit is not safe, this BIP could only be
> worse. OTOH, segwit also obviously increases tx throughput, although
> it may not be as much as some people wish to have.

Segwit wasn't considered to be a part of that statement. It was
referring to the numerous hardfork proposals we've seen over the past
few years. Segwit is safe, but wouldn't be a comparable block size
increase to what ext. blocks could potentially offer.

> I think extension block in the proposed form actually breaks BIP141.
> It may say it activates segregated witness as a general idea, but not
> a specific proposal like BIP141

Agreed. Needs to be reworded as it currently stands. Though, I suppose
it would be possible to allow for compatibility with segwit in the
mainchain if we utilize your idea of using a separate wit. program
versions for the extension block. A slightly minor change to the spec,
just a big change to the reference impl. code. It is doable.

> This hits the biggest question I asked in my January post: do you want
> to allow direct exit payment to legacy addresses? As a block reorg
> will almost guarantee changing txid of the resolution tx, that will
> permanently invalidate all the child txs based on the resolution tx.
> This is a significant change to the current tx model. To fix this, you
> need to make exit outputs unspendable for up to 100 blocks. Doing
> this, however, will make legacy wallet users very confused as they do
> not anticipate funding being locked up for a long period of time. So
> you can’t let the money sent back to a legacy address directly, but
> sent to a new format address that only recognized by new wallet, which
> understands the lock up requirement. This way, however, introduces
> friction and some fungibility issues, and I’d expect people using
> cross chain atomic swap to exchange bitcoin and xbitcoin

Yes, this issue is probably the biggest edge case in the proposal.

I think there's two possible solutions:

First solution:

Like you said, add a maturity requirement for exiting outputs. Likely
lower than coinbase's 100 block requirement. To solve the issue of
non-upgraded wallets not being aware of this rule and spending early,
have upgraded mempool implementations accept/relay txs that contain
early spends of exits, but not mine them until they are mature. This way
non-upgraded wallets do not end up broadcasting transactions that are
considered invalid to the rest of the network.

Depending on how wallets handle reorgs, a non-upgraded wallet may put
reorg'd spend chains from exits back into an unconfirmed state, when in
reality they should probably delete them or mark them conflicted in some
way. This may be an acceptable compromise as the wallet will still see
the funds as unconfirmed when they really don't exist anymore, but maybe
unconfirmed is good enough. Users are pretty used to dropping
non-confirming txs from their wallet, and this is much better than
legacy wallets seeing there funds as confirmed when they could be
permanently reorged out at any moment.

Second solution:

Move all exiting outputs to the coinbase. This will enforce a 100 block
maturity requirement and non-upgraded wallets will be aware of this.

The first solution might require more implementation, but allows more
flexibility with the maturity requirement. The second solution is
possibly simpler, but sticks to a hard 100 block limit.

> 1. Is it acceptable to have massive txid malleability and transaction
> chain invalidation for every natural happening reorg?  Yes: the
> current spec is ok; No: next question (I’d say no)

Answered above.

> 2. Is locking up exit outputs the best way to deal with the problem?
> (I tried really hard to find a better solution but failed)

You've probably thought about this more than anyone, so I'd say yes, it
may be the only way. Painful, but necessary.

> 3. How long the lock-up period should be? Answer could be anywhere
> from 1 to 100

I imagine having something lower than 100 would be preferable to users,
maybe somewhere in the 5 to 15 range. A 15 block reorg on mainnet is
seriously unlikely unless something strange is happening. A 5 block
reorg is still pretty unlikely, but possible. The coinbase solution only
allows for 100 blocks though.

> 4. With a lock-up period, should it allow direct exit to legacy
> address? (I think it’s ok if the lock-up is short, like 1-2 block. But
> is that safe enough?)

I think so. Adding a kind of special address probably creates more
issues than it solves.

> 5. Due to the fungibility issues, it may need a new name for the
> tokens in the ext-block

I suppose the market will decide whether that's the case.

It's worth noting, if segwit is not activated on the mainchain, it
creates a much bigger incentive to use

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

[Johnson Lau via bitcoin-dev]

> On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun  wrote:
> 
> 
> The concrete parameters chosen in the proposal are: each channel opening
> transaction reserves 700-bytes within _each_ block in the chain until the
> transaction has been closed. 
> 
> 

Why so? It seems you are describing it as a softfork. With hardfork or 
extension block, a new rule could simply grant extra space when the tagged UTXO 
is spent. So if the usual block size limit is 1MB, when the special UTXO is 
made, the block size limit decreases to 1MB-700 byte, and the user has to pay 
for that 700 byte. When it is spent, the block size will become 1MB+700 byte.

But miners or even users may abuse this system: they may try to claim all the 
unused space when the blocks are not congested, or when they are mining empty 
block, and sell those tagged UTXO later. So I think we need to limit the 
reservable space in each block, and deduct more space than it is reserved. For 
example, if 700 bytes are reserved, the deduction has to be 1400 byte.

With BIP68, there are 8 unused bits in nSequence. We may use a few bits to let 
users to fine tune the space they want to reserve. Maybe 1 = 256 bytes

I think this is an interesting idea to explorer and I’d like to include this in 
my hardfork proposal.

___
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

[Christopher Jeffrey via bitcoin-dev]

Hi Luke,

Thank you for the review. Many of these points should definitely be
addressed in the spec. Although extension blocks has working code, the
spec is currently still in a draft state now and could really use all
the feedback it can get. A few rules are still up in the air before we
setup a public testnet for it.

There's understandable confusion about this, but this proposal is not
meant to be a BIP. If it were meant to be a BIP, we still might not have
even submitted it yet as it needs a bit more revision still.

I'm just going to go over a lot of these and explain the reasoning.

> This breaks the ability to spend unconfirmed funds in the same block
> (as is required for CPFP).

Yeah, child-pays-for-parent is practically impossible for exiting
outputs. I don't see a good way around this. We tried to figure out a
decent solution while initially drafting this. It's possible with tons
of trickery, but likely not worth it.

> The extension block's transaction count is not cryptographically
> committed-to anywhere. (This is an outstanding bug in Bitcoin today,
> but impractical to exploit in practice; however, exploiting it in an
> extension block may not be as impractical, and it should be fixed
> given the opportunity.)

Yes. The merkle commitments are something we could definitely improve.
Open to suggestions. Personally, I don't consider myself a merkle
expert.

> This needs to elaborate how the merkle tree is constructed. Are all
> the txids followed by all the wtxids (tx hashes)? Are they alternated?
> Are txid and wtxid trees built independently and merged at the tip?

As of right now, the reference implementation uses the former, but
again, the merkle commitments are something up in the air. It'd be nice
to keep it as flexible as possible for SPV proofs on either the txids or
wxtids.

> Why? This prevents extblock users from sending to bare multisig or
> other various possible destinations. (While static address forms do
> not exist for other types, they can all be used by the payment
> protocol.)

Requiring only p2pkh and p2sh for exits reduces the possibility of more
UTXO set size bloat (at least slightly). Non-standard scripts are a
problem since they cannot be compressed for storage. I don't see it as
important to allow naked multisig outputs. Currently, if users wanted to
use a naked multisig (why?), they can always use the 1mb chain directly.

> Additionally, this forbids datacarrier (OP_RETURN), and forces spam to
> create unprovably-unspendable UTXOs. Is that intentional?

All outputs within the extension block are meant to be witness programs.
This was done for simplicity. The 1mb chain is still usable for any
OP_RETURNs committed to the chain. More thought on this would be good
though.

> > The maximum extension size should be intentionally high.
>
> This has the same "attacks can do more damage than ordinary benefit"
> issue as BIP141, but even more extreme since it is planned to be used
> for future size increases.

> What is a "point"? What does it mean multiplied by a factor of 8? Why
> not just say "8 points"?

Just for consistency of wording.

The notion of cost creates a system of points which are multiplied by a
factor chosen by the witness program version. Unknown witness programs
have a factor of 1. If, in the future, we soft-fork in a new witness
program version, its chosen factor could be 7 or 6. The idea being,
future versions could add less "cost" to the block, allowing for
relaxing dos limits over time via soft-fork.

I would much rather have people arguing over whether to soft-fork dos
limits than whether to hard-fork dos limits.

So the idea here is, we have a hard limit (say 6mb) for quick sanity
checking and DoS prevention, and a soft-forkable soft limit (e.g. 2mb).

Having unknown witness program versions be worth only 1 point does
enable the possibility that a worst case block could be up to the "hard"
max extension size limit. This is also a possibility with segwit, but
yes, less severe with segwit assuming the max ext. block size is above
3mb.

More discussion and running of numbers is probably necessary before we
come up with optimal limits here.

> Please define "accurately counted" here. Is this using BIP16 static
> counting, or accurately counting sigops during execution?

It's meant to refer to BIP16 static counting. I believe the actual
argument passed to the function in Bitcoin Core is called `fAccurate`.
Many other implementations use the same terminology. The counting during
execution proposed by Gavin's hardfork BIP isn't widely implemented as
far as I know.

> Is the size rounded up or down? If down, 72-byte scripts will carry 0
> points...)

Rounded up. The code included this earlier, but I took the whole
weighing against size out temporarily. Will be updated to match the
spec.

> BIPs must be in MediaWiki format, not Markdown. They should be
> submitted for discussion to the bitcoin-dev mailing list, not social
> media and news.

Yeah, that's sort o

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

[Joseph Poon via bitcoin-dev]

On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote:
> I'd appreciate the authors chiming in, but I read the PASDA differently:
> 
> 1) If a transaction is mined with a certain bit set, it reserves 700 bytes
> for that particular block.
> 2) In that space, 2 transactions may happen:
> a) First, a transaction penalizing the "parent" transaction for fraud by
> spending the funds immediately
> b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
> window
> 
> This means during systematic flooding of closing transactions by
> Goldfinger, vigilant watchers of their channels can immediately punish the
> fraud in the same block using (a), and if they are unable to, need to find
> space within two weeks in (b).
> 
> This is really in the LN weeds however, so I'll refrain from evaluating the
> efficacy of such a solution.

Yes, that is correct. I haven't had a chance to review Laolu's summary
yet, haven't had a chance to talk to him today since I was away from the
keyboard for most of the day, would have been unable to review things.

Section "b" above only allows for free riding on the first output of a
transaction with the bit set within the past 2016 blocks. It does not
allow free riding on outputs without that bit set in the transaction.

Additionally, the presumption is that the attacker fills up the
mempool with incorrect prior commitment transactions.

The attack scenario is Mallory asks everyone to open a channel with her.
Mallory only has 1 BTC. With sufficiently low tx fees, Mallory can use
that one bitcoin to open many ~1 BTC channels. All of those channels had
a prior state which Mallory had ~1 BTC, and a current state where she
has none. She broadcasts these thousands of prior states where she has
~1 BTC.

The presumption is the penalty transaction in many cases has a very
small fee, since it is already covered by the commitment.

This mitigates systemic goldfinger attacks since it is unlikely they can
get enough transactions in. Additionally the transactions waiting on the
mempool allows for many to be notified and fill up the first reserved
space. The attacker would likely be attempting to fill up the mempool
(longer block times help here with security!!!). It is presumed that
there is some small amount in reserve so there is some fee reward
covered for enforcing the penalty. This construction allows for the
amount in reserve to be significantly smaller and much more resilient
against even the largest of goldfinger attacks.

(This isn't a full mitigation, as there are certain conditions related
to miner-attacker coordination with high hashpower. Attacker-Miner
coordination is presumed to be out-of-scope, especially in relation to
51% attacks, since it's sort of a moot point, if they have the funds to
mount this attack so that it's profitable, it gets pretty close for them
to have a very significant hashpower anyway.)

I'll add a clarification to the specification on github soon. The intent
of this is to reduce the cost of setting up LN channels with funds in
reserve, with minimal code changes. Future changes which could be
desired if this is usable would be use additional tx flag bits to select
how many outputs in a transaction apply to enable a large payment of
funds pending in-flight.

-- 
Joseph Poon
___
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

[Greg Sanders via bitcoin-dev]

I'd appreciate the authors chiming in, but I read the PASDA differently:

1) If a transaction is mined with a certain bit set, it reserves 700 bytes
for that particular block.
2) In that space, 2 transactions may happen:
a) First, a transaction penalizing the "parent" transaction for fraud by
spending the funds immediately
b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
window

This means during systematic flooding of closing transactions by
Goldfinger, vigilant watchers of their channels can immediately punish the
fraud in the same block using (a), and if they are unable to, need to find
space within two weeks in (b).

This is really in the LN weeds however, so I'll refrain from evaluating the
efficacy of such a solution.

On Wed, Apr 5, 2017 at 10:05 AM, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Y'all,
>
> Thanks to luke-jr and jl2012 for publishing your analysis of the
> xblocks proposal. I'd like to also present some analysis but instead focus
> on the professed LN safety enhancing scheme in the proposal. It's a bit
> underspecified, so I've taken the liberty of extrapolating a bit to fill
> in the gaps to the point that I can analyze it.
>
> TLDR; The xblock proposal includes a sub-proposal for LN which is
> essentially a block-size decrease for each open channel within the network.
> This decrease reserves space in blocks to allow honest parties guaranteed
> space in the blocks to punish dishonest channel counter parties. As a
> result
> the block size is permanently decreased for each channel open. Some may
> consider this cost prohibitively high.
>
> >> If the second highest transaction version bit (30th bit) is set to to
> `1`
> >> within an extension block transaction, an extra 700-bytes is reserved on
> >> the transaction space used up in the block.
>
> > Why wouldn't users set this on all transactions?
>
> As the proposal stands now, it seems that users _are_ able to unilaterally
> use this for all their Bitcoin transactions, as there's no additional cost
> to using the smart-contract safety feature outlined in the proposal.
>
> The new safety measures proposed near the end of this xblock proposal
> could itself consume a dedicated document outlining the prior background,
> context, and implications of this new safety feature. Throughout the rest
> of this post, I'll be referring to the scheme as a Pre-Allocated
> Smart-contract Dispute arena (PASDA, chosen because it sounds kinda like
> "pasta", which brings me many keks). It's rather insufficiently described
> and
> under specified as it stands in the proposal. As a result, if one doesn't
> have the necessary prior context, it might've been skipped over entirely
> as it's difficult to extract the sub-proposal from the greater proposal. I
> think I possess the necessary prior context required to required to
> properly analyze the sub-proposal. As a result, I would like to illuminate
> the readers of the ML so y'all may also be able to evaluate this
> sub-proposal independently.
>
>
> ## Background
>
> First, some necessary background. Within LN as it exists today there is
> one particularly nasty systematic risk related to blockchain availability
> in the case of a channel dispute. This risk is clearly outlined in the
> original white paper, and in my opinion a satisfactory solution to the
> risks which safe guard the use of very high-value channels has yet to be
> presented.
>
>
> ### Chain Spam/Censorship Attack Vector
>
> The attack vector mentioned in the original paper is a reoccurring attack
> in systems of this nature: DoS attacks. As it stands today, if a channel
> counterparty is able to (solely, or in collaboration with other attackers)
> prevent one from committing a transaction to the chain, they're able to
> steal money from the honest participant in the channel. The attack
> proceeds something like this:
>
>* Mallory opens a very large channel with me.
>* We transfer money back and forth in the channel as normal. The nature
>  of these transfers isn't very important. The commitment balances may
>  be modified due to Mallory making multi-hop payments through my
>  channel, or possibly from Mallory directly purchasing some goods I
>  offer, paying via the channel.
>* Let's call the current commitment number state S_i. In the lifetime
>  of the channel there may exist some state S_j (i < j) s.t Mallory's
>  balance in S_i, is larger than S_j.
>* At this point, depending on the value of the channel's time-based
>  security parameter (T) it may be possible for Mallory to broadcast
>  state S_i (which has been revoked), and prevent me being able to
>  include by my punishment transaction (PTX) within the blockchain.
>* If Mallory is able to incapacitate me for a period of time T, or
>  censor my transactions from the chain (either selectively or via a
>  spam attack), then at time K (K > T + B, wher

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

[Thomas Kerin via bitcoin-dev]

A schism is just that: miners can't ameliorate a HF transition in the way they 
can censor transactions without permission. This is how miners became a 
convenient way to activate soft-forks. 

So while BIP9 can indicate the later censorship (a soft fork) in a way that 
nodes can follow (or not) a hardfork always requires nodes to upgrade to the 
version increasing the degrees of freedom of the system. 

Signaling is less useful here: the change is not opt-in and will require 
coordination; and the continuation of the chain thereafter depends on people 
actually running the hard-fork code, not just being aware there is something 
happening.


On 04/05/2017 12:08 PM, Tom Zander via bitcoin-dev wrote:

On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote: 

BIP 9 provides a mechanism for having miners coordinate softforks because they 
can make the upgrade process smoother this way. But the same is not true of 
hardforks: miners are essentially irrelevant to them, and cannot make the 
process any smoother. 

Can you explain how miners are irrelevant if the upgrade is not a soft fork? 



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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

[Olaoluwa Osuntokun via bitcoin-dev]

Hi Y'all,

Thanks to luke-jr and jl2012 for publishing your analysis of the
xblocks proposal. I'd like to also present some analysis but instead focus
on the professed LN safety enhancing scheme in the proposal. It's a bit
underspecified, so I've taken the liberty of extrapolating a bit to fill
in the gaps to the point that I can analyze it.

TLDR; The xblock proposal includes a sub-proposal for LN which is
essentially a block-size decrease for each open channel within the network.
This decrease reserves space in blocks to allow honest parties guaranteed
space in the blocks to punish dishonest channel counter parties. As a result
the block size is permanently decreased for each channel open. Some may
consider this cost prohibitively high.

>> If the second highest transaction version bit (30th bit) is set to to `1`
>> within an extension block transaction, an extra 700-bytes is reserved on
>> the transaction space used up in the block.

> Why wouldn't users set this on all transactions?

As the proposal stands now, it seems that users _are_ able to unilaterally
use this for all their Bitcoin transactions, as there's no additional cost
to using the smart-contract safety feature outlined in the proposal.

The new safety measures proposed near the end of this xblock proposal
could itself consume a dedicated document outlining the prior background,
context, and implications of this new safety feature. Throughout the rest
of this post, I'll be referring to the scheme as a Pre-Allocated
Smart-contract Dispute arena (PASDA, chosen because it sounds kinda like
"pasta", which brings me many keks). It's rather insufficiently described
and
under specified as it stands in the proposal. As a result, if one doesn't
have the necessary prior context, it might've been skipped over entirely
as it's difficult to extract the sub-proposal from the greater proposal. I
think I possess the necessary prior context required to required to
properly analyze the sub-proposal. As a result, I would like to illuminate
the readers of the ML so y'all may also be able to evaluate this
sub-proposal independently.


## Background

First, some necessary background. Within LN as it exists today there is
one particularly nasty systematic risk related to blockchain availability
in the case of a channel dispute. This risk is clearly outlined in the
original white paper, and in my opinion a satisfactory solution to the
risks which safe guard the use of very high-value channels has yet to be
presented.


### Chain Spam/Censorship Attack Vector

The attack vector mentioned in the original paper is a reoccurring attack
in systems of this nature: DoS attacks. As it stands today, if a channel
counterparty is able to (solely, or in collaboration with other attackers)
prevent one from committing a transaction to the chain, they're able to
steal money from the honest participant in the channel. The attack
proceeds something like this:

   * Mallory opens a very large channel with me.
   * We transfer money back and forth in the channel as normal. The nature
 of these transfers isn't very important. The commitment balances may
 be modified due to Mallory making multi-hop payments through my
 channel, or possibly from Mallory directly purchasing some goods I
 offer, paying via the channel.
   * Let's call the current commitment number state S_i. In the lifetime
 of the channel there may exist some state S_j (i < j) s.t Mallory's
 balance in S_i, is larger than S_j.
   * At this point, depending on the value of the channel's time-based
 security parameter (T) it may be possible for Mallory to broadcast
 state S_i (which has been revoked), and prevent me being able to
 include by my punishment transaction (PTX) within the blockchain.
   * If Mallory is able to incapacitate me for a period of time T, or
 censor my transactions from the chain (either selectively or via a
 spam attack), then at time K (K > T + B, where B is the time the
 commitment transaction was stamped in the chain), then she'll be free
 to walk away with her settled balance at state S_i. For the sake of
 simplicity, we're ignoring HTLC's.
   * Mallory's gain is the difference between the balance at state S_i and
 S_j. Deepening on the gap between the states, my settled balance at
 state S_i and the her balance delta, she may be able to fully recoup
 the funds she initially place in the channel.


### The Role of Channel Reserves as Partial Mitigation

A minor mitigation to this attack that's purely commitment transaction
policy is to mandate that Mallory's balance in the channel never dips
below some reserve value R. Otherwise, if at state S_j, Mallory has a
settled balance of 0 within he channel (all the money if on my side), then
the attack outline above can under certain conditions be _costless_ from
her PoV. Replicate this simultaneously across the network in a synchronized
manner (possibly getting some help from your min

Re: [bitcoin-dev] A different approach to define and understand softforks and hardforks

[greg misiorek via bitcoin-dev]

I'm not an expert to refute this classification, but would love to see those 
points addressed by those in the know, without resorting to ad hominem, even 
though I know it's really hard.

thx, gm

From: Johnson Lau via bitcoin-dev
Sent: ‎4/‎5/‎2017 6:28 AM
To: bitcoin-dev
Subject: [bitcoin-dev] A different approach to define and understand softforks 
and hardforks

Softforks and hardforks are usually defined in terms of block validity (BIP99): 
making valid blocks invalid is a softfork, making invalid blocks valid is a 
hardfork, and SFs are usually considered as less disruptive as it is considered 
to be “opt-in”. However, as shown below this technical definition could be very 
misleading. Here I’m trying to redefine the terminology in terms of software 
upgrade necessity and difficulty.

Softforks are defined as consensus rule changes that non-upgraded software will 
be able to function exactly as usual, as if the rule changes have never happened

Hardforks are defined as consensus rule changes that non-upgraded software will 
cease to function or be severely handicapped

SFs and HFs under this definitions is a continuum, which I call it 
“hardfork-ness”. A pure softfork has no hardfork-ness.

*Mining node

Under this definitions, for miners, any trivial consensus rule changes is 
somewhat a hardfork, as miners can’t reliably use non-upgraded software to 
create blocks. However, there is still 3 levels of “hardfork-ness”, for example:

1. Those with lower hardfork-ness would be the SFs that miners do not need to 
upgrade their software at all. Instead, the minimum requirement is to setup a 
boarder node with latest rules to make sure they won’t mine on top of an 
invalid block. Examples include CSV and Segwit

2. Some SFs have higher hardfork-ness, for example BIP65 and BIP66. The minimum 
actions needed include setting up a boarder node and change the block version. 
BIP34 has even higher hardfork-ness as more actions are needed to follow the 
new consensus.

3. Anything else, ranging from simple HFs like BIP102 to complete HFs like 
spoonnet, or soft-hardfork like forcenet, have the highest hardfork-ness. In 
these cases, boarder nodes are completely useless. Miners have to upgrade their 
servers in order to stay with the consensus.

*Non-mining full node

Similarly, in terms of non-mining full node, as the main function is to 
fully-validate all applicable rules on the network, any consensus change is a 
hardfork for this particular function. However, a technical SF would have much 
lower hardfork-ness than a HF, as a border node is everything needed in a SF. 
Just consider a company has some difficult-to-upgrade software that depends on 
Bitcoin Core 0.8. Using a 0.13.1+ boarder node will make sure they will always 
follow the latest rules. In case of a HF, they have no choice but to upgrade 
the backend system.

So we may use the costs of running a boarder node to further define the 
hardfork-ness of SFs, and it comes to the additional resources needed:

1. Things like BIP34, 65, 66, and CSV involves trivial resources use so they 
have lowest hardfork-ness.

2. Segwit is higher because of increased block size.

3. Extension block has very high hardfork-ness as people may not have enough 
resources to run a boarder node.

* Fully validating wallets

In terms of the wallet function in full node, without considering the issues of 
validation, the hardfork-ness could be ranked as below:

1. BIP34, 65, 66, CSV, segwit all have no hardfork-ness for wallets. 
Non-upgraded wallets will work exactly in the same way as before. Users won’t 
notice any change at all. (In some cases they may not see a new tx until it has 
1 confirmation, but this is a mild issue and 0-conf is unsafe anyway)

2. Extension block, as presented in my January post ( 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html
 ), has higher hardfork-ness, as users of legacy wallets may find it difficult 
to receive payments from upgraded wallet. However, once they got paid, the user 
experience is same as before

3. Another extension block proposal ( 
https://github.com/tothemoon-org/extension-blocks ) has very high hardfork-ness 
for wallets, as legacy wallets will frequently and suddenly find that incoming 
and outgoing txs becoming invalid, and need to sign the invalidated txs again, 
even no one is trying to double spend.

4. Hardfork rule changes have highest hardfork-ness for full node wallets

I’ll explain the issues with extension block in a separate post in details

* Real SPV wallet

The SPV wallets as proposed by Satoshi should have the ability to fully 
validate the rules when needed, so they could be somehow seen as fully 
validating wallets. So far, real SPV wallet is just vapourware.

* Fake SPV wallet, aka light wallet

All the so-called SPV wallets we have today are fake SP

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

[Tom Zander via bitcoin-dev]

On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:
> BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process
> smoother this way. But the same is not true of hardforks: miners are
> essentially irrelevant to them, and cannot make the process any smoother.

Can you explain how miners are irrelevant if the upgrade is not a soft fork?

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] A different approach to define and understand softforks and hardforks

[Johnson Lau via bitcoin-dev]

Softforks and hardforks are usually defined in terms of block validity (BIP99): 
making valid blocks invalid is a softfork, making invalid blocks valid is a 
hardfork, and SFs are usually considered as less disruptive as it is considered 
to be “opt-in”. However, as shown below this technical definition could be very 
misleading. Here I’m trying to redefine the terminology in terms of software 
upgrade necessity and difficulty.

Softforks are defined as consensus rule changes that non-upgraded software will 
be able to function exactly as usual, as if the rule changes have never happened

Hardforks are defined as consensus rule changes that non-upgraded software will 
cease to function or be severely handicapped

SFs and HFs under this definitions is a continuum, which I call it 
“hardfork-ness”. A pure softfork has no hardfork-ness.

*Mining node

Under this definitions, for miners, any trivial consensus rule changes is 
somewhat a hardfork, as miners can’t reliably use non-upgraded software to 
create blocks. However, there is still 3 levels of “hardfork-ness”, for example:

1. Those with lower hardfork-ness would be the SFs that miners do not need to 
upgrade their software at all. Instead, the minimum requirement is to setup a 
boarder node with latest rules to make sure they won’t mine on top of an 
invalid block. Examples include CSV and Segwit

2. Some SFs have higher hardfork-ness, for example BIP65 and BIP66. The minimum 
actions needed include setting up a boarder node and change the block version. 
BIP34 has even higher hardfork-ness as more actions are needed to follow the 
new consensus.

3. Anything else, ranging from simple HFs like BIP102 to complete HFs like 
spoonnet, or soft-hardfork like forcenet, have the highest hardfork-ness. In 
these cases, boarder nodes are completely useless. Miners have to upgrade their 
servers in order to stay with the consensus.

*Non-mining full node

Similarly, in terms of non-mining full node, as the main function is to 
fully-validate all applicable rules on the network, any consensus change is a 
hardfork for this particular function. However, a technical SF would have much 
lower hardfork-ness than a HF, as a border node is everything needed in a SF. 
Just consider a company has some difficult-to-upgrade software that depends on 
Bitcoin Core 0.8. Using a 0.13.1+ boarder node will make sure they will always 
follow the latest rules. In case of a HF, they have no choice but to upgrade 
the backend system.

So we may use the costs of running a boarder node to further define the 
hardfork-ness of SFs, and it comes to the additional resources needed:

1. Things like BIP34, 65, 66, and CSV involves trivial resources use so they 
have lowest hardfork-ness.

2. Segwit is higher because of increased block size.

3. Extension block has very high hardfork-ness as people may not have enough 
resources to run a boarder node.

* Fully validating wallets

In terms of the wallet function in full node, without considering the issues of 
validation, the hardfork-ness could be ranked as below:

1. BIP34, 65, 66, CSV, segwit all have no hardfork-ness for wallets. 
Non-upgraded wallets will work exactly in the same way as before. Users won’t 
notice any change at all. (In some cases they may not see a new tx until it has 
1 confirmation, but this is a mild issue and 0-conf is unsafe anyway)

2. Extension block, as presented in my January post ( 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html
 

 ), has higher hardfork-ness, as users of legacy wallets may find it difficult 
to receive payments from upgraded wallet. However, once they got paid, the user 
experience is same as before

3. Another extension block proposal ( 
https://github.com/tothemoon-org/extension-blocks 
 ) has very high 
hardfork-ness for wallets, as legacy wallets will frequently and suddenly find 
that incoming and outgoing txs becoming invalid, and need to sign the 
invalidated txs again, even no one is trying to double spend.

4. Hardfork rule changes have highest hardfork-ness for full node wallets

I’ll explain the issues with extension block in a separate post in details

* Real SPV wallet

The SPV wallets as proposed by Satoshi should have the ability to fully 
validate the rules when needed, so they could be somehow seen as fully 
validating wallets. So far, real SPV wallet is just vapourware.

* Fake SPV wallet, aka light wallet

All the so-called SPV wallets we have today are fake SPV according to 
whitepaper definition. Since they validate nothing, the hardfork-ness profile 
is very different:

1. BIP34, 65, 66, CSV, segwit has no hardfork-ness for light wallets. Block 
size HF proposals (BIP10x) and Bitcoin Unlimited also have no hardfork-ness 
(superficially, but not philosophically). Along the same line, even an 
inflation hard

[bitcoin-dev] Base Size Increase and Segregated Witness with Discount Governors (SW-DGov) Hardfork

[Oliver Petruzel via bitcoin-dev]

Evening all,

The following BIP submission summarizes an idea that I've been tossing
around for the last year.  I understand that there may be nuances to SegWit
and current consensus layer mechanisms that I may not fully understand, so
please do not hesitate to shred the following text to pieces (I can handle
it, I promise!).

Please note that this BIP assumes failure of the current softfork version
of SegWit to activate in November -- something that I personally do not
wish to see(!). However, given the real possibility of that happening, or
perhaps just some newfound willingness (by "the community") to support a
hardfork in lieu of a stalemate, I figure now is as good a time as any to
share the idea in black and white.

I would really appreciate any/all feedback from the dev community on the
technical merits (read: feasibility) of the idea. I would especially
appreciate feedback from the SegWit developers who designed the current
implementation in 0.14, as they likely have the most intimate knowledge of
SegWit's nuances, and the entire BIP below would likely rely on their
willingness to develop a hardfork version.

Nothing in this BIP is set in stone -- including all values and timelines
-- but, I do hope the following text effectively captures the gist of the
idea, and I do thank you ahead of time for your consideration of the
proposal.


Respectfully,
Oliver Petruzel

---

BIP:  TBD
Layer: Consensus (hard fork)
Title: Base Size Increase and Segregated Witness with Discount Governors
(SW-DGov) Hardfork
Author: Oliver Petruzel 
Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2017-04-05
License: PD

Abstract

This BIP proposes a method of combining an immediate base size increase to
2MB and a hardfork version of Segregated Witness (SegWit).  The SegWit
portion of the hardfork will leverage Discount Governors to control (or
“govern”) the pace of the increase over a period of 145,152 blocks
(approximately three (3) years).


Motivation

Given the possibility of the current softfork version of SegWit failing to
activate in November 2017, this BIP aims to provide a hardfork alternative
that would provide every user in the ecosystem with the fixes and changes
they need to move forward with other great projects, while also tightly
controlling the rate at which the total weight of blocks increases during
the next three years.  The predictable nature of the increases will provide
miners, full node operators, and other users of the system with the ability
to plan their development, resources, and operations accordingly.  The
fixed nature of the increases will also allow all full nodes to maintain a
fixed set of rules for block validity (consensus).


Specification

The following changes will be made to the client:

* An immediate increase of base size to 2,000,000 bytes (perhaps leveraging
code changes similar to those described in BIP 109).

· A hardfork version of SegWit that maintains all of the fixes present in
the softfork version, including (but not limited to):
- Fix for the Malleability issue
- Linear scaling of sighash operations
- Signing of input values
- Increased security for multisig via pay-to-script-hash (P2SH)
- Script versioning
- Reducing UTXO growth
- Moving towards a single combined block limit

* In addition to those fixes listed above, the hardfork version of SegWit
will include the following:

- Rather than using the fixed (75%) Discount found in the softfork version
of SegWit, the hardfork version will leverage Discount Governing to control
the pace of total block weight increases over a three (3) year period of
time.  The use of Discount Governors will allow a steady increase over that
period from an immediate 2MB to 8MB total.  There are several ways these
increases can be handled – either by hardcoding the scheduled increases in
the initial hardfork, or perhaps using subsequent softforks (additional
input/discussion needed on the best way to handle the increases.
- Example increase schedule: +12.5% every 24,192 blocks (roughly every six
(6) months).  The increases would cap at the same 75% Discount rate found
in the current softfork version of SegWit.
- Each time the Discount increases – every 24,192 blocks -- the Total Block
Weight value would also increase to appropriately compensate for the added
Discount.


Rationale

This hardfork employs a simple flag day deployment based on the median
timestamp of previous blocks. Beyond this point, supporting nodes will not
accept blocks with original rules.  This ensures a deterministic and
permanent departure with the original rules.

The use of Discount Governors to control the pace of the increase will
result in a predictable and stable increase over the period of three (3)
years.

If, at any time, the increases present problems for the network -- such as
centralization concerns, negative impacts on the fee market(s), or