Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Sjors Provoost via bitcoin-dev]

> (1) It has been well documented again and again that there is desire to 
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in 
> non-segwit scripts represents a rather significant vulnerability in Bitcoin 
> today, and (3) lots of effort has gone into attempting to find practical 
> use-cases for OP_CODESEPARATOR's specific construction, with no successes as 
> of yet. I strongly, strongly disagree that the highly-unlikely remote 
> possibility that someone created something before which could be rendered 
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
> 
>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases 
>> the transactions weight suitably as to temper the vulnerability caused by 
>> it.  Alternatively there could be some sort of limit (maybe 1) on the 
>> maximum number of OP_CODESEPARATORs allowed to be executed per script, but 
>> that would require an argument as to why exceeding that limit isn't 
>> reasonable.
> 
> You could equally argue, however, that any such limit could render some 
> moderately-large transaction unspendable, so I'm somewhat skeptical of this 
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined 
> is rather difficult in any case.

Although I'm not a fan of extra complicity, just to explore these two ideas a 
bit further.

What if such a transaction:

1. must have one input; and
2. must be smaller than 400 vbytes; and
3. must spend from a UTXO older than fork activation

Adding such a contextual check seems rather painful, perhaps comparable to 
nLockTime. Anything more specific than the above, e.g. counting the number of 
OP_CODESEPARATOR calls, seems like guess work.

Transaction weight currently doesn't consider OP codes, it only considers if 
bytes are part of the witness. Changing that to something more akin to 
Ethereums gas pricing sounds too complicated to even consider.


I would also like to believe that whoever went through the trouble of using 
OP_CODESEPARATOR reads this list.

Sjors

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

[bitcoin-dev] Signet

[Karl-Johan Alm via bitcoin-dev]

Hello,

As some of you already know, I've been working on a network called
"signet", which is bascially a complement to the already existing testnet,
except it is completely centralized, and blocks are signed by a specific
key rather than using proof of work.

Benefits of this:

1. It is more predictable than testnet. Miners appear and disappear
regularly, causing irregular block generation.

2. Since it is centrally controlled, it is easy to perform global testing,
such as reorgs (e.g. the network performs a 4 block reorg by request, or as
scheduled).

3. It is more stable than testnet, which occasionally sees several thousand
block reorgs.

4. It is trivial to spin up (and shut down) new signets to make public
tests where anyone can participate.

Anyone can create a signet at any time, simply by creating a key pair and
creating a challenge (scriptPubKey). The network can then be used globally
by anyone, assuming the creator sends some coins to the other participants.

Having a persistent signet would be beneficial in particular to services
which need a stable place to test features over an extended period of time.
My own company implements protocols on top of Bitcoin with sidechains. We
need multi-node test frameworks to behave in a predictable manner (unlike
testnet) and with the same standardness relay policy as mainnet.

Signets consist of 2 parameters: the challenge script (scriptPubKey) and
the solution length. (The latter is needed to retain fixed length block
headers, despite having an additional payload.)

I propose that a default persistent "signet1" is created, which can be
replaced in future versions e.g. if the coins are unwisely used as real
money, similarly to what happened to previous testnets. This signet is
picked by default if a user includes -signet without providing any of the
parameters mentioned above. The key holder would be someone sufficiently
trusted in the community, who would be willing to run the system (block
generation code, faucet, etc). It could be made a little more sturdy by
using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers
disappear. If people oppose this, it can be skipped, but will mean people
can't just jump onto signet without first tracking down parameters from
somewhere.

Implementation-wise, the code adds an std::map with block hash to block
signature. This is serialized/deserialized as appropriate (Segwit witness
style), which means block headers in p2p messages are (80 +
solution_length) bytes. Block header non-contextual check goes from
checking if block header hash < target to checking if the payload is a
valid signature for the block header hash instead.

Single commit with code (will split into commits and make PR later, but
just to give an idea what it looks like):
https://github.com/kallewoof/bitcoin/pull/4

I don't think this PR is overly intrusive, and I'm hoping to be able to get
signet code into Bitcoin Core eventually, and am equally hopeful that devs
of other (wallet etc) implementations will consider supporting it.

Feedback requested on this.

Attribution: parts of the signet code (in particular signblock and
getnewblockhex) were adapted from the ElementsProject/elements repository.
When PR is split into atomic commits, I will put appropriate attribution
there.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo via bitcoin-dev]

Replies inline.

On 3/8/19 3:57 PM, Russell O'Connor wrote:
On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo > wrote:

It's very easy to construct a practical script using OP_CODESEPARATOR.

IF <2>   <2> CHECKMULTISIGVERIFY ELSE 
CODESEPARATOR  CHECKSIGVERFY ENDIF


Now when someone hands Alice, the CFO of XYZ corp., some transaction, 
she has the option of either signing it unilaterally herself, or 
creating a partial signature such that the transaction additionally 
needs Bob, the CEOs signature as well, and Alice's choice is committed 
to the blockchain for auditing purposes later.


Now, there are many things you might object about this scheme, but my 
point is that (A) regardless of what you think about this scheme, it, or 
similar schemes, may have been devised by users, and (B) users may have 
already committed funds to such schemes, and due to P2SH you cannot know 
that this is not the case.


The common way to set that up is to have a separate key, but, ok, fair 
enough. That said, the argument that "it may be hidden by P2SH!" isn't 
sufficient here. It has to *both* be hidden by P2SH and have never been 
spent from (either on mainnet or testnet) or be lock-timed a year in the 
future. I'm seriously skeptical that someone is using a highly esoteric 
scheme and has just been pouring money into it without ever having 
tested it or having withdrawn any money from it whatsoever. This is just 
a weird argument.



Please don't strawman my position.  I am not suggesting we don't fix a 
vulnerability in Bitcoin.  I am suggesting we find another way.  One 
that limits the of risk destroying other people's money.


Here is a more concrete proposal:  No matter how bad OP_CODESEPARATOR 
is, it cannot be worse than instead including another input that spends 
another identically sized UTXO.  So how about we soft-fork in a rule 
that says that an input's weight is increased by an amount equal to the 
number of OP_CODESEPARATORs executed times the sum of weight of the UTXO 
being spent and 40 bytes, the weight of a stripped input. The risk of 
destroying other people's money is limited and AFAIU it would completely 
address the vulnerabilities caused by OP_CODESEPARATOR.


You're already arguing that someone has such an esoteric use of script, 
suggesting they aren't *also* creating pre-signed, long-locktimed 
transactions with many inputs isn't much of a further stretch 
(especially since this may result in the fee being non-standardly low if 
you artificially increase its weight).


Note that "just limit number of OP_CODESEPARATOR calls" results in a ton 
of complexity and reduces the simple analysis that fees (almost) have 
today vs just removing it allows us to also remove a ton of code.


Further note that if you don't remove it getting the efficiency wins 
right is even harder because instead of being able to cache sighashes 
you now have to (at a minimum) wipe the cache between each 
OP_CODESEPARATOR call, which results in a ton of additional 
implementation complexity.




 > I suggest an alternative whereby the execution of OP_CODESEPARATOR
 > increases the transactions weight suitably as to temper the
 > vulnerability caused by it.  Alternatively there could be some
sort of
 > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
allowed to be
 > executed per script, but that would require an argument as to why
 > exceeding that limit isn't reasonable.

You could equally argue, however, that any such limit could render some
moderately-large transaction unspendable, so I'm somewhat skeptical of
this argument. Note that OP_CODESEPARATOR is non-standard, so getting
them mined is rather difficult in any case.


I already know of people who's funds are tied up due to in other changes 
to Bitcoin Core's default relay policy.  Non-standardness is not an 
excuse to take other people's tied up funds and destroy them permanently.


Huh?! The whole point of non-standardness in this context is to (a) make 
soft-forking something out safer by derisking miners not upgrading right 
away and (b) signal something that may be a candidate for soft-forking 
out so that we get feedback. Who is getting things disabled who isn't 
bothering to *tell* people that their use-case is being hurt?!

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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor via bitcoin-dev]

On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo 
wrote:

> Replies inline.
>
> Matt
>
> On 3/7/19 3:03 PM, Russell O'Connor wrote:
> >
> > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script
> validation.
> > This includes OP_CODESEPARATORs in unexecuted branches of if
> > statements,
> > similar to other disabled opcodes, but unlike OP_RETURN.
> >
> >
> > OP_CODESEPARATOR is the only mechanism available that allows users to
> > sign which particular branch they are authorizing for within scripts
> > that have multiple possible conditions that reuse the same public key.
>
> This is true, and yet it does not appear to actually be practically
> usable. Thus far, despite a ton of effort, I have not yet seen a
> practical use-case for OP_CODESEPARATOR (except for one example of it
> being used to make SegWit scripts ever-so-slightly more effecient in
> TumbleBit, hence why this BIP does not propose disabling it for SegWit).
>

It's very easy to construct a practical script using OP_CODESEPARATOR.

IF <2>   <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR
 CHECKSIGVERFY ENDIF

Now when someone hands Alice, the CFO of XYZ corp., some transaction, she
has the option of either signing it unilaterally herself, or creating a
partial signature such that the transaction additionally needs Bob, the
CEOs signature as well, and Alice's choice is committed to the blockchain
for auditing purposes later.

Now, there are many things you might object about this scheme, but my point
is that (A) regardless of what you think about this scheme, it, or similar
schemes, may have been devised by users, and (B) users may have already
committed funds to such schemes, and due to P2SH you cannot know that this
is not the case.


> > Because of P2SH you cannot know that no one is currently using this
> > feature.  Activating a soft-fork as describe above means these sorts of
> > funds would be permanently lost.  It is not acceptable to risk people's
> > money like this.
>
> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in
> Bitcoin today, and (3) lots of effort has gone into attempting to find
> practical use-cases for OP_CODESEPARATOR's specific construction, with
> no successes as of yet. I strongly, strongly disagree that the
> highly-unlikely remote possibility that someone created something before
> which could be rendered unspendable is sufficient reason to not fix a
> vulnerability in Bitcoin today.
>

Please don't strawman my position.  I am not suggesting we don't fix a
vulnerability in Bitcoin.  I am suggesting we find another way.  One that
limits the of risk destroying other people's money.

Here is a more concrete proposal:  No matter how bad OP_CODESEPARATOR is,
it cannot be worse than instead including another input that spends another
identically sized UTXO.  So how about we soft-fork in a rule that says that
an input's weight is increased by an amount equal to the number of
OP_CODESEPARATORs executed times the sum of weight of the UTXO being spent
and 40 bytes, the weight of a stripped input. The risk of destroying other
people's money is limited and AFAIU it would completely address the
vulnerabilities caused by OP_CODESEPARATOR.

Even soft forking a rule like, "it is illegal to execute an
OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation", would be
vastly better than the current proposal, even though I would still object
to it.


> > I suggest an alternative whereby the execution of OP_CODESEPARATOR
> > increases the transactions weight suitably as to temper the
> > vulnerability caused by it.  Alternatively there could be some sort of
> > limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be
> > executed per script, but that would require an argument as to why
> > exceeding that limit isn't reasonable.
>
> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of
> this argument. Note that OP_CODESEPARATOR is non-standard, so getting
> them mined is rather difficult in any case.
>

I already know of people who's funds are tied up due to in other changes to
Bitcoin Core's default relay policy.  Non-standardness is not an excuse to
take other people's tied up funds and destroy them permanently.

There is some sort of crisis in the Bitcoin protocol stemming from the
possible excessive usage of OP_CODESEPARTOR otherwise we wouldn't even be
considering this soft fork.  Fine.  But presumably it is impossible for a
transaction to both be produced in good faith for legitimate use and at the
same time are expensive enough to be used as an attack vector, and
hopefully there is a wide gap between these two cases.  So let's draw a
line between the two cases to rule out attacks while allowing legitimate
uses by simply suitably pricing the 

Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

[Russell O'Connor via bitcoin-dev]

On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo 
wrote:

> I can't say I'm particularly married to this idea (hence the alternate
> proposal in the original email), but at the same time the lack of
> existing transactions using these bits (and the redundancy thereof -
> they don't *do* anything special) seems to be pretty strong indication
> that they are not in use. One could argue a similarity between these
> bits and OP_NOPs - no one is going to create transactions that require
> OP_NOP execution to be valid as they are precisely the kind of thing
> that may get soft-forked to have a new meaning. While the sighash bits
> are somewhat less candidates for soft-forking,


I don't think "somewhat less candidates for soft-forking" is a fair
description.  These bits essentially unsuitable for soft-forking within
legacy Script.

I don't think "someone
> may have shoved random bits into parts of their
> locked-for-more-than-a-year transactions" is sufficient reason to not
> soft-fork something out.


I disagree. It is sufficient.

When was the last time Bitcoin soft-forked out working transactions that
sent funds from securely held UTXOs to securely held UTXOs (aside from
those secured by Scripts using the reserved OP_NOP1-OP_NOP10)?  AFAIK it
has never occurred since the time of Satoshi, even for the most
hypothetical of transactions.  It is my understanding is that Bitcoin Core
would never do such a thing unless the security of Bitcoin protocol itself
was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
Core would only soft-fork out the minimal amount necessary to safely
diffuse such a threat.

Since the above soft-fork isn't addressing addressing any such threat (that
I'm aware of), and could hypothetically destroy other people money, it
crosses a line I thought we were never supposed to cross.

>
> Obviously, actually *seeing* it used in
> practice or trying to fork them out in a fast manner would be
> unacceptable, but neither is being proposed here.
>

Perhaps you don't see them in used in the blockchain because the users
trying to use them are caught up by the fact they they are not being
relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
difficulty redeeming them.
You cannot first make transactions non-standard and then use the fact that
you don't see them being used to justify a soft-fork.

I know of users who have their funds tied up due to other changes in
Bitcoin Core's default relay policy.  I believe they waiting for their
funds to become valuable enough to go through the trouble of having them
directly mined.  Shall we now permanently destroy their funds too, before
they have a chance to get their transactions mined?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

[Gregory Maxwell via bitcoin-dev]

On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev
 wrote:
> First and foremost, reject messages are an indication that the
> transaction isn't going to confirm. Without these messages, we'd need to
> revert to pre-BIP61 behaviour of using a timeout for reception of
> network confirmations.

That is already required because even in the presence of perfectly
honest and cooperative hosts reject messages at most can only tell you
about first-hop behaviour. It won't even tell you if the transaction
was ever even attempted to be sent to a next hop.  So alternative
handling must be provided and must be reliable for the software to
work at all regardless of reject messages.

> - Not enough fee

Rejection on low fee (over the static minimum feerate) only happens at
the point where the nodes mempool is full, which is already at a point
where you might be waiting weeks for confirmation.

Rejection causes were also not stable or reliable because the validity
criteria cannot generally be tested independently. For example, if a
transaction is queued due to missing a parent it isn't rejected
because missing the parent is often a temporary issue, but its feerate
cannot be measured without the parent. Later, when the parent is
obtained, the transaction can then be rejected due to feerate-- but no
reject is sent then.

Output already spend is often completely indistinguishable from a
missing parent and can't get rejects generated for it generally.

Similarly, the error state detected for things like invalid signatures
are often not very useful. The software knows that script execution
returned false, but in the general case _why_ it returned false is not
clear, and a straightforward high performance validation
implementation doesn't necessarily yield a good way of figuring out
and propagating up that information.  (I think invalid signatures end
up returning a stack-nonempty state from validation currently, as an
example of that).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev