Re: [bitcoin-dev] Signet

[Karl-Johan Alm via bitcoin-dev]

Hello all,

I started writing code that puts the signature in the coinbase
transaction similar to the witness commitment, and encountered a
potential issue. See inline comments below.

On Mon, Mar 11, 2019 at 2:02 AM David A. Harding  wrote:
>
> On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev 
> wrote:
> > 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
>
> Sure, but anyone could also just connect their lite client to a trusted
> node (or nodes) on signet.  The nodes would protect the clients from
> missing/invalid-signature DoS and the clients wouldn't have to implement
> any more network-level changes than they need to now for testnet.
>
> For people who don't want to run their own trusted signet nodes, there
> could be a list of signet nodes run by well-known Bitcoiners (and this
> could even be made available via a simple static dns seeder lite clients
> could use).

This sounds sensible. One issue here is that the "proper" signer will
be orders of magnitude slower than the fake miner when constructing
blocks. Because the signature is now stuffed into the coinbase
transaction, it becomes a part of the block merkle root, so the true
miner now has to (1) create a block, (2) sign it, (3) check if hash <
target, (4) nudge nonce if not, and then repeat from step (2) until it
finds a valid block. I.e. it has to sign the entire thing for every
nonce.

> This post from Maxwell could be the idea Corallo is describing:
>
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html

That's pretty cool. The plan I had was to set up some simple interface
where anyone could "order" reorgs whenever they wanted to. It would
reorg/double spend people on request (e.g. "send 1 signetcoin to
signet1qfoobar and then double spend it in a reorg 3 blocks deep") and
so on.

With that kind of tool, I don't know if you need the alternate signing
approach you described, but I could be mistaken.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[ZmnSCPxj via bitcoin-dev]

Good morning Alistair,

> It won't have escaped notice that the HTLB script can be wholly written 
> in an
> HTLC script: 'HTLB over HTLC', however there are additional reasons to
> consider HTLB for a separate BIP:

I believe there is indeed an important usecase for HTLB over HTLC, which is to 
improve the anonymity set.
An HTLB over HTLC would be indistinguishable onchain from other uses of HTLC; 
assuming that HTLCs have other uses, this is a (small?) plus to privacy.

Note that the redundant  would have to be given by Alice to Bob, since 
using a standardized one will also reveal use of HTLB over HTLC instead of 
hiding it among other HTLC UTXOs.

Another thing to improve privacy would be to apply the Funding Transaction 
pattern: https://zmnscpxj.github.io/offchain/generalized.html

In such a case, Alice would prepare two transactions, one which pays to a 
2-of-2, and another which spends that 2-of-2 and pays to an HTLB (over HTLC).
Alice would provide the second transaction to Bob, who must return a valid 
signature for that transaction, then place the first transaction onchain.
Then the protocol resumes as normal.
If Alice and Bob both agree that the bond can be returned to Alice, then they 
recreate the second transaction as a normal spend from 2-of-2 to a flat P2PKH 
of Alice (or whatever address Alice desires), obscuring that HTLB was used at 
all.


The Funding Transaction Pattern is applicable to all constructions that have a 
fixed participant set, and is effectively gotten "for free" with Taproot (the 
requirement is the "Taproot assumption"), but is available now even without 
Taproot.

Regards,
ZmnSCPxj
___
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]

I think you may have misunderstood part of the motivation. Yes, part of the 
motivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the 
theoretical operation of checksig operations (thus somewhat simplifying the 
implementation but also simplifying analysis of future changes, such as 
sighash-caching code).

I think a key part of the analysis here is that no one I've spoken to (and 
we've been discussing removing it for *years*, including many attempts at 
coming up with reasons to keep it) is aware of any real proposals to use 
OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid 
pubic keys is a long-discussed-and-implemented idea (despite it's 
discouragement, not to mention it appears on the chain in many places).

It would end up being a huge shame to have all the OP_CORESEPARATOR mess left 
around after all the effort that has gone into removing it for the past few 
years, especially given the stark difference in visibility of a fork when 
compared to a standardness change.

As for your specific proposal of increasing the weight of anything that has an 
OP_CODESEPARATOR in it by the cost of an additional (simple) input, this 
doesn't really solve the issue. After all, if we're assuming some user exists 
who has been using sending money, unspent, to scripts with OP_CODESEPARATOR to 
force signatures to commit to whether some other signature was present and who 
won't see a (invariably media-covered) pending soft-fork in time to claim their 
funds, we should also assume such a user has pre-signed transactions which are 
time-locked and claim a number of inputs and have several paths in the script 
which contain OP_CODESEPARATOR, rendering their transcription invalid.

Matt

> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev 
>  wrote:
> 
> Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limit) 
> + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more 
> (overhead for varints) = 572ish bytes should be enough to completely 
> eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH 
> transactions without the need to remove it ever.  I think it is worth 
> attempting to be a bit more clever than such a blunt rule, but it would be 
> much better than eliminating OP_CODESEPARATOR within P2SH entirely.
> 
> Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal 
> is to eliminate the vulnerability associated with it.
> 
>> On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev 
>>  wrote:
>> What about putting it in a deprecated state for some time. Adjust the 
>> transaction weight so using the op code is more expensive (10x, 20x?) and 
>> get the word out that it will be removed in the future.
>> 
>> You could even have nodes send a reject code with the message 
>> “OP_CODESEPARATOR is depcrecated.”
> ___
> 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

[Russell O'Connor via bitcoin-dev]

Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size
limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few
more (overhead for varints) = 572ish bytes should be enough to completely
eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH
transactions without the need to remove it ever.  I think it is worth
attempting to be a bit more clever than such a blunt rule, but it would be
much better than eliminating OP_CODESEPARATOR within P2SH entirely.

Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal
is to eliminate the vulnerability associated with it.

On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What about putting it in a deprecated state for some time. Adjust the
> transaction weight so using the op code is more expensive (10x, 20x?) and
> get the word out that it will be removed in the future.
>
> You could even have nodes send a reject code with the message
> “OP_CODESEPARATOR is depcrecated.”
>
___
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]

Hi Jacob,


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

It is so easy to say stuff like this when one's own money isn't what is at
risk.

While I encourage users who would be harmed to chime in if they can,
unfortunately, I think it is mostly wishful thinking on our part that they
necessarily would.  In fact, there is evidence that in practice people
don't.

To illustrate this, consider the example of the people affected by PR #5247
, which makes unparsable
public keys non-standard.  As far as I am aware none have commented on this
mailing list about it yet even though I happen to know such people do exist
because I've talked with them on Slack.  I believe the person I spoke with
to took over a year (and probably more than two years) to even notice that
the transactions they want to redeem with are no longer standard.  To be
fair, their money that is stuck due to PR #5247 isn't lost yet, but I'm
skeptical they would think or know to speak up here even if their money was
on the chopping block.  The fact that they haven't been able to move their
money in the last *4 years* doesn't mean they wouldn't like it back one day.

While non-standardness is a helpful in dissuading users from committing new
funds to OP_CODESEPARATOR scripts, it doesn't do anything to help users
that may have been caught unaware by the non-standardness change.
Furthermore, because these transactions are non-standard, anyone caught off
guard by the change is going to have a very hard time redeeming their
funds, as we have already seen with PR #5247, a non-standardness change
that is far older than the OP_CODESERPATOR change in PR #11423
.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[Alistair Mann via bitcoin-dev]

Greetings all, 

I'm looking for thoughts on the BIPability of a relatively minor change, with 
an outsize benefit, with the provisional name 'Hashed Time-Locked Bond', HTLB 
for short.

The minor change is to implement HTLC without its digest element. The outsize 
benefit is to incentivise against spam and other abuse. In this post I'll 
introduce the script, motivation, a working proof-of-concept site, and then 
round out addressing the desirability of a BIP.

Implementation of HTLB:
The script takes the form: 

OP_IF
OP_DUP OP_HASH160 
OP_ELSE
 [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

Notice that this is the script of BIP-0199 with '[HASHOP]  
OP_EQUALVERIFY' removed. 

A worked example. Alice is the buyer and Bob the seller. Alice knows that Bob 
is her father and that he doesn't know her new email address. She commits 
50,000 satoshis to the above script with a 24 hour timeout, then sends proof 
of that transaction along with an email reintroducing herself. Bob's MUA 
recognises that the bond is good and alerts him to the email from a strange 
sender: he knows that if he disagrees with the implicit assertion that he will 
want that email, he has 24 hours to redeem those funds at the sender's 
expense. He reads the email. Bob is incentivised not to redeem against his 
daughter though, and lets the timeout expire: Alice reclaims her funds. Carol 
did not bond at all, so her email was refused at the server. Dave's bond of 
100 satoshis was too small to pass Bob's minimum, so his email too was refused 
at the server. Erin guaranteed 50,000 satoshis each to reach Bob and ten 
thousand others with an email offering triple-glazed windows: she's now well 
on the way to losing them all.

Motivation: 
There is a transaction class we can identify as 'Good Behaviour Bonds' 
currently poorly served in Bitcoin*. Bail bonds and bar tabs are real world 
exemplars. Conceptually, Alice guarantees Bob she will do or be something for 
a fixed period: if she complies Bob refrains from redeeming her guarantee; if 
she does not comply Bob redeems some or all of it. It's inherent to the class 
that Alice is incentivised within the transaction to good behaviour outside 
it. Conversely, Bob is incentivised outside the transaction to good behaviour 
within it. 

In essence, Alice commits funds to a penalty in advance of a connection to 
Bob. Alice is incentivised by getting her funds back, Bob is incentivised by 
her - and others - continued patronage. 

This transaction class can protect any addressable resource. Alice can 
therefore guarantee Bob that:
1. Her email to him is not spam
2. Her telephone call to him is not a robocall
3. Her posts to his website are not flamebait.
In each case this is handled by extending the protocol concerned to detect for 
and change behaviour depending on Alice's proof of bond.

That Alice can guarantee her behaviour to addressable resources means she can 
also guarantee her behaviour to non-addressable resources. She could 
guarantee:
1. a group chat that she won't upload NSFW content
2. an IRC channel that she won't flood
3. a streamed multiplayer game that she won't swear over teamspeak.
This is accomplished by use of an addressable resource and an enforcement 
mechanism such as IRC's devoice command.

Alice can also guarantee her behaviour offline in much the same way. She can 
guarantee to:
1. a magistrate that she'll appear for trial by a given date (Bail bond/ 
Surety)
2. a houseowner that she'll cover costs incurred from cleaning up after her 
(Rental/Security deposit)
3. an innkeeper that she can pay for the drinks she's ordering (Bar tab)
That a transaction has been entered into online can be proved offline, so 
these can be accomplished by means of an online, addressable resource and an 
offline plaintext token.

Live site:

I have put up a live proof-of-concept at http://berewic.com. This protects a 
specific URL accessed through HTTP (the "demo page") whereby visitors who have 
posted bond on testnet3 get different content than those who have not posted 
bond, or whose bond has expired. This is accomplished through an experimental 
protocol where an agent with a hot wallet speaks for a credentialed user in a 
similar way to how SMTP speaks for an email's original sender. That protocol 
would seem to be outside the scope of the proposed BIP but I'm happy to 
elaborate if required.

A short video demonstrating live use of the HTLB is also posted there. 

BIP:

Name: "Hashed Time-Locked Bond" seems a reasonable name - the script is still 
hashed even if the digest is gone, and HTLB nicely scans like HTLC - 1.

It won't have escaped notice that the HTLB script can be wholly written in an 
HTLC script: 'HTLB over HTLC', however there are additional reasons to 
consider HTLB for a separate BIP:
1. Alternative implementations using HTLB over HTLC would need to standardise 
on what the redundant [HASHOP] 

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

[Dustin Dettmer via bitcoin-dev]

What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.

You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”

On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev  wrote:

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

[Moral Agent via bitcoin-dev]

>Lock in a blockheight to get rid of it 10 years in the future.

And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?

On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev  wrote:

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

Re: [bitcoin-dev] Signet

[David A. Harding via bitcoin-dev]

On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> 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

Sure, but anyone could also just connect their lite client to a trusted
node (or nodes) on signet.  The nodes would protect the clients from
missing/invalid-signature DoS and the clients wouldn't have to implement
any more network-level changes than they need to now for testnet.

For people who don't want to run their own trusted signet nodes, there
could be a list of signet nodes run by well-known Bitcoiners (and this
could even be made available via a simple static dns seeder lite clients
could use).

> On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo 
> wrote:
> > 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.

This post from Maxwell could be the idea Corallo is describing:


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html

I read it as:

  - Trusted signer Alice only signs extensions of her previous blocks

  - Trusted signer Bob periodically extends one of Alice's blocks
(either the tip or an earlier block) with a chain that grows faster
than Alice's chain, becoming the most-PoW chain.  At some point he
stops and Alice's chain overtakes Bob's fork as the most-PoW chain

  - User0 who wants to ignore reorg problems starts his node with
-signet -signers="alice", causing his node to only accept blocks
from Alice.

  - User1 who wants to consider reorg problems starts his node with
-signet -signers="alice,bob", causing his node to accept blocks from
both Alice and Bob, thus experiencing periodic reorgs.

  - There can also be other signing keys for any sort of attack
that can be practically executed, allowing clients to test their
response to the attack when they want to but also ignore any
disruption it would otherwise cause the rest of the time.

  - As an alternative to particular signing keys, there could just be
flags put in the header versionbits, header nonce, or generation
transaction indicating how the block should be classified (e.g.
no_reorg, reorg_max6, reorg_max144, merkle_vulnerability, special0,
special1, etc...)

(If something like this is implemented, I propose reserving one of the
signing keys/classification flags for use by any of Bitcoin's more
devious devs in unannounced attacks.  Having to occasionally dig
through weird log messages and odd blocks with other Bitcoin dorks on
IRC in order to figure out why things went horribly sideways in our
signet clients sounds to me like an enjoyable experience.  :-)

-Dave


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

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

[Russell O'Connor via bitcoin-dev]

I fear that we cannot simply wait 10 years to address the vulnerability
that OP_CODESEPARATOR has in its current form.

On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <
willt...@live.com.au> wrote:

> 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 <
> bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev 
> *Sent:* Saturday, 9 March 2019 6:12 AM
> *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
>
> > (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