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

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

Opinion: Lock in a blockheight to get rid of it 10 years in the future. Use it 
as press that Bitcoin is going to lose $1,000,000 if some mystery person does 
not put their transaction through by then, try for global presses. Use the 
opportunity to get rid of it while you are able. Once gazetted anything is 
public knowledge.

Regards,
LORD HIS EXCELLENCY JAMES HRMH


From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Matt Corallo via 
bitcoin-dev 
Sent: Saturday, 9 March 2019 7:14 AM
To: Sjors Provoost
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great 
Consensus Cleanup

Aside from the complexity issues here, note that for a user to be adversely 
affect, they probably have to have pre-signed lock-timed transactions. 
Otherwise, in the crazy case that such a user exists, they should have no 
problem claiming the funds before activation of a soft-fork (and just switching 
to the swgwit equivalent, or some other equivalent scheme). Thus, adding 
additional restrictions like tx size limits will equally break txn.

> On Mar 8, 2019, at 14:12, Sjors Provoost  wrote:
>
>
>> (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 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

[Jacob Eliosoff via bitcoin-dev]

>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>

This principle was only ever a rule of thumb to protect users, not a
commandment from God.  It shouldn't be violated lightly, but that's why
Matt did the legwork to show that the tradeoffs around OP_CODESEPARATOR
justify removing it.

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?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years.  Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do.  Perhaps others don't want to risk
> blowing their pseudonymity.  Perhaps they think that attempting to undo
> some of these non-standardness changes is futile.  I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>

Like Matt, I understand non-standardness to be specifically for making a
transaction type more difficult to set the stage for a future disabling.

If anyone is actually harmed by this change, let them at least speak up
pseudonymously as others have before.  Backwards compatibility shouldn't
mean letting imaginary implausible cases veto net-beneficial changes.


On Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Matt,
>
> On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo 
> wrote:
>
>> 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.
>>
>
> No one is required to test their Scripts on a public testnet; they can use
> regtest. Because these transactions are non-standard on mainnet, it could
> take years to arrange for these funds to be recovered by having their
> transactions mined directly, or take years to become valuable enough to be
> worth bothering having them directly mined.  As I have noted elsewhere, you
> cannot first make transactions non-standard and then use the fact that you
> don't see them being used on mainnet to justify a soft-fork.
>
> My argument isn't weird; it is principled.  You are skeptical that any
> uses of OP_CODESEPARATOR have P2SH commitments.  I am also skeptical, and
> so is everyone reading this mailing list.  But none of us know this with
> certainty, and it is /wrong/ for any of us to gamble with other people's
> money that our assumptions are true.
>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
> The fact that Bitcoin has stuck to this principle gives me and everyone
> else confidence in the protocol; that anyone can secure their funds by
> whatever scheme they dream up, and deploy it 

Re: [bitcoin-dev] Signet

[Karl-Johan Alm via bitcoin-dev]

Hi Lautaro,

Using regtest is not ideal for public networks, as anyone anywhere can
just rewrite the blockchain at their whim by mining a ton of blocks.

On Sun, Mar 10, 2019 at 4:52 AM Lautaro Dragan  wrote:
>
> Hi Karl-Johan, my two cents:
>
> At Po.et we use regtest to simulate reorgs in integration tests in Travis / 
> CircleCI. It has proved quite useful.
>
> In general regtest for automated testing has given us all we needed so far, 
> but I admit we have a rather simple use of Bitcoin right now (colored coins).
>
> For local development, we sometimes use a script that "mines" blocks in 
> regtest periodically. It was my goal to also use this method in QA, although 
> we wound up using testnet and didn't encounter any problems so far.
>
> Out of curiosity: what limitations did you find in using, for example, a 
> private network of bitcoin core nodes running regtest? (this gives you the 
> same power as centralization without any changes or extra functionality 
> required)
>
> El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev 
>  escribió:
>>
>> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Signet

[Karl-Johan Alm via bitcoin-dev]

Hi Matt,

On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo  wrote:
>
> To make testing easier, it may make sense to keep the existing block header 
> format (and PoW) and instead apply the signature rules to some field in the 
> coinbase transaction. This means SPV clients (assuming they only connect to 
> honest/trusted nodes) work as-is.

Keeping the PoW rule and moving the signature would mean DoS attacks
would be trivial as anyone could mine blocks without a signature in
them, unless you ramped up the difficulty, which would mean it's just
another testnet. It's a test network, admittedly, but I think it would
kind of defeat the purpose.

> A previous idea regarding reorgs (that I believe Greg came up with) is to 
> allow multiple keys to sign blocks, with one signing no reorgs and one 
> signing a reorg every few blocks, allowing users to choose the behavior they 
> want.

Not sure how this would work in practice. The idea with signet is to
have an actual network that is occasionally reorged, i.e. it's a
global network (for those participating) that everyone agrees on. Not
sure how you would have choices there.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev