Johnson Lau [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-04-29 to 2019-05-26
💬 Posted a total of 150 messages
📚 Participated in the following categories: bitcoin-dev, BIP Proposal, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9

Profile Code

nprofile1qqsyjtayqt5r3yztmj8t9j86lgd239wlyepchlve33cmq89emd2slacprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdstgghe

Publishing to

relay.noswhere.com

Author Public Key

npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9

Show more details

Last Notes

2023-06-09 12:46:40

- reply

📅 Original date posted:2016-09-01
📝 Original message:
Restriction for segwit OP_IF argument as a policy has got a few concept ACK. I would like to have more people to ACK or NACK, especially the real users of OP_IF. I think Lightning network would use that at lot.
Pull request: https://github.com/bitcoin/bitcoin/pull/8526
more related discussion could be found at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html
It does have impact if your script uses the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts.
>
> On August 16, 2016 at 1:53 PM Johnson Lau via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> https://github.com/bitcoin/bitcoin/pull/8526
>
> BIP: x
> Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
> Author: Johnson Lau <jl2012 at xbt.hk>
> Status: Draft
> Type: Standards Track
> Created: 2016-08-17
>
> Abstract
>
> This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.
>
> Motivation
>
> OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.
>
> The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.
>
> Specification
>
> In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.
>
> This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.
>
> Compatibility
>
> This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).
>
> Implementation
>
> https://github.com/bitcoin/bitcoin/pull/8526
>
> Copyright
>
> This work is placed in the public domain.
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - https://gpgtools.org
>
> iQGcBAEBCgAGBQJXs1LgAAoJEO6eVSA0viTSrJQL/A/womJKgi4FuyBTL9oykCss
> aBMNN9+SLtmuH7SBgEUGZ8TFxa2st+6RP6Imu+Vvn4O5sXQl3DIXV+X38X93sUYk
> wrjdpvdpqFFYJezPDESz6pR/6bZ1ES0aO2QqX578/8sqr8GO6L388s66vJeIGj4n
> 0LWW8sdEypMuV3HUG/9FFdUNHgiVX1U0sS1rT3P4aN30JYtb7PQpd7r8KTMta7Rt
> L1VOZB+W3m2m2YZ9gB7IRmMfzzNm2QXRTPIZXt2x3mYDBuMkp+zEd5+ogA4sBpgP
> wp2+l/aos686v0w8QYiNUX2+9Qpe7+238qUpw75d2XJYmLzdotWFvmp4g1hP+awX
> HEfwe4BUM+El17LjrHkNeMWNJXMlhTtXb2i0XMj8tU5lZVHep4WpQ+LEahrNlsUl
> FdFsi3q8HeWh8JsGaNCL41Bgbg/rKb5hUXyF6hTRHa//E6llOrpXRnsloKgBLv8c
> QezgKTAPwwgdjcS6Ek0AqgLp7bCFRijCduYH9i9uaQ==
> =lLIZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160901/8e47cd9f/attachment.html>

2023-06-07 18:15:50

- reply

📅 Original date posted:2018-12-17
📝 Original message:> On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 5. if there's exactly one, non-zero item on the stack; succeed
>
> Unless it is too much bikeshedding, I'd like to propose that to succeed the stack must be exactly empty. Script is more composable that way, removing the need for special logic to handle top-level CHECKSIG, vs mid-level CHECKSIGVERIFY.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I proposed the same in BIP114. I wish Satoshi had designed that way. But I’m not sure if that would do more harm than good. For example, people might lose money by copying an existing script template. But they might also lose money in the same way as CHECKMULTISIG is disabled. So I’m not sure.
Another related thing I’d like to bikeshed is to pop the stack after OP_CLTV and OP_CSV. The same pros and cons apply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181218/27c5b742/attachment.html>

2023-06-07 18:15:44

- reply

📅 Original date posted:2018-12-20
📝 Original message:> On 20 Dec 2018, at 6:09 AM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> writes:
>
>> Hi Johnson,
>>
>> The design considerations here seem similar to the ML discussion of
>> whether Graftroot should be optional [1].
>>
>>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>>
>> As far as I can tell it should be compatible with Statechains [2],
>> since it pretty much mirrors Eltoo in setup.
>>
>> My understanding is somewhat lacking, so perhaps I am missing the
>> mark, but it is not completely clear to me how this affects
>> fungibility if taproot gets added and the setup and trigger tx for
>> Eltoo get combined into a single transaction. Would the NOINPUT
>> spending condition be hidden inside the taproot commitment?
>
> I'm not aware of a way to combine the setup and trigger transaction. The
> trigger transaction was introduced in order to delay the start of the
> timeouts until a later time, to avoid having an absolute lifetime limit
> and having really huge timeout. If we were to combine the trigger
> transaction with the setup transaction (which is broadcast during
> channel creation), all of those timeouts would start counting down
> immediately, and we could just skip the trigger transaction
> altogether. It'd be more interesting to combine update and trigger
> transactions in a sort of cut-through combination, but that doesn't seem
> possible outside of Mimblewimble.
>
> Cheers,
> Christian
Correct me if I’m wrong.
For the sake of simplicity, in the following I assume BIP118, 143, and 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible optimisations.
1. A and B are going to setup a channel.
2. They create one setup tx, with a setup output of the following script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign
3. They create the update tx 0, spending the setup output with NOINPUT and locktime = s+1, to the update-0 output with the script:
IF 2 As0 Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
4. They create the settlement tx 0, spending the update-0 output with As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
5. They sign the setup tx and let it confirm
6. To update, they create the update tx 1, spending the setup output with NOINPUT and locktime = s+2, to the update-1 output with the script:
IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
and create the settlement tx 1, spending the update-1 output with As1 and Bs1 using relative-locktime, with 2 settlement outputs
7. To close the channel, broadcast update tx 1. Wait for several confirmations. And broadcast settlement-tx-1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181220/4c9d8779/attachment-0001.html>

2023-06-07 18:15:44

- reply

📅 Original date posted:2018-12-18
📝 Original message:> On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
>> On 17 Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen at gmail.com <mailto:rsomsen at gmail.com>> wrote:
>>
>> Hi Johnson,
>>
>> The design considerations here seem similar to the ML discussion of
>> whether Graftroot should be optional [1].
>
> Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee would never reuse the key, the payer could avoid any NOINPUT-related trouble by tagging properly.
>
>>
>>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>>
>> As far as I can tell it should be compatible with Statechains [2],
>> since it pretty much mirrors Eltoo in setup.
>>
>> My understanding is somewhat lacking, so perhaps I am missing the
>> mark, but it is not completely clear to me how this affects
>> fungibility if taproot gets added and the setup and trigger tx for
>> Eltoo get combined into a single transaction. Would the NOINPUT
>> spending condition be hidden inside the taproot commitment?
>
> For the design considerations I mentioned above, the tags must be explicit and configurable by the payer. So it couldn’t be hidden in taproot.
>
> If you don’t care about fungibility, you can always tag your setup output, and makes it ready for NOINPUT spending. Every update will need 2 signatures: a NOINPUT to spend the setup output or an earlier update output, and a NOINPUT to settle the latest update output.
>
> If you care about fungibility, you can’t tag your setup output. Every update will need 3 signatures: a SINGLEINPUT (aka ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier update output, and a NOINPUT to settle the latest update output.
>
> (Actually, as soon as you made the first update tx with SINGLEINPUT, you don’t strictly need to make any SINGLEINPUT signatures in the later updates again, as the first update tx (or any update with a SINGLEINPUT signature) could be effectively the trigger tx. While it makes the settlement more expensive, it also means accidentally missing a SINGLEINPUT signature will not lead to any fund loss. So security-wise it’s same as the always-tagging scenario.)
>
> The most interesting observation is: you never have the need to use NOINPUT on an already confirmed UTXO, since nothing about a confirmed UTXO is mutable. And every smart contract must anchor to a confirmed UTXO, or the whole contract is double-spendable. So the ability to NOINPUT-spend a setup output should not be strictly needed. In some (but not all) case it might make the protocol simpler, though.
>
> So the philosophy behind output tagging is “avoid NOINPUT at all cost, until it is truly unavoidable"
>
After thinking more carefully, I believe output tagging could have no adverse effect on eltoo.
Consider a system without tagging, where you could always spend an output with NOINPUT. Under taproot, state update could be made in 2 ways:
a) Making 2 sigs for each update. One sig is a “script path” locktime NOINPUT spending of the setup output or an earlier update output. One sig is a “key path” relative-locktime NOINPUT spending of the new update output. In taproot terminology, “key path” means direct spending with the scriptPubKey, and “script path” means revealing the script hidden in taproot. Key path spending is always cheaper.
b) Making 3 sigs for each update. One sig is a key path SINGLEINPUT (aka ANYONECANPAY) or NOINPUT spending of the setup output, without any locktime. One sig is a script path locktime NOINPUT spending of an earlier update output (if this is not the first update). One sig is a key path relative-locktime NOINPUT spending of the new update output
Note that in b), the first signature could be either SINGLEINPUT or NOINPUT, and they just work as fine. So SINGLEINPUT should be used to avoid unnecessary replayability.
In the case of uncooperative channel closing, b) is always cheaper than a), since this first broadcast signature will be a key path signature. Also, b) has better privacy if no one is cheating (only the last update is broadcast). The only information leaked in b) is the use of SINGLEINPUT and the subsequent relative-locktime NOINPUT. However, the script path signature in a) will leak the state number, which is the maximum number of updates made in this channel.
In conclusion, b) is cheaper and more private, but it is more complex by requiring 3 sigs per update rather than 2. I think it is an acceptable tradeoff. (And as I mentioned in my last mail, missing some SINGLEINPUT sigs is not the end of the world. As long as you find one SINGLEINPUT sig in your backup, it safely falls back to the trigger tx model)
What if we require output tagging? For privacy reason you shouldn’t tag your setup tx, so the setup output could not be spent with NOINPUT. Option a) doesn’t work, but b) only requires SINGLEINPUT and has no problem. So in a fee-minimising and privacy-maximising eltoo design, output tagging should have no adverse effect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181218/76d443f8/attachment-0001.html>

2023-06-07 18:15:43

- reply

📅 Original date posted:2018-12-17
📝 Original message:> On 17 Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen at gmail.com> wrote:
>
> Hi Johnson,
>
> The design considerations here seem similar to the ML discussion of
> whether Graftroot should be optional [1].
Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee would never reuse the key, the payer could avoid any NOINPUT-related trouble by tagging properly.
>
>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>
> My understanding is somewhat lacking, so perhaps I am missing the
> mark, but it is not completely clear to me how this affects
> fungibility if taproot gets added and the setup and trigger tx for
> Eltoo get combined into a single transaction. Would the NOINPUT
> spending condition be hidden inside the taproot commitment?
For the design considerations I mentioned above, the tags must be explicit and configurable by the payer. So it couldn’t be hidden in taproot.
If you don’t care about fungibility, you can always tag your setup output, and makes it ready for NOINPUT spending. Every update will need 2 signatures: a NOINPUT to spend the setup output or an earlier update output, and a NOINPUT to settle the latest update output.
If you care about fungibility, you can’t tag your setup output. Every update will need 3 signatures: a SINGLEINPUT (aka ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier update output, and a NOINPUT to settle the latest update output.
(Actually, as soon as you made the first update tx with SINGLEINPUT, you don’t strictly need to make any SINGLEINPUT signatures in the later updates again, as the first update tx (or any update with a SINGLEINPUT signature) could be effectively the trigger tx. While it makes the settlement more expensive, it also means accidentally missing a SINGLEINPUT signature will not lead to any fund loss. So security-wise it’s same as the always-tagging scenario.)
The most interesting observation is: you never have the need to use NOINPUT on an already confirmed UTXO, since nothing about a confirmed UTXO is mutable. And every smart contract must anchor to a confirmed UTXO, or the whole contract is double-spendable. So the ability to NOINPUT-spend a setup output should not be strictly needed. In some (but not all) case it might make the protocol simpler, though.
So the philosophy behind output tagging is “avoid NOINPUT at all cost, until it is truly unavoidable"
>
> Cheers,
> Ruben Somsen
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006.html
> [2] https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_statechains_offchain_transfer_of/
>
> On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the first tx made in block 170 reused the previous public key). I don’t see any hope to change this norm any time soon, if possible at all.
>>
>> As the people who are designing the layer-1 protocol, we could always blame the payer and/or payee for their stupidity, just like those people laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The existing bitcoin script language is so restrictive. It disallows many useful smart contracts, but at the same time prevented many dumb contracts. After all, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.
>>
>> So NOINPUT brings us more smart contract capacity, and at the same time we are one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts we want, while minimising the risks of misuse.
>>
>> The risk I am trying to mitigate is a payer mistakenly pay to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is not uncommon. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers (mostly exchanges) may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT)
>>
>> The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:
>>
>> 1. A certain bit in the tx version must be set
>> 2. A certain bit in the scriptPubKey must be set
>>
>> I will analyse the pros and cons later.
>>
>> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and should not be tagged. This makes it indistinguishable from normal 1-of-1 utxo. The trigger tx, which spends the setup utxo, should be tagged, so the update txs could spend the trigger utxo with NOINPUT. Similarly, all update txs should be tagged, so they could be spent by other update txs and settlement tx with NOINPUT. As the final destination, there is no need to tag in the settlement tx.
>>
>> In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.
>>
>> I mentioned 2 ways of tagging, and they have pros and cons. First of all, tagging in either way should not complicate the eltoo protocol in anyway, nor bring extra block space overhead.
>>
>> A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Otherwise, *all* P2SH addresses would become “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.
>>
>> Another problem with scriptPubKey tagging is all the existing bech32 implementations will not understand the special tag, and will pay to a tagged address as usual. An upgrade would be needed for them to refuse sending to tagged addresses by default.
>>
>> On the other hand, tagging with tx version will also protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx. Also, as Bitcoin Core has just removed the tx version from the UTXO database, adding it back could be a little bit annoying, but doable.
>>
>> There is an extension to the version tagging, which could make NOINPUT even safer. In addition to tagging requirement, NOINPUT will also sign the version of the previous tx. If the wallet always uses a randomised tx version, it makes accidental replay very unlikely. However, that will burn a few more bits in the tx version field.
>>
>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:15:40

- reply

📅 Original date posted:2018-12-17
📝 Original message:> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev wrote:
>>> And is it worthwhile doing the mask complexity, rather than just
>>> removing the commitment to script with NOINPUT? It *feels* safer to
>>> restrict what scripts we can sign, but is it?
>>
>> If it's not safer in practice, we've spent a little extra complexity
>> committing to a subset of the script in each signature to no gain. If
>> it is safer in practice, we've prevented people from losing funds. I'm
>> all for less complexity, but not for that tradeoff.
>
> There are many complexities we could add, each of which would prevent
> loss of funds in some theoretical case.
Every security measures are overkill, until someone get burnt. If these security measures are really effective, no one will get burnt. The inevitable conclusion is: every effective security measures are overkill.
>
> From practical experience; reuse of private keys between lightning and
> other things is not how people will lose funds[1].
Assuming an user holds a private key exclusively and securely, currently there are only 2 ways to lose funds by private key reuse: 1. reusing the same signature nonce; 2. signing the hash “one”, for the SIGHASH_SINGLE consensus bug.
People lost money for the first reason. Since this is a feature of the signature schemes we use, unavoidably that will happen again from time to time. The second one has been fixed in segwit (though incompletely), and could be completely fixed with a simple softfork.
Overall speaking, while private key reuse hurts fungibility and privacy, it is not terribly insecure, as long as you use rfc6979 and are not foolish enough to sign hash “one”. This actually thanks to the fact that signatures always committed to the previous txid. It makes sure that a signature is never valid for more than one UTXO. Unfortunately, the guarantee of non-replayability incentified the practice of key-reuse, since the day-one of bitcoin. While NOINPUT fundamentally changes this security assumption, it won’t change this long-established culture of key reuse.
So you argument seems just begging the question. Without NOINPUT, it is just impossible to lose money by key reuse, and this is exactly the topic we are debating.
>
> It *is* however non-trivially more complicated for wallets; they
> currently have a set of script templates which they will sign (ie. no
> OP_CODESEPARATOR) and I implemented BIP 143 with only the simplest of
> naive code[2]. In particular, there is no code to parse scripts.
Sorry that I’m not familiar with the implementation details of your wallet. But as you don’t have code to parse scripts, I assume your wallet can’t handle OP_CODESEPARATOR? However, this is exactly what you should do: only implement what you actually need, and ignore those unrelated details.
Also, trying to faithfully and completely reproduce the consensus code in a wallet (even if you don’t need that at all) could be extremely dangerous. Such wallet might be tricked, for example, to sign the hash “one” and get all money stolen (I was told someone really did that, but I don’t know the details)
If you didn’t implement OP_CODESEPARATOR because you didn’t use it, there is no reason for you to fully implement OP_MASKEDPUSH nor script parsing. In existing signature schemes (e.g. BIP143), signatures always commit to the script being executed (the “scriptCode”). I assume that all wallets would re-construct the scriptCode at signing time, based on the limited set of script templates they support. If a wallet had a function called GetScriptCodeForMultiSig() for this purpose, all they need now is a GetMaskedScriptCodeForMultiSig() that returns the masked template, or a new option in the existing GetScriptCodeForMultiSig(). It does not need to be something like GetMaskedScript(GetScriptCodeForMultiSig()). After all, only a very small number of script templates really need NOINPUT. A GetMaskedScript() in a wallet is just an overkill (and a vulnerability if mis-implemented)
>
> Bitcoind developers are not in a good position to assess complexity
> here. They have to implement *everything*, so each increment seems
> minor. In addition, none of these new script versions will ever make
> bitcoind simpler, since they have to support all prior ones. Wallets,
> however, do not have to.
>
> I also think that minimal complexity for (future) wallets is an
> underappreciated feature: the state of wallets in bitcoin is poor[3]
> so simplicity should be a key goal.
It is a 3-way tradeoff of security, complexity, and functionality. While not everyone might appreciate this, security seems to always be the dominent factor in bitcoin protocol development. It was the reason why most core contributors were hesitant towards BIP148, despite they all love the functionality of segwit.
It’s also about functionality here: as I mentioned in another reply, OP_CODESEPARATOR couldn’t function properly with NOINPUT but without OP_MASKEDPUSH
This debate happens because NOINPUT introduces the third way to lose fund with key reuse. And once it is deployed, we have to support it forever, and is not something that we could softfork it away.
>
> Respectfully,
> Rusty.
>
> [1] Reusing your revocation base point across two channels will lose
> funds in a much more trivial way, as will reusing payment hashes
> across invoices.
> [2] In fact, I added SIGHASH_ANYONECANPAY and SIGHASH_SINGLE recently
> for Segwit and it worked first time! Kudos to BIP143's authors for
> such a clear guide.
> [3] Bitcoind's wallet can't restore from seed; this neatly demonstrates
> how hard the wallet problem is, but there are many others.
>
>
>
>
>
>
>
>
>
>
>
>
> code, as modern wallets currently don't have to parse the scripts they
> sign.
>
>
>
>
>
>
>
> I'm telling you that this is not how people are losing funds.
>
>
>
>>
>> Also, saying "I can't see how to break this, so it's probably good
>> enough, even if other people have a bad feeling about it" is a crypto
>> anti-pattern, isn't it?
>>
>> I don't see how you could feasibly commit to more information than script
>> masking does for use cases where you want to be able to spend different
>> scripts with the same signature [0]. If that's possible, I'd probably
>> be for it.
>>
>> At the same time, script masking does seem feasible, both for
>> lightning/eltoo, and even for possibly complex variations of scripts. So
>> committing to less doesn't seem wise.
>>
>>> You already need both key-reuse and amount-reuse to be exploited.
>>> SIGHASH_MASK only prevents you from reusing this input for a "normal"
>>> output; if you used this key for multiple scripts of the same form,
>>> you're vulnerable[1].
>>
>> For example, script masking seems general enough to prevent footguns
>> even if (for some reason) key and value reuse across eltoo channels
>> were a requirement, rather than prohibited: you'd make the script be
>> "<eltoo-channel-id> MASK <statenum> CLTV 2DROP <a+b> CHECKSIG", and your
>> signature will only apply to that channel, even if another channel has
>> the same capacity and uses the same keys, a and b.
>>
>>> So I don't think it's worth it. SIGHASH_NOINPUT is simply dangerous
>>> with key-reuse, and Don't Do That.
>>
>> For my money, "NOINPUT" commits to dangerously little context, and
>> doesn't really feel safe to include as a primitive -- as evidenced by
>> the suggestion to add "_UNSAFE" or similar to its name. Personally, I'm
>> willing to accept a bit of risk, so that feeling doesn't make me strongly
>> against the idea; but it also makes it hard for me to want to support
>> adding it. To me, committing to a masked script is a huge improvement.
>>
>> Heck, if it also makes it easier to do something safer, that's also
>> probably a win...
>>
>> Cheers,
>> aj
>>
>> [0] You could, perhaps, commit to knowing the private keys for all the
>> *outputs* you're spending to, as well as the inputs, which comes
>> close to saying "I know this is a scary NOINPUT transaction, but
>> we're paying to ourselves, so it will all be okay".
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:15:39

- reply

📅 Original date posted:2018-12-24
📝 Original message:I find another proposed use of CODESEPARATOR here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html <https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html>
<KeyA> OP_CHECKSIG
OP_IF
<KeyB>
OP_ELSE
<Delay> OP_CSV OP_DROP
OP_CODESEPARATOR <KeyA>
OP_ENDIF
OP_CHECKSIG
It is actually 2 scripts:
S1: <KeyA> OP_CHECKSIGVERIFY <KeyB> OP_CHECKSIG
S2: <Delay> OP_CSV OP_DROP <KeyA> OP_CHECKSIG
Under taproot, we could make Q = P + H(P||S2)G, where P = MuSig(KeyA, KeyB)
S1 becomes a direct spending with Q, and there is no need to use OP_IF or CODESEPARATOR in S2 at all.
==================
If it is only to force R reuse, there is no need to use CODESEPARATOR:
Input: <R> <S2> <S1> Script: 2DUP EQUAL NOT VERIFY 2 PICK SWAP CAT <key> DUP TOALTSTACK CHECKSIGVERIFY CAT FROMALTSTACK CHECKSIG
But using CODESEPARATOR will save 3 bytes
Input: <S2> <R> <S1> Script: OVER SWAP CAT <key> DUP TOALTSTACK CHECKSIGVERIFY CODESEPARATOR SWAP CAT FROMALTSTACK CHECKSIG
However, a much better way would be:
Input: <S> Script: <known R> SWAP CAT <key> CHECKSIG
The discrete log of R could be a shared secret between A and B. If the purpose is to publish the private key to the whole world, R = G could be used.
> On 24 Dec 2018, at 8:01 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning,
>
>> Could anyone propose a better use case of CODESEPARATOR?
>
> Long ago, aj sent an email on Lightning-dev about use of CODESEPARATOR to impose Scriptless Script even without Schnorr. It involved 3 signatures with different CODESEPARATOR places, and forced R reuse so that the signatures to claim the funds revealed the privkey.
>
> The script shown had all CODESEPARATOR in a single branch.
>
> I cannot claim to understand the script, and am having difficulty digging through the mailinglist
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181225/2bf63818/attachment-0001.html>

2023-06-07 18:15:36

- reply

📅 Original date posted:2018-12-12
📝 Original message:> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
>> Here is a combined proposal:
>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>> and SIGHASH_SCRIPTMASK.
>> * A new opcode OP_MASK is added, which acts as a NOP during execution.
>> * The sighash is computed like in BIP143, but:
>> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
>> the subsequent opcode/push is removed.
>
> I'm asking on-list because I'm sure I'm not the only confused one.
>
> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always
> perform mask-removal for signing?
Because a hardware wallet may want to know what exact script it is signing?
Masked script has reduced security, but this is a tradeoff with functionality (e.g. eltoo can’t work without masking part of the script). So when you don’t need that extra functionality, you go back to better security
However, I’m not sure if there is any useful NOINPUT case with unmasked script.
>
> If you're signing arbitrary scripts, you're surely in trouble already?
>
> And I am struggling to understand the role of scriptmask in a taproot
> world, where the alternate script is both hidden and general?
It makes sure that your signature is applicable to a specific script branch, not others (assuming you use the same pubkey in many branches, which is avoidable)
>
> I look forward to learning what I missed!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:15:20

- reply

📅 Original date posted:2018-11-28
📝 Original message:> On 28 Nov 2018, at 11:41 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> So a combined proposal:
> * All existing sighash flags, plus NOINPUT and MASK
> (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).
> * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is
> failing if not immediately followed by a push, or when appearing as
> last opcode in the script.
I suggest to use the place of OP_RESERVED (0x50) as OP_MASKEDPUSH. The reason is 0x50 is not counted towards the 201 opcode limit, so people could mask as many pushes as needed.
In a new script version, of course, we could make any opcode not being counted. But that would just create another special case in the EvalScript() code.
(Or, maybe we should limit the use of OP_MASKEDPUSH? I think this is open for discussion.)
> * Signatures are 64 plus an optional sighash byte. A missing sighash
> byte implies ALL, and ALL cannot be specified explicitly.
> * The sighash is computed from the following:
> * A 64-byte constant tag
> * Data about the spending transaction:
> * The transaction version number
> * The hash of txins' prevouts+amounts+sequences (or nothing if ANYONECANPAY)
Do you want to make it 1 hash or 3 hashes? With 3 hashes, it could share hashPrevouts and hashSequence with BIP143. Making everything 1 hash will only result in redundent hashing for each input
> * The hash of all txouts (or just the corresponding txout if
> SINGLE; nothing if NONE)
Starting from this sighash version, I think we should forbid the use of SINGLE without a matching output. Also, the undefined output type should also be invalid.
> * The transaction locktime
> * Data about the output being spent:
> * The prevout (or nothing if NOINPUT)
> * The amount
> * The sequence number
> * The hash of the scriptPubKey (or nothing if MASK)
I think we should just use the scriptPubKey, since sPK is fixed size (23-byte for p2sh and 35-byte for native segwit).
In order to distinguish p2sh and native segwit for MASKED NOINPUT, you also need to commit to an additional 1-bit value
> * Data about the script being executed:
> * The hash of the scriptCode (after masking out, if MASK is set)
For direct key-spending (i.e. not taprooted script), I suggest to set the H(scriptCode) to zero, for the following reasons:
1) Since we have already committed to sPK, which is already a *direct* hash of scriptCode, it is redundant to do it again.
2) This could save one SHA256 compression for direct key-spending, which is probably 90% of all cases
3) This allows hardware wallet to tell whether they are using direct-spending path or taproot script path
Since we may want 3) anyway, we don’t need to commit to another 1-bit value if we simply set H(scriptCode) to zero
We should also ban MASKED NOINPUT for direct-spending, which doesn’t make sense. And it is not safe since both H(scriptCode) and sPK are empty.
> * The opcode number of the last executed OP_CODESEPARATOR (or
> 0xFFFFFFFF if none)
> * The sighash mode
This proposal will only use 4 out of the 8 sighash bits. Do we want to make those 4 unused bits invalid, or ignored? Leaving at least 1 bit valid but ignored (“bit-x"), and 1 bit invalid (“bit-y”), will allow opt-in/out hardfork replay-protection, for example:
* default signatures are those with both bit-x and bit-y unset.
* If we want to make default signatures replayable across chains, the new fork should reject signatures with bit-x, and accept sigs with or without bit-y. In this case, defaults sigs are valid for both chains. Sigs with bit-x is valid only for original chain, and sigs with bit-y is valid only for new chain.
* If we want to make default signatures non-replayabble, the new fork should reject all default sigs, but accept sigs with either bit-x or bit-y set. In this case, default sig is valid only for original chain. Sigs with bit-x is valid for both chains, and sigs with bit-y is valid only for new chain.
Replayability is sometimes desirable, for example, an LN opened before a fork should be able to be settled on both chains
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181128/40369e53/attachment-0001.html>

2023-06-07 18:15:16

- reply

📅 Original date posted:2018-11-21
📝 Original message:If we sign the txids of all inputs, we should also explicitly commit to their values. Only this could fully eliminate any possible way to lie about input value to hardware wallets
> Does it make sense to keep SIGHASH_NONE?
SIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust UTXOs to miners
> I think NONE without NOFEE doesn't make much sense…….
We might refuse to sign weird combinations like NOFEE|ALLINPUT|ALLOUTPUT. But to keep the consensus logic simple, we should just validate it as usual.
> OP_MASK seems a bit complicated to me. …...
Yes, it looks complicated to me, and it improves security only in some avoidable edge cases in SIGHASH_NOINPUT:
The common case: the exact masked script or address is reused. OP_MASK can’t prevent signature replay since the masked script is the same.
The avoidable case: the same public key is reused in different script templates. OP_MASK may prevent signature replay is the masked script is not the same.
The latter case is totally avoidable since one could and should use a different public key for different script.
It could be made much simpler as NOINPUT with/without SCRIPT. This again is only helpful in the avoidable case above, but it doesn’t bring too much complexity.
> I don't have a reason why, but committing to the scriptCode feels to me like it reduces the "hackiness" of NOINPUT a lot.
OP_MASK is designed to preserve the hackiness, while provide some sort of replay protection (only in avoidable cases). However, I’m not sure who would actually need NOINPUT with KNOWNSCRIPT
> On 21 Nov 2018, at 4:29 AM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote:
>> Here is a combined proposal:
>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>> and SIGHASH_SCRIPTMASK.
>> * A new opcode OP_MASK is added, which acts as a NOP during execution.
>> * The sighash is computed like in BIP143, but:
>> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
>> the subsequent opcode/push is removed.
>> * The scriptPubKey being spent is added to the sighash, unless
>> SIGHASH_SCRIPTMASK is set.
>> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
>> * hashPrevouts, hashSequence, and outpoint are set to null when
>> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143
> tx digest consists of the hash of:
>
> 1 nVersion
> 4 outpoint
> 5 input scriptCode
> 6 input's outpoint value
> 7 input's nSeq
> 9 nLocktime
> 10 sighash
>
> 2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY)
> 3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY)
> 8 hashOutputs
> - NONE: 0
> - SINGLE: {value,scriptPubKey} for corresponding output
> - otherwise: {value,scriptPubKey} for all outputs
>
> The fee is committed to by hashPrevOuts and hashOutputs, which means
> NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is set.
>
> For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges (5))
> is only useful given NOINPUT, since (4) indirectly commits to (5).
>
> Given this implementation, NOINPUT effectively implies ANYONECANPAY,
> I think. (I think that is also true of BIP 118's NOINPUT spec)
>
> Does it make sense to treat this as two classes of options, affecting
> the input and output side:
>
> output: (pick one, using bits 0,1)
> * NONE -- don't care where the money goes
> * SINGLE -- want this output
> * ALL -- want exactly this set of outputs
>
> input: (pick one, using bits 4,5)
> * PARTIALSCRIPT -- spending from some tx with roughly this script (and
> maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY)
> * KNOWNSCRIPT -- spending from some tx with exactly this script (and
> maybe others; NOINPUT|ANYONECANPAY)
> * KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY)
> * ALL_INPUTS -- spending from exactly these txes
>
> combo: (flag, bit 6)
> * NOFEE -- don't commit to the fee
>
> I think NONE without NOFEE doesn't make much sense, and
> NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to
> warn/error on signing when asking for those combinations, and maybe even
> to fail on validating them.
>
> (Does it make sense to keep SIGHASH_NONE? I guess SIGHASH_NONE|ALL_INPUTS
> could be useful if you just use sigs on one of the other inputs to commit
> to a useful output)
>
> FWIW, OP_MASK seems a bit complicated to me. How would you mask a script
> that looks like:
>
> OP_MASK IF <p> ENDIF <q> ...
>
> or:
>
> IF OP_MASK ENDIF <p> ...
>
> I guess if you make the rule be "for every OP_MASK in scriptCode the
> *immediately* subsequent opcode/push is removed (if present)" it would
> be fine though -- that would make OP_MASK in both the above not have
> any effect. (Maybe a more explicit name like "MASK_PUSH_FOR_SIGHASH"
> or something might be good?)
>
> I don't have a reason why, but committing to the scriptCode feels to me
> like it reduces the "hackiness" of NOINPUT a lot.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:14:54

- reply

📅 Original date posted:2018-09-26
📝 Original message:In BIP143, the nSequence of the same input is always signed, with any hashtype. Why do you need to sign the sequence of other inputs?
> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>
> There is a good reason for not doing that. If NOINPUT would sign the
> hashSequence then it would be possible to get rid of OP_CSV in eltoo update
> scripts. As a result update scripts could be taprootified because the more
> common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
> would then make unilateral settlement look like a single pubkey spend and avoid
> having to reveal the unexecuted (update) branch.
>
> Eltoo update transaction outputs consist of two branches, update and
> settlement, where the update branch can be spend by a more recent update
> transaction if an obsolete update transaction ends up spending the funding
> output. The settlement branch is a 2-of-2 multisig with a relative timelock
> using OP_CSV. Removing OP_CSV is possible because both parties signature is
> required to spend the update transaction. They will only sign if the input has
> the right sequence numbers which is sufficient to enforce the timeout (BIP68) -
> assuming they are covered by the signature.
>
> There's a catch: hashSequence includes the sequence numbers of all transaction
> inputs. That's not a problem for eltoo because settlement transactions only
> have one input. The update mechanism with update transactions relies on being
> able to bump the fee by unilaterally adding inputs and and change outputs to
> the transaction. That's also not a problem because update spends do not use
> relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
> combined SINGLE the hashSequence should be zeroed. This is in fact what a
> minimal change to the current NOINPUT implementation would naturally do (see
> below). However, that's error-prone when using NOINPUT in other contexts so in
> general it would be better if NOINPUT would only sign the sequence number of
> the corresponding input.
>
> Another downside of this approach is that you can never rebind to an output
> with an OP_CSV that requires a larger sequence number, unless you also sign
> with SIGHASH_SINGLE. It's difficult to imagine application where this would be
> an issue.
>
> This is the modification to the NOINPUT implementation
> (https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
> unilateral closes taprootifiable:
> +++ b/src/script/interpreter.cpp
> @@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const CTransaction& txTo, unsig
> hashPrevouts = cacheready ? cache->hashPrevouts : GetPrevoutHash(txTo);
> }
>
> - if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
> + if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
> hashSequence = cacheready ? cache->hashSequence : GetSequenceHash(txTo);
> }
>
> On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>>
>

2023-06-07 18:14:17

- reply

📅 Original date posted:2018-08-30
📝 Original message:After gathering some feedbacks I substantially revised the proposal. This version focus on improving security, and reduces the number of optional features.
Formatted BIP and sample code at:
https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
https://github.com/jl2012/bitcoin/commits/sighash2
The major new features compared with BIP143:
1. If signing all inputs, also sign all input value. BIP143 signature only covers the value of the same input. In some cases this may not be adequate for hardware wallet to determine the right amount of fees. Signing all input values will secure any possible case.
2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin design, previous scriptPubKey is signed as the scriptCode. However, this is not the case with P2SH and segwit. Explicitly committing to the scriptPubKey allows hardware wallet to confirm what it is actually signing (e.g. P2SH-segwit vs. Native-segwit).
3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to both scriptCode and scriptPubKey. This prevents signature replay if the same public key is used in different scripts.
4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range case.
5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index output. Described by gmaxwell at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html>
7. Signing the amount of fees (optional, yes by default). In case of not signing all inputs or outputs, users may still want to commit to a specific fee amount.
8. Signing the witness size (optional, yes by default). While segwit fixed txid malleability, it is not a fix of script malleability. It may cause some trouble if an attacker could bloat the witness and reduce the fee priority of a transaction. Although the witness size is not malleable for most simple scripts, this is not guaranteed for more complex ones. Such kind of size malleability could be avoided if signatures commit to the size of witness.
Any suggestions are welcomed. But I have the following questions:
1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it should, because that helps avoid signature replay in some cases, and also lets hardware wallets know what they are signing. I am asking this because BIP118 proposes the opposite. I want to make sure I’m not missing something here.
2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, an example use case is kickstarter, where individual supporters send money to the last output for a kickstarter project, and send change to the matched output. However, I doubt if this would be actually used this way, because the kickstarter organiser could always take the money before the target is met, by making up the difference with his own input. This is an inherent problem for any anonymous kickstarter scheme. If these new SIGHASHs are not useful in other applications, I am not sure if we should add them.
3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully flexible way to sign a subset of outputs? The indexes of signed outputs are put at the end of the signature, and the signature won’t commit to these index values. Therefore, a third party could collect all transactions of this kind and merge them into one transaction. To limit the sighash cost, number of signed outputs might not be more than 2 or 3. Some potential problems: a) code complexity; b) 1-byte or 2-byte index: 1-byte will limit the number of outputs to 256. 2-byte will use more space even for smaller txs; c) highly variable signature size makes witness size estimation more difficult
4. Should we sign the exact witness size (as proposed), or an upper size limit? Signing an upper limit will take up more space, as the limit has to be explicitly shown in the witness. The overhead could be avoided by showing the limit only if the actual witness size is not equal to the committed limit. However, I tend to keep it simple and sign the exact value. If in a multi-sig setup some signers are unable to accurately estimate the witness size, they should leave this responsibility to the last signer who should know the exact size.
> On 1 Jun 2018, at 2:35 AM, Johnson Lau via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Since 2016, I have made a number of proposals for the next generation of script. Since then, there has been a lot of exciting development on this topic. The most notable ones are Taproot and Graftroot proposed by Maxwell. It seems the most logical way is to implement MAST and other new script functions inside Taproot and/or Graftroot. Therefore, I substantially simplified my earlier proposal on SIGHASH2. It is a superset of the existing SIGHASH and the BIP118 SIGHASH_NOINPUT, with further flexibility but not being too complicated. It also fixes some minor problems that we found in the late stage of BIP143 review. For example, the theoretical (but not statistical) possibility of having same SignatureHash() results for a legacy and a witness transaction. This is fixed by padding a constant at the end of the message so collision would not be possible.
>
> A formatted version and example code could be found here:
> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
> https://github.com/jl2012/bitcoin/commits/sighash2
>
>
> ========
>
> BIP: YYY
> Layer: Consensus (soft fork)
> Title: Signature checking operations in version 1 witness program
> Author: Johnson Lau <jl2012 at xbt.hk>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0YYY
> Status: Draft
> Type: Standards Track
> Created: 2017-07-19
> License: BSD-3-Clause
>
>
> *Abstract
>
> This BIP defines signature checking operations in version 1 witness program.
>
> *Motivation
>
> Use of compact signatures to save space.
>
> More SIGHASH options, more flexibility
>
> *Specification
>
> The following specification is applicable to OP_CHECKSIG and OP_CHECKSIGVERIFY in version 1 witness program.
>
> **Public Key Format
>
> The pubic key MUST be exactly 33 bytes.
>
> If the first byte of the public key is a 0x02 or 0x03, it MUST be a compressed public key. The signature is a Schnorr signature (To be defined separately)
>
> If the first byte of the public key is neither 0x02 nor 0x03, the signature is assumed valid. This is for future upgrade.
>
> **Signature Format
>
> The following rules apply only if the first byte of the public key is a 0x02 or 0x03.
>
> If the signature size is 64 to 66 byte, it MUST be a valid Schnorr signature or the script execution MUST fail (cf. BIP146 NULLFAIL). The first 32-byte is the R value in big-endian. The next 32-byte is the S value in big-endian. The remaining data, if any, denotes the hashtype in little-endian (0 to 0xffff).
>
> hashtype MUST be minimally encoded. Any trailing zero MUST be removed.
>
> If the signature size is zero, it is accepted as the "valid failing" signature for OP_CHECKSIG to return a FALSE value to the stack. (cf. BIP66)
>
> The script execution MUST fail with a signature size not 0, 64, 65, or 66-byte.
>
> **New hashtype definitions
>
> hashtype and the SignatureHash function are re-defined:
>
> Double SHA256 of the serialization of:
> 1. nVersion (4-byte little endian)
> 2. hashPrevouts (32-byte hash)
> 3. hashSequence (32-byte hash)
> 4. outpoint (32-byte hash + 4-byte little endian)
> 5. scriptCode (serialized as scripts inside CTxOuts)
> 6. nAmount (8-byte little endian)
> 7. nSequence (4-byte little endian)
> 8. hashOutputs (32-byte hash)
> 9. nLocktime (4-byte little endian)
> 10. nInputIndex (4-byte little endian)
> 11. nFees (8-byte little endian)
> 12. hashtype (4-byte little endian)
> 13. sigversion (4-byte little endian for the fixed value 0x01000000)
>
> The bit 0 to 3 of hashtype denotes a value between 0 and 15:
>
> • If the value is 1, the signature is invalid.
> • If the value is 3 or below, hashPrevouts is the hash of all input, same as defined in BIP143. Otherwise, it is 32-byte of 0x0000......0000.
> • If the value is 7 or below, outpoint is the COutPoint of the current input. Otherwise, it is 36-byte of 0x0000......0000.
> • If the value is 0, hashSequence is the hash of all sequence, same as defined in BIP143. Otherwise, it is 32-byte of 0x0000......0000.
> • If the value is even (including 0), nSequence is the nSequence of the current input. Otherwise, it is 0x00000000.
> • If the value is 6, 7, 10, 11, 14, or 15, nInputIndex is 0x00000000. Otherwise, it is the index of the current input.
> • If the value is 11 or below, nAmount is the value of the current input (same as BIP143). Otherwise, it is 0x0000000000000000.
>
> The bit 4 and 5 of hashtype denotes a value between 0 and 3:
>
> • If the value is 0, hashOutputs is same as the SIGHASH_ALL case in BIP143 as a hash of all outputs.
> • If the value is 1, the signature is invalid.
> • If the value is 2, hashOutputs is same as the SIGHASH_SINGLE case in BIP143 as a hash of the matching output. If a matching output does not exist, hashOutputs is 32-byte of 0x0000......0000.
> • If the value is 3, hashOutputs is 32-byte of 0x0000......0000.
> If bit 6 is set (SIGHASH2_NOFEE), nFees is 0x0000000000000000. Otherwise, it is the fee paid by the transaction.
> If bit 7 is set (SIGHASH2_NOLOCKTIME), nLockTime is 0x00000000. Otherwise, it is the transaction nLockTime.
>
> If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x00000000. Otherwise, it is the transaction nVersion.
>
> If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. Otherwise, it is same as described in BIP143.
>
> Bits 10 to 15 are reserved and ignored, but the signature still commits to their value as hashtype.
>
> hashtype of 0 is also known as SIGHASH2_ALL, which covers all the available options. In this case the singnature MUST be exactly 64-byte.
>
> hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing and is effectively forfeiting the right related to this public key to anyone.
>
> *Rationale
>
> **Signature Format
>
> The current DER format is a complete waste of block space. The new format saves ~8 bytes per signature.
>
> **New hashtype definitions
>
> The default and most commonly used case is SIGHASH2_ALL. Making it zero size to save space. As a result, the bit flags are defined in a negative way (e.g. NOLOCKTIME)
>
> Why decouple INPUT and SEQUENCE? Maybe you want NOINPUT but still have a relative lock-time?
>
> Why some combinations are missing? To save some bits for useless flags. If you sign all inputs, you must know its index and value. If you sign only this input, you must know its value, but probably don't know its index in the input vector.
>
> Why only allow signing all SEQUENCE if all INPUT are signed? It doesn't make much sense if you care about their sequence without even knowing what they are.
>
> Why signing INPUTINDEX? Legacy and BIP143 SINGLE|ANYONECANPAY behaves differently for input index. Better make it explicit and optional.
>
> Why signing FEE? Sometimes you don't sign all inputs / outputs but still want to make sure the fees amount is correct.
>
> Putting NOVERSION and NOSCRIPTCODE in the second byte makes most signatures below 66 bytes:
>
> • NOVERSION: Currently the only use of transaction version is to enforce BIP68. It could be safely assumed that version 2 is used. The only case one would like to use NOVERSION is to make the signature compatible with some unknown new features that use a different transaction version.
> • NOSCRIPTCODE: It would be very rare if one could make a signature without knowing what the script is (at least they know the public key). The only scenario that a NOSCRIPTCODE is really needed is the public key being reused in different scripts, and the user wants to use a single signature to cover all these scripts.
> Reserved bits: These bits are ignored but should normally be unset. Users MUST NOT set these bits until they are defined by a future proposal, or they might lose money.
> Why sigversion? Make sure the message digest won't collide with SIGHASH schemes in the past (legacy and BIP143) and future (which will use a different sigversion).
>
> *Examples
>
> Equivalent SIGHASH2 value for other SIGHASH schemes:
> Legacy/BIP143 ALL: 0 (commit to everything)
> Legacy/BIP143 SINGLE with matching output: 0x62 (all input, one sequence, one output, no fee)
> Legacy SINGLE without matching output: 0x3ff (Not exactly. Both signatures commit to nothing, but the legacy one is valid only without a matched output. Practically, they are both "wildcard" signatures that allow anyone to spend any related UTXO)
> Legacy/BIP143 NONE: 0x72 (all input, one sequence, no output, no fee)
> Legacy/BIP143 ANYONECANPAY|ALL: 0x46 (one input without index, one sequence, all output, no fee)
> Legacy ANYONECANPAY|SINGLE with matching output: 0x64 (one input with index, one sequence, one output, no fee)
> Legacy/BIP143 ANYONECANPAY|NONE: 0x76 (one input without index, one sequence, no output, no fee)
> BIP143 SINGLE without matching output: 0x62 (all input, one sequence, no output, no fee)
> BIP143 ANYONECANPAY|SINGLE with matching output: 0x66 (one input without index, one sequence, one output, no fee)
> BIP143 ANYONECANPAY|SINGLE without matching output: 0x66 (one input without index, one sequence, no output, no fee)
> BIP118 NOINPUT: 0x14b (no input but with value, no index, no sequence, no fee, no scriptcode)
>
> Notes:
>
> 1. In legacy and BIP143 SIGHASH, only ALL but not other types implicitly commits to the fee paid.
> 2. Legacy SIGHASH always implicitly commits to the input value. BIP143 and BIP118 commits to that explicitly.
> 3. Legacy and BIP143 SIGHASH behaves differently in the case of SINGLE without matching output. In legacy SIGHASH it is a true "wildcard signature" that allows anyone to spend any related UTXO. In BIP143 such signature applies only to a specific UTXO.
> 4. BIP143 ANYONECANPAY never commits to the input index. Legacy ANYONECANPAY|SINGLE implicitly commits to the input index.
>
> *Backward compatibility
>
> This is a soft-fork.
>
> *Deployment
>
> Exact details TBD.
>
> *Reference Implementation
>
> https://github.com/jl2012/bitcoin/commits/sighash2 (To be updated)
>
> *Copyright
>
> This document is licensed as BSD 3-clause.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180831/134e94ee/attachment-0001.html>

2023-06-07 18:14:09

- reply

📅 Original date posted:2018-08-24
📝 Original message:To determine the new difficulty, it is supposed to compare the timestamps of block (2016n - 1) with block (2016n - 2017). However, an off-by-one bug makes it compares with block (2016n - 2016) instead.
A naive but perfect fix is to require every block (2016x) to have a timestamp not smaller than that of its parent block. However, a chain-split would happen even without any attack, unless super-majority of miners are enforcing the new rules. This also involves mandatory upgrade of pool software (cf. pool software upgrade is not mandatory for segwit). The best way is to do it with something like BIP34, which also requires new pool software.
We could have a weaker version of this, to require the timestamp of block (2016x) not smaller than its parent block by t-seconds, with 0 <= t <= infinity. With a bigger t, the fix is less effective but also less likely to cause intentional/unintentional split. Status quo is t = infinity.
Reducing the value of t is a softfork. The aim is to find a t which is small-enough-to-prohibit-time-wrap-attack but also big-enough-to-avoid-split. With t=86400 (one day), a time-wrap attacker may bring down the difficulty by about 1/14 = 7.1% per round. Unless new blocks were coming incredibly slow, the attacker needs to manipulate the MTP for at least 24 hours, or try to rewrite 24 hours of history. Such scale of 51% attack is already above the 100-block coinbase maturity safety theshold and we are facing a much bigger problem.
With t=86400, a non-majority, opportunistic attacker may split the chain only if we have no new block for at least 24 - 2 = 22 hours (2-hours is the protocol limit for using a future timestamp) at the exact moment of retarget. That means no retarget is possible in the next 2016 blocks. Doing a time-wrap attack at this point is not quite interesting as the coin is probably already worthless. Again, this is a much bigger problem than the potential chain spilt. People will yell for a difficulty (and time wrap fix, maybe) hardfork to resuscitate the chain.
> On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
> difficulty calculation was vulnerable to gaming with inaccurate
> timestamps to massively increase the rate of block production beyond
> the system's intentional design. It can be fixed with a soft-fork that
> further constraints block timestamps, and a couple of proposals have
> been floated along these lines.
>
> I put a demonstration of timewarp early in the testnet3 chain to also
> let people test mitigations against that. It pegs the difficulty way
> down and then churned out blocks at the maximum rate that the median
> time protocol rule allows.
>
> I, and I assume others, haven't put a big priority into fixing this
> vulnerability because it requires a majority hashrate and could easily
> be blocked if someone started using it.
>
> But there haven't been too many other network consensus rules going on
> right now, and I believe at least several of the proposals suggested
> are fully compatible with existing behaviour and only trigger in the
> presence of exceptional circumstances-- e.g. a timewarp attack. So
> the risk of deploying these mitigations would be minimal.
>
> Before I dust off my old fix and perhaps prematurely cause fixation on
> a particular approach, I thought it would be useful to ask the list if
> anyone else was aware of a favourite backwards compatible timewarp fix
> proposal they wanted to point out.
>
> Cheers.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:12:25

- reply

📅 Original date posted:2018-05-25
📝 Original message:While you have rescind your concern, I’d like to point out that it’s strictly a problem of SIGHASH_NOINPUT, not graftroot (or script delegation in general).
For example, we could modify graftroot. Instead of signing the (script), we require it to sign (outpoint | script). That means a graftroot signature would never be valid for more than one UTXO.
> On 24 May 2018, at 1:52 AM, Andrew Poelstra via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Wed, May 23, 2018 at 01:50:13PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>>
>> Graftroot also break blind signature schemes. Consider a protocol such as [1]
>> where some party has a bunch of UTXOs all controlled (in part) by the same
>> key X. This party produces blind signatures on receipt of new funds, and can
>> only verify the number of signatures he produces, not anything about what he
>> is signing.
>>
>> BTW, the same concern holds for SIGHASH_NOINPUT, which I'd also like to be
>> disable-able. Maybe we should extend one of ZmnSCPxj's suggestions to include
>> a free "flags" byte or two in the witness?
>>
>> (I also had the same concern about signature aggregation. It seems like it's
>> pretty hard to preserve the "one signature = at most one input" invariant of
>> Bitcoin, but I think it's important that it is preserved, at least for
>> outputs that need it.)
>>
>> Or maybe, since it appears it will require a space hit to support optional
>> graftroot anyway, we should simply not include it in a proposal for Taproot,
>> since there would be no opportunity cost (in blockchain efficiency) to doing
>> it later.
>>
>> [1] https://github.com/apoelstra/scriptless-scripts/pull/1
>>
>
> On further thought, I rescind this concern (ditto for SIGHASH_NOINPUT) (but
> not for aggregate sigs, they still interact badly with blind signatures).
>
> As long as graftroot (and NOINPUT) sigs commit to the public key, it is
> possible for a server to have unique keys for every output, even while
> retaining the same private key, and thereby ensure that "one sig can spend
> only one output" holds. To do this, suppose the server has a BIP32 xpubkey
> (xG, cc). A blind signer using the private key x can be made to sign not
> only for xG, but also for any publicly-derived child keys of (xG, cc).
>
> Here is a simple scheme that does this:
>
> 1. Signer provides a nonce R = kG
>
> 2. Challenger computes bip32 tweak h, chooses blinders alpha and beta,
> and computes:
> R' = R + alpha*G + beta*P
> e = H(P + hG || R' || tx)
> e' = e + beta
> and sends e' to the signer.
>
> 3. Signer replies with s = k + xe' (= k + beta*x + (x + h)e - he)
>
> 4. Challenger unblinds this as s' = s + alpha + he
>
> (This blind signature scheme is vulnerable to Wagner's attack, though see
> Schnorr 2004 [1] for mitigations that are perfectly compatible with this
> modified BIP32ish scheme.)
>
> I'm unsure whether key-prefixing is _actually_ necessary for this, but it
> makes the security argument much clearer since the messagehash contains
> some data which can be made unique per-utxo and is committed in the chain.
>
>
> Andrew
>
>
> [1] http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8ECEF929559865FD68D1D873555D18FE?doi=10.1.1.68.9836&rep=rep1&type=pdf
>
>
> --
> Andrew Poelstra
> Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> "A goose alone, I suppose, can know the loneliness of geese
> who can never find their peace,
> whether north or south or west or east"
> --Joanna Newsom
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:11:56

- reply

📅 Original date posted:2018-05-09
📝 Original message:> On 10 May 2018, at 3:27 AM, Peter Todd <pete at petertodd.org> wrote:
>
> On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote:
>> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
>>
>> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change.
>>
>> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
>
> I don't think that will work, as a zero-fee tx won't get relayed even with
> CPFP, due to the fact that we haven't yet implemented package-based tx
> relaying.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
My only concern is UTXO pollution. There could be a “CPFP anchor” softfork that outputs with empty scriptPubKey and 0 value are spendable only in the same block. If not spent immediately, they become invalid and are removed from UTXO. But I still think the best solution is a more flexible SIGHASH system, which doesn’t need CPFP at all.

2023-06-07 18:11:55

- reply

📅 Original date posted:2018-05-09
📝 Original message:You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change.
In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
> On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees. Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard. Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:07:50

- reply

📅 Original date posted:2017-11-20
📝 Original message:We can’t “just compute the Transaction ID the same way the hash for signing the transaction is computed” because with different SIGHASH flags, there are 6 (actually 256) ways to hash a transaction.
Also, changing the definition of TxID is a hardfork change, i.e. everyone are required to upgrade or a chain split will happen.
It is possible to use “normalised TxID” (BIP140) to fix malleability issue. As a softfork, BIP140 doesn’t change the definition of TxID. Instead, the normalised txid (i.e. txid with scriptSig removed) is used when making signature. Comparing with segwit (BIP141), BIP140 does not have the side-effect of block size increase, and doesn’t provide any incentive to control the size of UTXO set. Also, BIP140 makes the UTXO set permanently bigger, as the database needs to store both txid and normalised txid
> On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Bitcoin Noob here. Please forgive my ignorance.
>
> From what I understand, in SegWit, the transaction needs to be serialized into a data structure that is different from the current one where signatures are separated from the rest of the transaction data.
>
> Why change the format at all? Why cant we just compute the Transaction ID the same way the hash for signing the transaction is computed?
>
> --
> Dr. Praveen Baratam
>
> about.me <http://about.me/praveen.baratam>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171121/f53f93f9/attachment.html>

2023-06-07 18:05:44

- reply

📅 Original date posted:2017-09-12
📝 Original message:> On 8 Sep 2017, at 4:04 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If I understand the revised attack description correctly, then there
> is a small window in which the attacker can create a script less than
> 55 bytes in length, where nearly all of the first 32 bytes are
> selected by the attacker, yet nevertheless the script seems safe to
> the counter-party. The smallest such script I was able to construct
> was the following:
>
> <fake-pubkey> CHECKSIGVERIFY HASH160 <preimage> EQUAL
>
> This is 56 bytes and requires only 7 bits of grinding in the fake
> pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
> 32-byte pubkeys (in a script version upgrade, for example) would
> reduce this to the necessary 55 bytes with 0 bits of grinding. A
> smaller variant is possible:
>
> DUP HASH160 <fake-pubkey-hash> EQUALVERIFY CHECKSIGVERIFY HASH160 <preimage> EQUAL
>
> This is 46 bytes, but requires grinding 96 bits, which is a bit less
> plausible.
>
> Belts and suspenders are not so terrible together, however, and I
> think there is enough of a justification here to look into modifying
> the scheme to use a different IV for hash tree updates. This would
> prevent even the above implausible attacks.
>
I think you overestimated the difficulty. Consider this MAST branch (an example in BIP114)
"Timestamp" CHECKLOCKTIMEVERIFY <fake-pubkey> CHECKSIGVERIFY
This requires just a few bytes of collision.

2023-06-07 18:05:36

- reply

📅 Original date posted:2017-09-12
📝 Original message:> On 12 Sep 2017, at 10:03 AM, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> My apologies for a delay in responding to emails on this list; I have
> been fighting a cold.
>
> (Also my apologies to Johnson Lau, as I forgot to forward this to the list.)
>
> On Sep 8, 2017, at 2:21 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
>
>> Tail-call execution semantics require "unclean stake" , i.e. final
>> stake with more than one item. However, "unclean stake" is invalid
>> (not just non-standard) in BIP141, so you could only use it with
>> legacy P2SH (which is totally pointless....). A different design
>> like OP_EVAL might be needed, or you need a new witness script
>> version.
>
> I believe you meant "unclean stack," and you are correct. This was
> also pointed out last tuesday by a participant at the in-person
> CoreDev meetup where the idea was presented.
>
> This doesn't kill the idea, it just complicates the implementation
> slightly. A simple fix would be to allow tail-recursion to occur if
> the stack is not clean (as can happen with legacy P2SH as you point
> out, or yet to be defined version 1+ forms of segwit script), OR if
> there is a single item on the stack and the alt-stack is not empty.
> For segwit v0 scripts you then have to move any arguments to the alt
> stack before ending the redeem script, leaving just the policy script
> on the main stack.
This is ugly and actually broken, as different script path may require different number of stack items, so you don’t know how many OP_TOALTSTACK do you need. Easier to just use a new witness version
>
>> I think you have also missed the sigOp counting of the executed
>> script. As you can't count it without executing the script, the
>> current static analysability is lost. This was one of the reasons
>> for OP_EVAL being rejected. Since sigOp is a per-block limit, any
>> OP_EVAL-like operation means block validity will depend on the
>> precise outcome of script execution (instead of just pass or fail),
>> which is a layer violation.
>
> I disagree with this design requirement.
>
> The SigOp counting method used by bitcoin is flawed. It incorrectly
> limits not the number of signature operations necessary to validate a
> block, but rather the number of CHECKSIGs potentially encountered in
> script execution, even if in an unexecuted branch. (Admitedly MAST
> makes this less of an issue, but there are still useful compact
> scripts that use if/else constructs to elide a CHECKSIG.) Nor will it
> account for aggregation when that feature is added, or properly
> differentiate between signature operations that can be batched and
> those that can not.
>
> Additionally there are other resources used by script that should be
> globally limited, such as hash operations, which are not accounted for
> at this time and cannot be statically assessed, even by the flawed
> mechanism by which SigOps are counted. I have maintained for some time
> that bitcoin should move from having multiple separate global limits
> (weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear
> metric that combines all of these factors with appropriate
> coefficients.
>
I like the idea to have an unified global limit and suggested a way to do it (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html). But I think this is off-topic here.
> A better way of handling this problem, which works for both SigOps and
> HashOps, is to have the witness commit to the maximum resources
> consumed by validation of the spend of the coin, to relay this data
> with the transaction and include it in the SigHash, and to use the
> committed maximum for block validation. This could be added in a
> future script version upgrade. This change would also resolve the
> issue that led to the clean stack rule in segwit, allowing future
> versions of script to use tail-call recursion without involving the
> alt-stack.
>
> Nevertheless it is constructive feedback that the current draft of the
> BIP and its implementation do not count SigOps, at all. There are a
> couple of ways this can be fixed by evaluating the top-level script
> and then doing static analysis of the resulting policy script, or by
> running the script and counting operations actually performed.
In any case, I think maintaining static analysability for global limit(s) is very important. Ethereum had to give up their DAO softfork plan at the last minute, exactly due to the lack of this: http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/
Otherwise, one could attack relay and mining nodes by sending many small size txs with many sigops, forcing them to validate, and discard due to insufficient fees.
Technically it might be ok if we commit the total validation cost (sigop + hashop + whatever) as the first witness stack item, but that’d take more space and I’m not sure if it is desirable. Anyway, giving up static analysability for scripts is a fundamental change to our existing model.
>
> Additionally, it is possible that we take this time to re-evaluate
> whether we should be counting SigOps other than for legacy consensus
> rule compliance. The speed of verification in secp256k1 has made
> signature operations no longer the chief concern in block validation
> times.
Without the limit I think we would be DoS-ed to dead
>> Witness script versioning is by design fully compatible with P2SH
>> and BIP173, so there will be no hurdle for existing wallets to pay
>> to BIP114. Actually it should be completely transparent to them.
>
> This is correct. Your feedback will be incorporated.
>
>> For code complexity, the minimal BIP114 could be really simple, like
>> <30 lines of code? It looks complex now because it does much more
>> than simply hiding scripts in a hash.
>
> Is there a repo that contains the latest implementation of BIP 114,
> for comparison purposes?
You can find it here: https://github.com/jl2012/bitcoin/commits/vault
https://github.com/jl2012/bitcoin/commit/f3f201d232d3995db38e09b171e4d1dea8d04ad2
But this does more than your proposal as it allows users adding extra scripts when spending a coin. The rationale is described in the revised BIP114:
https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki#Additional_scripts_in_witness
So to make it functionally comparable with your proposal, the IsMSV0Stack() function is not needed. The new 249-254 lines in interpreter.cpp could be removed. The new 1480-1519 lines could be replaced by a few lines copied from the existing P2WSH code. I can make a minimal version if you want to see how it looks like
>
> Kind regards,
> Mark Friedenbach
>

2023-06-07 18:05:35

- reply

📅 Original date posted:2017-09-08
📝 Original message:Some comments with the tail-call execution semantics BIP:
Tail-call execution semantics require “unclean stake”, i.e. final stake with more than one item. However, “unclean stake” is invalid (not just non-standard) in BIP141, so you could only use it with legacy P2SH (which is totally pointless….). A different design like OP_EVAL might be needed, or you need a new witness script version.
I think you have also missed the sigOp counting of the executed script. As you can’t count it without executing the script, the current static analysability is lost. This was one of the reasons for OP_EVAL being rejected. Since sigOp is a per-block limit, any OP_EVAL-like operation means block validity will depend on the precise outcome of script execution (instead of just pass or fail), which is a layer violation.
(An alternative is to make sigOp a per-input limit instead of per-block limit, just like the 201 nOp limit. But this is a very different security model)
Witness script versioning is by design fully compatible with P2SH and BIP173, so there will be no hurdle for existing wallets to pay to BIP114. Actually it should be completely transparent to them.
For code complexity, the minimal BIP114 could be really simple, like <30 lines of code? It looks complex now because it does much more than simply hiding scripts in a hash.
> On 7 Sep 2017, at 8:38 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I would like to propose two new script features to be added to the
> bitcoin protocol by means of soft-fork activation. These features are
> a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution
> semantics.
>
> In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force
> redemption to use values selected from a pre-determined set committed
> to in the scriptPubKey, but without requiring revelation of unused
> elements in the set for both enhanced privacy and smaller script
> sizes. Tail-call execution semantics allows a single level of
> recursion into a subscript, providing properties similar to P2SH while
> at the same time more flexible.
>
> These two features together are enough to enable a range of
> applications such as tree signatures (minus Schnorr aggregation) as
> described by Pieter Wuille [1], and a generalized MAST useful for
> constructing private smart contracts. It also brings privacy and
> fungibility improvements to users of counter-signing wallet/vault
> services as unique redemption policies need only be revealed if/when
> exceptional circumstances demand it, leaving most transactions looking
> the same as any other MAST-enabled multi-sig script.
>
> I believe that the implementation of these features is simple enough,
> and the use cases compelling enough that we could BIP 8/9 rollout of
> these features in relatively short order, perhaps before the end of
> the year.
>
> I have written three BIPs to describe these features, and their
> associated implementation, for which I now invite public review and
> discussion:
>
> Fast Merkle Trees
> BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
> Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
>
> MERKLEBRANCHVERIFY
> BIP: https://gist.github.com/maaku/bcf63a208880bbf8135e453994c0e431
> Code: https://github.com/maaku/bitcoin/tree/merkle-branch-verify
>
> Tail-call execution semantics
> BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368
> Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics
>
> Note: I have circulated this idea privately among a few people, and I
> will note that there is one piece of feedback which I agree with but
> is not incorporated yet: there should be a multi-element MBV opcode
> that allows verifying multiple items are extracted from a single
> tree. It is not obvious how MBV could be modified to support this
> without sacrificing important properties, or whether should be a
> separate multi-MBV opcode instead.
>
> Kind regards,
> Mark Friedenbach
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:00:57

- reply

📅 Original date posted:2017-05-09
📝 Original message:No, changing from 50% to 75% is a hardfork. (75 -> 50 is a softfork). Unless you make it pre-scheduled, or leave a special “backdoor” softfork to change the discount.
And that would certainly reduce the max tx/s with 50% discount, also reduce the incentive to spend witness UTXO.
> On 10 May 2017, at 00:19, Sergio Demian Lerner <sergio.d.lerner at gmail.com> wrote:
>
> Thanks Johnson and Hampus for the clarifications.
> However, I would rather do the opposite: soft-fork to 50% now, and soft-fork again to 75% discount later if needed, because it doesn't affect the max transactions/second.
>
> Segwit as it is today should be activated. However if it is not before November, then for the next Segwit attempt I would choose a more conservative 50% discount.
>
>
>
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012 at xbt.hk <mailto:jl2012 at xbt.hk>> wrote:
>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> >
> > So it seems the 75% discount has been chosen with the idea that in the future the current transaction pattern will shift towards multisigs. This is not a bad idea, as it's the only direction Bitcoin can scale without a HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize increase HF in the future. In that case it's much better to use a 50% witness discount, and do not make scaling risky by making the worse case block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> >
>
> As we could change any parameter in a hardfork, I don’t think this has any relation with the current BIP141 proposal. We could just use 75% in a softfork, and change that to a different value (or completely redefine the definition of weight) with a hardfork later.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170510/7cb9f0fc/attachment.html>

2023-06-07 18:00:57

- reply

📅 Original date posted:2017-05-09
📝 Original message:> On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> So it seems the 75% discount has been chosen with the idea that in the future the current transaction pattern will shift towards multisigs. This is not a bad idea, as it's the only direction Bitcoin can scale without a HF.
> But it's a bad idea if we end up doing, for example, a 2X blocksize increase HF in the future. In that case it's much better to use a 50% witness discount, and do not make scaling risky by making the worse case block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>
As we could change any parameter in a hardfork, I don’t think this has any relation with the current BIP141 proposal. We could just use 75% in a softfork, and change that to a different value (or completely redefine the definition of weight) with a hardfork later.

2023-06-07 18:00:33

- reply

📅 Original date posted:2017-04-26
📝 Original message:> On 27 Apr 2017, at 04:01, Luke Dashjr <luke at dashjr.org> wrote:
>
> On Wednesday 26 April 2017 7:31:38 PM Johnson Lau wrote:
>> I prefer not to do anything that requires pools software upgrade or wallet
>> upgrade. So I prefer to keep the dummy marker, and not change the
>> commitment structure as suggested by another post.
>
> Fair enough, I guess. Although I think the dummy marker could actually be non-
> consensus critical so long as the hashing replaces it with a 0.
>
>> For your second suggestion, I think we should keep scriptSig empty as that
>> should be obsoleted. If you want to put something in scriptSig, you should
>> put it in witness instead.
>
> There are things scriptSig can do that witness cannot today - specifically add
> additional conditions under the signature. We can always obsolete scriptSig
> later, after segwit has provided an alternative way to do this.
You can do this with witness too, which is also cheaper. Just need to make sure the signature covers a special part of the witness. I will make a proposal to Litecoin soon, which allows signing and executing extra scripts in witness. Useful for things like OP_PUSHBLOCKHASH
>
>> Maybe we could restrict witness to IsPushOnly() scriptPubKey, so miners
>> can’t put garbage to legacy txs.
>
> They already can malleate transactions and add garbage to the blocks. I don't
> see the benefit here.
Witness is cheaper and bigger
>
> Luke

2023-06-07 17:59:41

- reply

📅 Original date posted:2017-04-08
📝 Original message:> On 9 Apr 2017, at 03:56, Tomas <tomas at tomasvdw.nl> wrote:
>
>
>> I don’t fully understand your storage engine. So the following deduction
>> is just based on common sense.
>>
>> a) It is possible to make unlimited number of 1-in-100-out txs
>>
>> b) The maximum number of 100-in-1-out txs is limited by the number of
>> previous 1-in-100-out txs
>>
>> c) Since bitcrust performs not good with 100-in-1-out txs, for anti-DoS
>> purpose you should limit the number of previous 1-in-100-out txs.
>>
>> d) Limit 1-in-100-out txs == Limit UTXO growth
>>
>> I’m not surprised that you find an model more efficient than Core. But I
>> don’t believe one could find a model that doesn’t become more efficient
>> with UTXO growth limitation.
>
> My efficiency claims are *only* with regards to order validation. If we
> assume all transactions are already pre-synced and verified, bitcrust's
> order validation is very fast, and (only slightly) negatively effected
> by input-counts.
pre-synced means already in mempool and verified? Then it sounds like we just need some mempool optimisation? The tx order in a block is not important, unless they are dependent
>
>> One more question: what is the absolute minimum disk and memory usage in
>> bitcrust, compared with the pruning mode in Core?
>
> As bitcrust doesn't support this yet, I cannot give accurate numbers,
> but I've provided some numbers estimates earlier in the thread.
>
>
> Rereading my post and these comments, I may have stepped on some toes
> with regards to SegWit's model. I like SegWit (though I may have a
> slight preference for BIP140), and I understand the reasons for the
> "discount", so this was not my intention. I just think that the reversal
> of costs during peak load order validation is a rather interesting
> feature of using spend-tree based validation.
>
> Tomas
Please no conspiracy theory like stepping on someone’s toes. I believe it’s always nice to challenge the established model. However, as I’m trying to make some hardfork design, I intend to have a stricter UTXO growth limit. As you said "protocol addressing the UTXO growth, might not be worth considering protocol improvements*, it sounds like UTXO growth limit wouldn’t be very helpful for your model, which I doubt.

2023-06-07 17:59:41

- reply

📅 Original date posted:2017-04-08
📝 Original message:> On 8 Apr 2017, at 15:28, Tomas via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>
> I think you are being a bit harsh here . I am also clearly explaining
> the difference only applies to peak load, and just making a suggestion.
> I simply want to stress the importance of protocol / implementation
> separation as even though you are correct UTXO data is always a resource
> cost for script validation (as I also state), the ratio of different
> costs are not necessarily *identical* across implementation.
>
> Note that the converse also holds: In bitcrust, if the last few blocks
> contain many inputs, the peak load verification for this block is
> slower. This is not the case in Core.
>
> Tomas
>
I don’t fully understand your storage engine. So the following deduction is just based on common sense.
a) It is possible to make unlimited number of 1-in-100-out txs
b) The maximum number of 100-in-1-out txs is limited by the number of previous 1-in-100-out txs
c) Since bitcrust performs not good with 100-in-1-out txs, for anti-DoS purpose you should limit the number of previous 1-in-100-out txs.
d) Limit 1-in-100-out txs == Limit UTXO growth
I’m not surprised that you find an model more efficient than Core. But I don’t believe one could find a model that doesn’t become more efficient with UTXO growth limitation.
Maybe you could try an experiment with regtest? Make a lot 1-in-100-out txs with many blocks, then spend all the UTXOs with 100-in-1-out txs. Compare the performance of bitcrust with core. Then repeat with 1-in-1-out chained txs (so the UTXO set is always almost empty)
One more question: what is the absolute minimum disk and memory usage in bitcrust, compared with the pruning mode in Core?

2023-06-07 17:58:10

- reply

📅 Original date posted:2017-03-29
📝 Original message:> On 29 Mar 2017, at 14:24, Emin Gün Sirer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> >Even when several of the experts involved in the document you refer has my respect and admiration, I do not agree with some of their conclusions
>
> I'm one of the co-authors of that study. I'd be the first to agree with your conclusion
> and argue that the 4MB size suggested in that paper should not be used without
> compensation for two important changes to the network.
>
> Our recent measurements of the Bitcoin P2P network show that network speeds
> have improved tremendously. From February 2016 to February 2017, the average
> provisioned bandwidth of a reachable Bitcoin node went up by approximately 70%.
> And that's just in the last year.
4 * 144 * 30 = 17.3GB per month, or 207GB per year. Full node initialisation will become prohibitive for most users until a shortcut is made (e.g. witness pruning and UTXO commitment but these are not trust-free)
>
> Further, the emergence of high-speed block relay networks, like Falcon (http://www.falcon-net.org <http://www.falcon-net.org/>)
> and FIBRE, as well as block compression, e.g. BIP152 and xthin, change the picture dramatically.
Also as the co-author of the selfish mining paper, you should know all these technology assume big miners being benevolent.
>
> So, the 4MB limit mentioned in our paper should not be used as a protocol limit today.
>
> Best,
> - egs
>
>
>
> On Tue, Mar 28, 2017 at 3:36 PM, Juan Garavaglia via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Alphonse,
>
>
>
> Even when several of the experts involved in the document you refer has my respect and admiration, I do not agree with some of their conclusions some of their estimations are not accurate other changed like Bootstrap Time, Cost per Confirmed Transaction they consider a network of 450,000,00 GH and today is 3.594.236.966 GH, the energy consumption per GH is old, the cost of electricity is wrong even when the document was made and is hard to find any parameter used that is valid for an analysis today.
>
>
>
> Again with all respect to the experts involved in that analysis is not valid today.
>
>
>
> I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s Law all has been verified for many years and support that 32 MB in 2020 are possible and equals or less than 1 MB in 2010.
>
>
>
> Again may be is not possible Johnson Lau and LukeJr invested a significant amount of time investigating ways to do a safe HF, and may be not possible to do a safe HF today but from processing power, bandwidth and storage is totally valid and Wang Chung proposal has solid grounds.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> From: Alphonse Pace [mailto:alp.bitcoin at gmail.com <mailto:alp.bitcoin at gmail.com>]
> Sent: Tuesday, March 28, 2017 2:53 PM
> To: Juan Garavaglia <jg at 112bit.com <mailto:jg at 112bit.com>>; Wang Chun <1240902 at gmail.com <mailto:1240902 at gmail.com>>
> Cc: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
>
>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> Juan,
>
>
>
> I suggest you take a look at this paper: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf <http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf> It may help you form opinions based in science rather than what appears to be nothing more than a hunch. It shows that even 4MB is unsafe. SegWit provides up to this limit.
>
>
>
> 8MB is most definitely not safe today.
>
>
>
> Whether it is unsafe or impossible is the topic, since Wang Chun proposed making the block size limit 32MiB.
>
>
>
>
>
> Wang Chun,
>
>
> Can you specify what meeting you are talking about? You seem to have not replied on that point. Who were the participants and what was the purpose of this meeting?
>
>
>
> -Alphonse
>
>
>
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com <mailto:jg at 112bit.com>> wrote:
>
> Alphonse,
>
>
>
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB limit valid in next halving, from network, storage and CPU perspective or 1MB was too high in 2010 what is possible or 1MB is to low today.
>
>
>
> If is unsafe or impossible to raise the blocksize is a different topic.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> From: bitcoin-dev-bounces at lists.linuxfoundation.org <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org> [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>] On Behalf Of Alphonse Pace via bitcoin-dev
> Sent: Tuesday, March 28, 2017 2:24 PM
> To: Wang Chun <1240902 at gmail.com <mailto:1240902 at gmail.com>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> What meeting are you referring to? Who were the participants?
>
>
>
> Removing the limit but relying on the p2p protocol is not really a true 32MiB limit, but a limit of whatever transport methods provide. This can lead to differing consensus if alternative layers for relaying are used. What you seem to be asking for is an unbound block size (or at least determined by whatever miners produce). This has the possibility (and even likelihood) of removing many participants from the network, including many small miners.
>
>
>
> 32MB in less than 3 years also appears to be far beyond limits of safety which are known to exist far sooner, and we cannot expect hardware and networking layers to improve by those amounts in that time.
>
>
>
> It also seems like it would be much better to wait until SegWit activates in order to truly measure the effects on the network from this increased capacity before committing to any additional increases.
>
>
>
> -Alphonse
>
>
>
>
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/2a360938/attachment-0001.html>

2023-06-07 17:55:38

- reply

📅 Original date posted:2017-01-25
📝 Original message:Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to himself again (with different tx format). But as Bob gets all the money on both forks, it is already a successful replay
> On 25 Jan 2017, at 15:15, Natanael <natanael.l at gmail.com> wrote:
>
>
> Den 25 jan. 2017 08:06 skrev "Johnson Lau" <jl2012 at xbt.hk <mailto:jl2012 at xbt.hk>>:
> What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter.
>
> Read it again.
>
> The validation algorithm would be extended so that the transaction can't be replayed, because replaying it in the other network REQUIRES a child transaction in the same block that is valid, a child transaction the is unique to the network. By doing this policy change simultaneously in both networks, old pre-signed transactions *can not be replayed by anybody but the owner* of the coins (as he must spend them immediately in the child transaction).
>
> It means that as soon as spent, the UTXO sets immediately and irrevocably diverges across the two networks. Which is the entire point, isn't it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/2ead65d2/attachment-0001.html>

2023-06-07 17:55:38

- reply

📅 Original date posted:2017-01-25
📝 Original message:What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter.
> On 25 Jan 2017, at 09:22, Natanael <natanael.l at gmail.com> wrote:
>
>
>
> Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
>
>
> B. For transactions created before this proposal is made, they are not protected from anti-replay. The new fork has to accept these transactions, as there is no guarantee that the existing fork would survive nor maintain any value. People made time-locked transactions in anticipation that they would be accepted later. In order to maximise the value of such transactions, the only way is to make them accepted by any potential hardforks.
>
> This can be fixed.
>
> Make old-format transactions valid *only when paired with a fork-only follow-up transaction* which is spending at least one (or all) of the outputs of the old-format transaction.
>
> (Yes, I know this introduces new statefulness into the block validation logic. Unfortunately it is necessary for maximal fork safety. It can be disabled at a later time if ever deemed no longer necessary.)
>
> Meanwhile, the old network SHOULD soft-fork in an identical rule with a follow-up transaction format incompatible with the fork.
>
> This means that old transactions can not be replayed across forks/networks, because they're not valid when stand-alone. It also means that all wallet clients either needs to be updated OR paired with software that intercepts generated transactions, and automatically generates the correct follow-up transaction for it (old network only).
>
> The rules should be that old-format transactions can't reference new-format transactions, even if only a softfork change differ between the formats. This prevents an unnecessary amount of transactions pairs generated by old wallets. Thus they can spend old outputs, but not spend new ones.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/7ef54e56/attachment.html>

2023-06-07 17:55:37

- reply

📅 Original date posted:2017-01-25
📝 Original message:Yes, it’s similar. I’ll quote your design if/when I formalise my BIP. But it seems they are not the same: yours is opt-out, while mine is opt-in.
However, my proposal in nowhere depends on standardness for the protection. It depends on the new network enforcing a new SignatureHash for txs with an nVersion not used in the existing network. This itself is a hardfork and the existing network would never accept such txs.
This is to avoid requiring any consensus changes to the existing network, as there is no guarantee that such softfork would be accepted by the existing network. If the new network wants to protect their users, it’d be trivial for them to include a SignatureHash hardfork like this, along with other other hardfork changes. Further hardforks will only require changing the network characteristic bit, but not the SignatureHash.
If the hardfork designers don’t like the fix of BIP143, there are many other options. The simplest one would be a trivial change to Satoshi’s SignatureHash, such as adding an extra value at the end of the algorithm. I just don’t see any technical reasons not to fix the O(n^2) problem altogether, if it is trivial (but not that trivial if the hardfork is not based on segwit)
> On 25 Jan 2017, at 02:52, Tom Harding <tomh at thinlink.com> wrote:
>
> On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
>> 9. If the network characteristic byte is non-zero, and the existing
>> network characteristic bit is set, the masked version is used to
>> determine whether a transaction should be mined or relayed (policy change)
>
> Johnson,
>
> Your proposal supports 8 opt-out bits compatible with may earlier
> description:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
>
> If the existing network really wants to play along, it should execute a
> soft fork as soon as possible to support its own hard-fork opt-out bit
> ("network characteristic bit"). It is totally inadequate for a new
> network to rely on non-standardness in the existing network to prevent
> replay there. Instead, in the absence of a supported opt-out bit in the
> existing network, a responsible new network would allow something that
> is invalid in the existing network, for transactions where replay to the
> existing network is undesirable.
>
> It is an overreach for your BIP to suggest specific changes to be
> included in the new network, such as the specific O(n^2) fix you
> suggest. This is a matter for the new network itself.
>
>

2023-06-07 17:54:41

- reply

📅 Original date posted:2016-12-04
📝 Original message:Based on Luke Dashjr’s code and BIP: https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki , I created an experimental network to show how a new header format may be implemented.
Basically, the header hash is calculated in a way that non-upgrading nodes would see it as a block with only the coinbase tx and zero output value. They are effectively broken as they won’t see any transactions confirmed. This allows rewriting most of the rules related to block and transaction validity. Such technique has different names like soft-hardfork, firmfork, evil softfork, and could be itself a controversial topic. However, I’d rather not to focus on its soft-hardfork property, as that would be trivial to turn this into a true hardfork (e.g. setting the sign bit in block nVersion, or setting the most significant bit in the dummy coinbase nLockTime)
Instead of its soft-HF property, I think the more interesting thing is the new header format. The current bitcoin header has only 80 bytes. It provides only 32bits of nonce space and is far not enough for ASICs. It also provides no room for committing to additional data. Therefore, people are forced to put many different data in the coinbase transaction, such as merge-mining commitments, and the segwit commitment. It is not a ideal solution, especially for light wallets.
Following the practice of segwit development of making a experimental network (segnet), I made something similar and call it the Forcenet (as it forces legacy nodes to follow the post-fork chain)
The header of forcenet is mostly described in Luke’s BIP, but I have made some amendments as I implemented it. The format is (size in parentheses; little endian):
Height (4), BIP9 signalling field (4), hardfork signalling field (3), merge-mining hard fork signalling field (1), prev hash (32), timestamp (4), nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32), Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8), number of tx (4), merkle branches leading to header C (compactSize + 32 bit hashes)
In addition to increasing the max block size, I also showed how the calculation and validation of witness commitment may be changed with a new header. For example, since the commitment is no longer in the coinbase tx, we don’t need to use a 0000….0000 hash for the coinbase tx like in BIP141.
Something not yet done:
1. The new merkle root algorithm described in the MMHF BIP
2. The nTxsSigops has no meaning currently
3. Communication with legacy nodes. This version can’t talk to legacy nodes through the P2P network, but theoretically they could be linked up with a bridge node
4. A new block weight definition to provide incentives for slowing down UTXO growth
5. Many other interesting hardfork ideas, and softfork ideas that works better with a header redesign
For easier testing, forcenet has the following parameters:
Hardfork at block 200
Segwit is always activated
1 minutes block with 40000 (prefork) and 80000 (postfork) weight limit
50 blocks coinbase maturity
21000 blocks halving
144 blocks retarget
How to join: codes at https://github.com/jl2012/bitcoin/tree/forcenet1 , start with "bitcoind —forcenet" .
Connection: I’m running a node at 8333.info with default port (38901)
Mining: there is only basic internal mining support. Limited GBT support is theoretically possible but needs more hacking. To use the internal miner, writeup a shell script to repeatedly call “bitcoin-cli —forcenet generate 1”
New RPC commands: getlegacyblock and getlegacyblockheader, which generates blocks and headers that are compatible with legacy nodes.
This is largely work-in-progress so expect a reset every couple weeks
jl2012
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 671 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161205/126aae21/attachment.sig>

2023-06-07 17:54:13

- reply

📅 Original date posted:2016-11-03
📝 Original message:Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different way from the Elements. Instead of hashing the data on stack, I directly put the 32 byte hash to the stack. This should be more flexible as not every system are using double-SHA256
https://github.com/jl2012/bitcoin/commits/mast_v3_master <https://github.com/jl2012/bitcoin/commits/mast_v3_master>
> On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi all,
>
> It is possible to implement covenants using two script extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already available in the Elements Alpha sidechain, so it is possible to construct covenants in Elements Alpha today. I have detailed how the construction works in a blog post at <https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html <https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html>>. As an example, I've constructed scripts for the Moeser-Eyal-Sirer vault.
>
> I'm interested in collecting and implementing other useful covenants, so if people have ideas, please post them.
>
> If there are any questions, I'd be happy to answer.
>
> --
> Russell O'Connor
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161103/1ad19231/attachment.html>

2023-06-07 17:54:03

- reply

📅 Original date posted:2016-10-17
📝 Original message:---- On Mon, 17 Oct 2016 04:08:29 +0800 Tom Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote ----
> On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote:
> > > Honestly, if the reason for the too-short-for-safety timespan is that
> > > you
> > > want to use BIP9, then please take a step back and realize that SegWit
> > > is a contriversial soft-fork that needs to be deployed in a way that is
> > > extra safe because you can't roll the feature back a week after
> > > deployment. All transactions that were made in the mean time turn into
> > > everyone-can- spent transactions.
> >
> > No one should use, nor anyone is advised to use, segwit transactions
> > before it is fully activated.
>
> Naturally, I fully agree.
>
> It seems I choose the wrong words, let me rephrase;
>
> You can't roll the SegWit back a week after people are allowed to send
> segwit transactions (lock-in + fallow period). All transactions that were
> made in the mean time turn into everyone-can- spent transactions.
>
> Because the network as a whole and any implementation is unable to roll back
> in an environment where SegWit is a contriversial soft-fork, it is super
> important to make sure that it is properly supported by all miners. This
> takes time and the risk you take by pushing this is that actual real people
> loose actual real money because of the issue I outlined inthe previous
> paragraph.
It would only happen if a large proportion of miners are false-signalling, like how BU did with BIP109 and forked your Classic away on testnet
But this is a egg-and-chicken problem and extending the grace period would not have any improvement. Until the rules are fully activated, it is totally impossible to tell if some miners are false signalling. The only method to prevent it, as usual, is the majority of miners will orphan the blocks of malicious miners. Like in the last year, some miners did not correctly implement BIP66 and got punished by losing many blocks.
If your are suggesting >51% of miners may false-signal (like in the BIP109 case), we already have a much bigger problem.
If people are really worrying about that, I would advise them not to use segwit extensively at the beginning, and wait for at least a week to see any sign of false signalling (which will be shown as invalid orphaned blocks). If the grace period was 2 weeks, they need to wait for 3 weeks; if the grace period was 2 months, they need to wait for 2 months and a week. Pre-activation consensus-imposed grace period could never replace post-activation self-imposed observation period

2023-06-07 17:53:44

- reply

📅 Original date posted:2016-10-24
📝 Original message:Some comments and questions
1. In the BIP you mentioned scriptSig 3 times, but I don't think you are really talking about scriptSig. Especially, segwit has aborted the use of scriptSig to fix malleability. From the context I guess you mean redeemScript (see BIP141)
2. It seems that 51% of miners may steal all money from the peg, right? But I think this is unavoidable for all 2-way-peg proposals. To make it safer you still need notaries.
3. Instead of using a OP_NOPx, I suggest you using an unused code such as 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that does not write to the stack.
4. I don't think you should simply replace "(witversion == 0)" with "((witversion == 0) || (witversion == 1))". There are only 16 available versions. It'd be exhausted very soon if we use a version for every new opcode. As a testing prototype this is fine, but the actual softfork should not waste a witversion this way. We need a better way to coordinate the use of new witness version. BIP114 suggests an additional field in the witness to indicate the script version (https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki)
5. It seems this is the first BIP in markdown format, not mediawiki (but this is allowed by BIP1)
6. The coinbase space is limited to 100 bytes and is already overloaded by many different purposes. I think any additional consensus critical message should go to a dummy scriptPubKey like the witness commitment. You may consider to have a new OP_RETURN output like BIP141, with different magic bytes. However, please don't make this output mandatory (cf. witness commitment output is optional if the block does not have witness tx)
6a. "..........due to lack of space to include the proper ack tag in a block": this shouldn't happen if you use a OP_RETURN output
7. "It can be the case that two different secondary blockchains specify the same transaction candidate, but **at least** one of them will clearly be unauthentic."
8. Question: is an ack-poll valid only for 1 transaction? When the transaction is confirmed, could full nodes prune the corresponding ack-poll data? (I think it has to be prunable after spending because ack-poll data is effectively UTXO data)
9. No matter how you design a softfork, "Zero risk of invalidating a block" couldn't be true for any softfork. For example, even if a miner does not include any txs with OP_COUNT_ACKS, he may still build on top of blocks with invalid OP_COUNT_ACKS operations.
---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote ----
> Since ScalingBitcoin is close, I think this is a good moment to publish our proposal on drivechains. This BIP proposed the drivechain we'd like to use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented in Bitcoin. Until that happens, we're using a federated approach.
> I'm sure that adding risk-less Bitcoin extensibility through sidechains/drivechains is what we all want, but it's of maximum importance to decide which technology will leads us there.
> We hope this work can also be the base of all other new 2-way-pegged blockchains that can take Bitcoin the currency to new niches and test new use cases, but cannot yet be realized because of current limitations/protections.
>
> The full BIP plus a reference implementation can be found here:
>
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
>
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> (Note: Code is still unaudited)
>
> As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode that counts acks and nacks tags in coinbase fields, and push the resulting totals in the script stack.
>
> The system was designed with the following properties in mind:
>
> 1. Interoperability with scripting system
> 2. Zero risk of invalidating a block
> 3. No additional computation during blockchain management and re-organization
> 4. No change in Bitcoin security model
> 5. Bounded computation of poll results
> 6. Strong protection from DoS attacks
> 7. Minimum block space consumption
> 8. Zero risk of cross-secondary chain invalidation
>
> Please see the BIP draft for a more-detailed explanation on how we achieve these goals.
>
> I'll be in ScalingBitcoin in less than a week and I'll be available to discuss the design rationale, improvements, changes and ideas any of you may have.
>
> Truly yours,
> Sergio Demian Lerner
> Bitcoiner and RSK co-founder
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:53:14

- reply

📅 Original date posted:2016-09-01
📝 Original message:Restriction for segwit OP_IF argument as a policy has got a few concept ACK. I would like to have more people to ACK or NACK, especially the real users of OP_IF. I think Lightning network would use that at lot.
Pull request: https://github.com/bitcoin/bitcoin/pull/8526
more related discussion could be found at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html
It does have impact if your script uses the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts.
>
> On August 16, 2016 at 1:53 PM Johnson Lau via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> https://github.com/bitcoin/bitcoin/pull/8526
>
> BIP: x
> Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
> Author: Johnson Lau <jl2012 at xbt.hk>
> Status: Draft
> Type: Standards Track
> Created: 2016-08-17
>
> Abstract
>
> This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.
>
> Motivation
>
> OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.
>
> The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.
>
> Specification
>
> In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.
>
> This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.
>
> Compatibility
>
> This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).
>
> Implementation
>
> https://github.com/bitcoin/bitcoin/pull/8526
>
> Copyright
>
> This work is placed in the public domain.
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - https://gpgtools.org
>
> iQGcBAEBCgAGBQJXs1LgAAoJEO6eVSA0viTSrJQL/A/womJKgi4FuyBTL9oykCss
> aBMNN9+SLtmuH7SBgEUGZ8TFxa2st+6RP6Imu+Vvn4O5sXQl3DIXV+X38X93sUYk
> wrjdpvdpqFFYJezPDESz6pR/6bZ1ES0aO2QqX578/8sqr8GO6L388s66vJeIGj4n
> 0LWW8sdEypMuV3HUG/9FFdUNHgiVX1U0sS1rT3P4aN30JYtb7PQpd7r8KTMta7Rt
> L1VOZB+W3m2m2YZ9gB7IRmMfzzNm2QXRTPIZXt2x3mYDBuMkp+zEd5+ogA4sBpgP
> wp2+l/aos686v0w8QYiNUX2+9Qpe7+238qUpw75d2XJYmLzdotWFvmp4g1hP+awX
> HEfwe4BUM+El17LjrHkNeMWNJXMlhTtXb2i0XMj8tU5lZVHep4WpQ+LEahrNlsUl
> FdFsi3q8HeWh8JsGaNCL41Bgbg/rKb5hUXyF6hTRHa//E6llOrpXRnsloKgBLv8c
> QezgKTAPwwgdjcS6Ek0AqgLp7bCFRijCduYH9i9uaQ==
> =lLIZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160901/8e47cd9f/attachment.html>

2023-06-07 17:53:11

- reply

📅 Original date posted:2016-08-24
📝 Original message:Adding witness data to a non-segwit script is invalid by consensus:
https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/interpreter.cpp#L1467
This PR will detect such violation early and ban the peer:
https://github.com/bitcoin/bitcoin/pull/8499
Another approach is to run the scripts of all incoming transactions. That's not too bad as you have already fetched the utxos which is a major part of validation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/957edeac/attachment.html>

2023-06-07 17:52:58

- reply

📅 Original date posted:2016-08-17
📝 Original message:> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Okay.
>
> I'm not really opposed to this BIP, but I am worried that fighting script malleability is a battle that can never be won; even leaving one avenue of malleability open is probably just as bad as having many avenues of malleability, so it just doesn't seem worthwhile to me.
Not really. I think the goal is to protect as many common scripts as possible.
For example:
1) BIP146 (Low S values signatures) will eliminate all malleability for P2WPKH
2) BIP146 + null dummy value for CHECKMULTISIG ("NULLDUMMY") will eliminate all malleability for simple multi-sig in P2WSH. This is particularly interesting since without NULLDUMMY, attackers are able to replace the dummy value with anything.
3) BIP146 + NULLDUMMY + minimal IF argument ("MINIMALIF") will eliminate malleability for any Lightening Network scripts that I'm aware of.
With 3), 99.99% of segwit transactions in foreseeable future should be fully protected.
The plan is to implement MINIMALIF as a relay policy first, and enforce the softfork after further risks assessment. This BIP serves as a warning to users for not using incompatible script.
Peter Todd:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode that fails unless the top item on the stack is a minimally encoded true or false value, to allow script writers to opt into this behavior; it's not always ideal.
I believe all Lightening Network scripts (the only real users of IF/NOTIF in foreseeable future) are already compatible with MINIMALIF. It may not be a good idea for them to spend 1 more byte to get protected.
If people want to have the original OP_IF behaviour, a simple way would be using "0NOTEQUAL IF". However, this works only if the argument is a valid number (also beware of MINIMALDATA rule in BIP62).
To completely replicate the original behaviour, one may use:
"DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} ELSE DROP {else script} ENDIF"
This is because we don't have a simple OP_CASTTOBOOL, and IFDUP is 1 of the 4 codes that perform CastToBool on top stack item (the others are VERIFY, IF, and NOTIF; and VERIFY can't be used here since it terminates the script with a False).

2023-06-07 17:52:58

- reply

📅 Original date posted:2016-08-17
📝 Original message:> On August 17, 2016 at 12:40 AM Luke Dashjr <luke at dashjr.org> wrote:
>
>
> On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> > To completely replicate the original behaviour, one may use:
> > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}
> > ELSE DROP {else script} ENDIF"
>
> This is much uglier than expected. IMO if that's the best workaround for the
> current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if they
> need to avoid malleability issues.
It is ugly only if you want to faithfully replicate the behaviour. I'd argue that in no real use case you need to do this. For example, "OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must return a valid MINIMALDATA number.
And your workaround does not fix malleability, since any non-0x01 values are valid FALSE
However, in some case, enforcing MINIMALIF does require 1 more witness byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html
I think the best strategy is to make it a relay policy first, and decide whether we want a softfork later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/c3a1cef3/attachment.html>

2023-06-07 17:52:55

- reply

📅 Original date posted:2016-08-16
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
https://github.com/bitcoin/bitcoin/pull/8526
BIP: x
Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Author: Johnson Lau <jl2012 at xbt.hk>
Status: Draft
Type: Standards Track
Created: 2016-08-17
Abstract
This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.
Motivation
OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.
The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.
Specification
In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.
This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.
Compatibility
This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).
Implementation
https://github.com/bitcoin/bitcoin/pull/8526
Copyright
This work is placed in the public domain.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQGcBAEBCgAGBQJXs1LgAAoJEO6eVSA0viTSrJQL/A/womJKgi4FuyBTL9oykCss
aBMNN9+SLtmuH7SBgEUGZ8TFxa2st+6RP6Imu+Vvn4O5sXQl3DIXV+X38X93sUYk
wrjdpvdpqFFYJezPDESz6pR/6bZ1ES0aO2QqX578/8sqr8GO6L388s66vJeIGj4n
0LWW8sdEypMuV3HUG/9FFdUNHgiVX1U0sS1rT3P4aN30JYtb7PQpd7r8KTMta7Rt
L1VOZB+W3m2m2YZ9gB7IRmMfzzNm2QXRTPIZXt2x3mYDBuMkp+zEd5+ogA4sBpgP
wp2+l/aos686v0w8QYiNUX2+9Qpe7+238qUpw75d2XJYmLzdotWFvmp4g1hP+awX
HEfwe4BUM+El17LjrHkNeMWNJXMlhTtXb2i0XMj8tU5lZVHep4WpQ+LEahrNlsUl
FdFsi3q8HeWh8JsGaNCL41Bgbg/rKb5hUXyF6hTRHa//E6llOrpXRnsloKgBLv8c
QezgKTAPwwgdjcS6Ek0AqgLp7bCFRijCduYH9i9uaQ==
=lLIZ
-----END PGP SIGNATURE-----

2023-06-07 17:50:54

- reply

📅 Original date posted:2016-05-20
📝 Original message:Using the hash of multiple blocks does not make it any safer. The miner of the last block always determines the results, by knowing the hashes of all previous blocks.
>
> == Security
> Pay-to-script-hash can be used to protect the details of contracts that use OP_PRANDOM from the prying eyes of miners. However, since there is also a non-zero risk that a participant in a contract may attempt to bribe a miner the inclusion of multiple block hashes as a source of randomness is a must. Every miner would effectively need to be bribed to ensure control over the results of the random numbers, which is already very unlikely. The risk approaches zero as N goes up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/18fa58d6/attachment.html>

2023-06-07 17:50:49

- reply

📅 Original date posted:2016-05-20
📝 Original message:How is this compared to my earlier proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html> ?
In my proposal, only the (pruned) UTXO set, and 32 bytes per archived block, are required for mining. But it is probably more difficult for people to spend an archived output. They need to know the status of other archived outputs from the same block. A full re-scan of the blockchain may be needed to generate the proof but this could be done by a third party archival node.
>
>
>
> ## Implementation
>
> Our proposed high-performance/low-latency delayed commitment full-node
> implementation needs to store the following data:
>
> 1) UTXO set
>
> Low-latency K:V map of txouts definitely known to be unspent. Similar to
> existing UTXO implementation, but with the key difference that old,
> unspent, outputs may be pruned from the UTXO set.
>
>
> 2) STXO set
>
> Low-latency set of transaction outputs known to have been spent by
> transactions after the most recent TXO commitment, but created prior to the
> TXO commitment.
>
>
> 3) TXO journal
>
> FIFO of outputs that need to be marked as spent in the TXO MMR. Appends
> must be low-latency; removals can be high-latency.
>
>
> 4) TXO MMR list
>
> Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,
> backed by a reference counted, cryptographically hashed object store
> indexed by digest (similar to how git repos work). High-latency ok. We'll
> cover this in more in detail later.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/532a993f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 671 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/532a993f/attachment.sig>