<unnamed>

Public Key

npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9

Profile Code

nprofile1qqsyjtayqt5r3yztmj8t9j86lgd239wlyepchlve33cmq89emd2slacpzpmhxue69uhkummnw3ezuamfdejslj35sw

Publishing to

nostr.wine

Last Notes

2023-06-09 14:54:31 CEST

- reply

📅 Original date posted:2019-03-21
📝 Original message:
> On 20 Mar 2019, at 4:07 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi aj,
>
> Re-reading again, I think perhaps I was massively confused by this:
>
>> - alternatively, we could require every script to have a valid signature
>> that commits to the input. In that case, you could do eltoo with a
>> script like either:
>>
>> <A> CHECKSIGVERIFY CHECKSIG
>> or CHECKSIGVERIFY <Q> CHECKSIG
>>
>>
>> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
>> a key they both know the private key for. In the first case, Alice
>> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
>> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
>> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
>> finish that when they wanted to publish.
>
> Do you mean that *either* of the above two scripts is OK, *or* do you mean they are alternatives within a single MAST or `OP_IF`?
>
It means either.
If you use <A> CHECKSIGVERIFY CHECKSIG style, A and B will exchange the NOINPUT sig, and they will add the required non-NOINPUT sig when needed.
If you use <muSig(A,B)> CHECKVERIFY <Q> CHECKSIG, A and B will co-sign the muSig(A,B) with NOINPUT. They will also share the private key of Q, so they could produce a non-NOINPUT sig when needed.
The first style is slightly easier as it doesn’t need muSig. But with 3 or more parties, the second style is more efficient.
However, if you use watchtower, you have to use the second style. That means you need to share the private key for Q with the watchtower, That also means the watchtower will have the ability to reply the NOINPU muSig. But it is still strictly better than anyone-can-replay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190321/7a2ef867/attachment.html>

2023-06-07 20:18:24 CEST

- reply

📅 Original date posted:2019-05-26
📝 Original message:This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set.
In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no way to tell whether it is segwit-enabled or not. So there needs to be a way to tell the validator that “the witness for this input is empty”, and it is the “00”.
> On 27 May 2019, at 12:18 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>
> ……. for the 00 number of witness
> data for non segwit inputs the one that is doing the transaction knows
> which inputs are segwit or not, then parsing the transaction you can
> associate the correct input to the correct witness data, without the
> need of 00, so I must be missing the use case

2023-06-07 20:18:22 CEST

- reply

📅 Original date posted:2019-05-26
📝 Original message:> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
Witness is not script. There is no op_pushdata or any other opcodes.
Witness is a stack. For each input, the witness starts with a CCompactSize for the number of stack elements for this input. Each stack element in turns starts with a CCompactSize for the size of this element, followed by the actual data
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
A “00” element means the size of this element is zero. Since it’s zero size, no data is followed. This will create an empty element on the stack. It’s effectively same as OP_0 (Again, witness is not script)
A “0100” element means the element size is one, and the data for this element is “00”. So it will leave an 1-byte element on the stack.
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
The “00” here means "this input has no witness stack element”. You need this even for non segwit inputs, because there is no way to tell whether an input is segwit-enabled or not, until you look up the UTXO, which might not be always available. Transaction serialization couldn’t rely on contextual information.
However, if all inputs have no stack element, the spec requires you to always use the non-segwit serialization.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:16:11 CEST

- reply

📅 Original date posted:2019-02-09
📝 Original message:In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC respectively, there are few ways they could make the settlement tx.
The first type we may call it “simple settlement”, which has 3 outputs with A=2, B=3, C=6.
The second type we may call it “fully combinatorial settlement”, which has 3 outputs with (A & B), (B & C), and (A & C). The value distribution is flexible, but never exceed the total balance of the involved parties. For example, (A & B) may have any value between 0 and 5BTC. For the following example, I will use (A & B) = 3; (B & C) = 6; (A & C) = 2, but there are infinitely many valid combinations.
The third type we may call it “partially combinatorial settlement”. It may have 2 multi-sig outputs, for example, (A & B) = 4 and (B & C) = 7; or 1 multi-sig output and 1 single-sig output, for example, (A & B) = 5 and C=6 (known as "semi-cooperative channel closing” SCCC in my last post)
I’ll just focus on the fully combinatorial settlement. The partial type works in the same way, with benefits and limitations.
In a combinatorial settlement, the multi-sig outputs are actually eltoo-style scripts. Therefore, A and B will further distribute the value of (A & B) by a 2-party eltoo channel (“branch channels"). Again, there are infinitely many valid ways to distribute the values. If the AB branch channel is distributed as A=1 and B=2, then the BC channel must be B=1 and C=5, and the AC channel must be A=1 and C=1.
A clear benefit of this model is that any 2 parties could trade with each other, in the absence of any other party(s), as long as there is enough liquidity in their branch channel. There is also no way to “fork” the state, because liquidity is restricted to each branch channel. In some way, this is like the existing lightning network where the 3 parties have direct channel with each other. However, this is superior to lightning network, because when the 3 parties are online simultaneously, they could re-distribute the channel capacities without closing any channels. They could even change it to a partially combinatorial settlement. If they find that A and C rarely trade with each other, they could remove the (A & C) output, and improve the capacities of the remaining channels. If C is going offline for a week, they could make it (A & B), C, (aka. SCCC) which will maximise the capacity of the AB branch channel, and minimise the cost in case C is not coming back.
A problem with combinatorial settlement is the increased costs of uncooperative settlement. It is more expensive, as more parties are missing. Simple settlement has the same settlement cost for any number of missing party. However, even if one party is missing, a simple settled channel will cease to function and force an immediate on-chain settlement. In combinatorial settlement, the surviving parties may keep trading, may or may not with reduced capacity depending on the exact settlement model, and in the meantime hope that the missing parties may return.
It requires 6 outputs for 4 parties doing fully combinatorial settlement, 10 outputs for 5 parties, 15 outputs for 6 parties, etc. However, in a many parties situation, not every parties might want to trade with all the other parties, and those branch channels might be omitted to improve the capacities of the other channels. If some pairs want to trade without a direct branch channel, they might try to find a third (internal) party to forward the tx. When the next time all parties are online, they could rearrange the branch channel capacities at no cost.
The combinatorial settlement model could be generalised to a hierarchical settlement model, where we might have 4 settlement outputs (A&B&C), (A&B&D), (A&C&D), (B&C&D) for a 4-party channel, and each settlement output will have 3 branch channels. If A is missing, for example, we will still have one BC branch channel, one BD branch channel, one CD branch channel, and one BCD 3-party branch channel. The benefit of having a BCD 3-party branch channel is the 3 parties could rearrange the channel capacities without involving A. Let’s say D is going for vacation, he could do a SCCC in the BCD branch channel to maximise the capacity of its BC channel. Without the involvement of A, however, the capacities of the other BC, BD, and CD branch channels are not modifiable, and B and C’s balance in the BD/CD channels are frozen during the absence of D.
As the number of parties increase, the number of settlement txs will grow factorially in a fully hierarchical settlement model, and will soon be out-of-control. The result could be catastrophic if many parties are gone. So the group needs to continuously evaluate the risks of each party being missing, and modify the settlement model accordingly.
> On 9 Feb 2019, at 6:01 PM, Alejandro Ranchal Pedrosa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>>
>> Side note: I was not able to come up with an similar, eltoo-like protocol that works
>> if you can't predict in advance who will become absent.
>>
> An eltoo-like protocol that works (without going on-chain) if you can't predict in advance who will become absent would be a childchain. If the off-chain protocol can continue updating in the abscence of other parties, it means that other parties' signatures must not be required when they are not involved in the off-chain state update. If other parties' signatures must not be required, there must be a way of having a common verifiable 'last state' to prevent a party to simultaneously 'fork' the state with two different parties, and double-spend. A solution for this is a childchain for Bitcoin. An example of this is what is known as a 'Broken Factory' attack [1] (https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
>
>> If the expectation is that the unresponsive party returns, fungibility is
>> not reduced due to output tagging because the above scheme can be used
>> off-chain until the original channel can be continued.
>
> I believe that in many cases other parties won't be able to continue until the unresponsive parties go back online. That might be true in particular scenarios, but generally speaking, the party might have gone unresponsive during a factory-level update (i.e. off-chain closing and opening of channels), while some parties might have given out their signature for the update without receiving a fully signed transaction. In this case they do not even know which channel they have open (the one of the old state that they have fully signed, or the one for the new state that they have given out their signature for). This is known as a 'Stale Factory', and can be exploited by an adversary in a 'Stale Factory' attack [1]. Even if they knew which state they are in (i.e. the party went unresponsive but not during a factory-level update), some of them might have run out of funds in some of their channels of the factory, and might want to update, while they will not be willing to wait for a party to go back online (something for which they also have zero guarantees of).
>
> An eltoo-like protocol that works (allowing going on-chain) if you can't in advance who will become absent, then this is precisely why 'Transaction Fragments' have been suggested. They allow an eltoo-like protocol even when one cannot predict in advance who will become absent, or malicious (by publishing invalid states), cause the non-absent parties can unite their fragments and create a valid spendable factory-level transaction that effectively kicks out the malicious parties, while leaving the rest of the factory as it was. To the best of my understanding, the eltoo original proposal also allows this though.
>
> Best,
>
> Alejandro.
>
> [1]: Scalable Lightning Factories for Bitcoin, https://eprint.iacr.org/2018/918.pdf
>
>
> On 08/02/2019 20:01, Jonas Nick via bitcoin-dev wrote:
>> Output tagging may result in reduced fungibility in multiparty eltoo channels.
>> If one party is unresponsive, the remaining participants want to remove
>> the party from the channel without downtime. This is possible by creating
>> settlement transactions which pay off the unresponsive party and fund a new
>> channel with the remaining participants.
>>
>> When the party becomes unresponsive, the channel is closed by broadcasting the
>> update transaction as usual. As soon as that happens the remaining
>> participants can start to update their new channel. Their update signatures
>> must use SIGHASH_NOINPUT. This is because in eltoo the settlement txid is not
>> final (because update tx is not confirmed and may have to rebind to another
>> output). Therefore, the funding output of the new channel must be NOINPUT
>> tagged. Assuming the remaining parties later settle cooperatively, this loss
>> of fungibility would not have happened without output tagging.
>>
>> funding output update output settlement outputs update output
>> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) ] -> [ NOINPUT tagged: (A' & B'), -> ...
>> C' ]
>> If the expectation is that the unresponsive party returns, fungibility is
>> not reduced due to output tagging because the above scheme can be used
>> off-chain until the original channel can be continued.
>>
>> Side note: I was not able to come up with an similar, eltoo-like protocol that works
>> if you can't predict in advance who will become absent.
>>
>> On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev 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
>>>
>> _______________________________________________
>> 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 20:15:44 CEST

- 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 20:15:44 CEST

- 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 20:15:43 CEST

- 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 20:15:42 CEST

- reply

📅 Original date posted:2018-12-13
📝 Original message: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?

2023-06-07 20:15:36 CEST

- 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 20:15:33 CEST

- reply

📅 Original date posted:2018-12-12
📝 Original message:> On 12 Dec 2018, at 6:50 AM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
> On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012 at xbt.hk <mailto:jl2012 at xbt.hk>> wrote:
> The current proposal is that a 64-byte signature will be used for the default “signing all” sighash, and 65-byte for other sighash types. The space saved will allow a few more txs in a block, so I think it worths doing. However, this also makes witness weight estimation more difficult in multisig cases.
>
> This idea of signing witness weight has been brought up before. I think the concern is the difficulty to estimate the witness weight for complex scripts, which need this feature most. So it will work when it is not needed, and will not work when it is needed.
>
> Is there any script example that witness size malleability is unavoidable?
>
> I tend to think in opposite terms. Is there a proof that any script can be transformed into an equivalent one that avoids witness weight malleability? But I admit there is a trade off: If we don't allow for signature covers weight, and we do need it, it will be too late to add. On the other hand if we add signature covers weight, but it turns out that no Script ever needs to use it, then we've added that software complexity for no gain. However, I think the software complexity is relatively low, making it worthwhile.
>
> Moreover, even if witness weight malleability is entirely avoidable, it always seems to come at a cost. Taking as an example libwally's proposed " <https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>csv_2of3_then_2" Script <https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>, it begins with "OP_DEPTH OP_1SUB OP_1SUB" spending 3 vbytes to avoid any possible witness malleability versus just taking a witness stack item to determine the branch, costing 1 or 2 (unmalleated) vbytes. Now to be fair, under Taproot this particular script's witness malleability problem probably goes away. Nonetheless, I think it is fair to say that Bitcoin Script was designed without any regard given to scriptSig/witness malleability concerns and the result is that one is constantly fighting against malleability issues. Short of a wholesale replacement of Bitcoin Script, I do think that having an option for signature covers weight is one of the best ways to address the whole problem.
>
> Regarding your point about 64/65-byte signatures; I speculate that in most protocols, all parties that are able to consider signing the weight, know what sighash flags the other parties are expected to be using. However, your point is well-taken, and if we choose to adopt the option of signatures covering weight, we ought to make sure there exists a 65-byte signature that performs the equivalent of a sigHashAll (of course, still covering that particular sighash flag under the signature), to ensure that anti-weight-malleability can be use even when the sighash flags that other parties will use are unknown. Even with the extra vbytes in the signatures, there may be a net weight savings by avoiding the need for anti-malleability Script code. (It might also be reasonable to have participants create signatures for a small range of different weight values? (Sorry in advance to PSBT)).
I think the root cause of witness weight malleability is some opcodes accept variable size input (without affecting the output), and that input is provided by the puzzle solver. Going through the opcode list, I think such opcodes include IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, and all arithmetic opcode that accepts CScriptNum (including CHECKMULTISIG)
VERIFY, DROP, 2DROP, NIP are not real problem, since they should not be the first opcode to interact with data directly provided by the puzzle solver.
CHECKMULTISIG is fixed by BIP147. For the key number and sig number, they should be part of the script, so not malleable.
DEPTH is a problem only if its inputs are not later examined by other opcodes. Again, this is pointless.
The liberally example should be protected by the MINIMAL_IF policy, which requires the input of OP_IF be minimal. As you note, OP_IF could be replaced by taproot in many cases
Non-minimal CScriptNum is also banned as BIP62 policy.
For the purpose of preventing malicious third party witness bloating, all we need is the miners to enforce the policy. There is no reason for miners to accept size malleated txs, as that will reduce the usable block space. If they hate a tx, they would simply drop it, instead of wasting the block space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181213/a18091cd/attachment-0001.html>

2023-06-07 20:15:33 CEST

- reply

📅 Original date posted:2018-12-09
📝 Original message:The current proposal is that a 64-byte signature will be used for the default “signing all” sighash, and 65-byte for other sighash types. The space saved will allow a few more txs in a block, so I think it worths doing. However, this also makes witness weight estimation more difficult in multisig cases.
This idea of signing witness weight has been brought up before. I think the concern is the difficulty to estimate the witness weight for complex scripts, which need this feature most. So it will work when it is not needed, and will not work when it is needed.
Is there any script example that witness size malleability is unavoidable?
> On 7 Dec 2018, at 12:57 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> One more item to consider is "signature covers witness weight".
>
> While signing the witness weight doesn't completely eliminate witness malleability (of the kind that can cause grief for compact blocks), it does eliminate the worst kind of witness malleability from the user's perspective, the kind where malicious relay nodes increase the amount of witness data and therefore reduce the overall fee-rate of the transaction. Generally users should strive to construct their Bitcoin Scripts in such a way that witness malleability isn't possible, but as you are probably aware, this can be quite difficult to achieve as Scripts become more complex and maybe isn't even possible for some complex Scripts.
>
> Given the new fixed-sized signature of the Schnorr BIP, it becomes much easier to compute the final witness weight prior to signing. In complex multi-party signing protocol, the final witness weight might not be known at signing time for everyone involved, so the "signature covers witness weight" ought to be optional.
>
>

2023-06-07 20:15:19 CEST

- reply

📅 Original date posted:2018-11-23
📝 Original message:>Even still, each call to OP_CODESEPARATOR / OP_CHECKSIG pair requires recomputing a new #5. scriptCode from BIP 143, and hence computes a new transaction digest.
In the existing sighash (i.e. legacy and BIP143), there are 6 canonical SIGHASH types: 1, 2, 3, 0x81, 0x82, 0x83. In consensus, however, all 256 types are valid and distinct. An adversarial miner could use non-standard sighash types to nullify any attempt to cache sighash values (i.e. you have to compute a new tx digest for every OP_CHECKSIG, even without using OP_CODESEPARATOR).
The only way to prevent this is reject OP_CODESEPARATOR, FindAndDelete(), and non-standard SIGHASH with a softfork. However, this doesn’t work in the next-generation SIGHASH, as tens of standard sighash types will exist. And, more importantly, sighash cache is no longer necessary in segwit, with the legacy O(n^2) hash bug being fixed.
In summary, sighash cache is not necessary nor efficient in the next-generation SIGHASH, and is not a sufficient reason to remove OP_CODESEPARATOR, especially when people find OP_CODESEPARATOR useful in some way.
But just to be clear, I think OP_CODESEPARATOR should be deprecated in legacy scripts. There is a general negative sentiment against OP_CODESEPARATOR but I think we need to evaluate case by case.
> On 23 Nov 2018, at 6:10 AM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
>
>
> On Thu, Nov 22, 2018 at 3:53 PM Johnson Lau <jl2012 at xbt.hk <mailto:jl2012 at xbt.hk>> wrote:
> Assuming a script size of 128 bytes (including SHA256 padding), 2^20 scripts is 134MB. Double it to 268MB for the merkle branch hashes. With roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However, memory use is not considered.
>
> >each call to this operation effectively takes O(script-size) time
> I’m not sure if this is correct. Actually, CTransactionSignatureSerializer() scans every script for OP_CODESEPARATOR. Scripts with and without OP_CODESEPARATOR should take exactly the same O(script-size) time (see https://github.com/bitcoin/bitcoin/pull/14786 <https://github.com/bitcoin/bitcoin/pull/14786>)
> Also, this is no longer a concern under segwit (BIP143), which CTransactionSignatureSerializer() is not used. Actually, OP_CODESEPARATOR under segwit is way simpler than the proposed OP_MASK. If one finds OP_MASK acceptable, there should be no reason to reject OP_CODESEPARATOR.
>
> Even still, each call to OP_CODESEPARATOR / OP_CHECKSIG pair requires recomputing a new #5. scriptCode from BIP 143, and hence computes a new transaction digest. I understood that this issue was the main motivation for wanting to deprecate OP_CODESEPARATOR and remove it from later versions of script.
>
> However, given that we are looking at a combinatorial explosion in SIGHASH flag combinations already, coupled with existing SigOp limitations, maybe the cost of recomputing scriptCode with OP_CODESEPARATOR isn't such a big deal.
>
> And even if we choose remove the behavior of OP_CODESEPARATOR in new versions of Script, it seems more than 30 layers of sequential OP_IFs can be MASTified, so there is no need to use OP_CODESEPARATOR within that limit.
>
> >One suggestion I heard (I think I heard it from Pieter) to achieve the above is to add an internal counter that increments on every control flow operator,……...
> If I have to choose among OP_CODESEPARATOR and “flow operator counting”, I’d rather choose OP_CODESEPARATOR. At least we don’t need to add more lines to the consensus code, just for something that is mostly archivable with MAST.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181123/0c20c6f7/attachment-0001.html>

2023-06-07 20:15:18 CEST

- reply

📅 Original date posted:2018-11-22
📝 Original message:Assuming a script size of 128 bytes (including SHA256 padding), 2^20 scripts is 134MB. Double it to 268MB for the merkle branch hashes. With roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However, memory use is not considered.
>each call to this operation effectively takes O(script-size) time
I’m not sure if this is correct. Actually, CTransactionSignatureSerializer() scans every script for OP_CODESEPARATOR. Scripts with and without OP_CODESEPARATOR should take exactly the same O(script-size) time (see https://github.com/bitcoin/bitcoin/pull/14786)
Also, this is no longer a concern under segwit (BIP143), which CTransactionSignatureSerializer() is not used. Actually, OP_CODESEPARATOR under segwit is way simpler than the proposed OP_MASK. If one finds OP_MASK acceptable, there should be no reason to reject OP_CODESEPARATOR.
>One suggestion I heard (I think I heard it from Pieter) to achieve the above is to add an internal counter that increments on every control flow operator,……...
If I have to choose among OP_CODESEPARATOR and “flow operator counting”, I’d rather choose OP_CODESEPARATOR. At least we don’t need to add more lines to the consensus code, just for something that is mostly archivable with MAST.
> On 23 Nov 2018, at 12:23 AM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
> I see, so your suggestion is that a sequence of OP_IF ... OP_ENDIF can be replaced by a Merklized Script tree of that depth in practice.
>
> I'm concerned that at script creation time it takes exponential time to complete a Merkle root of depth 'n'. Can anyone provide benchmarks or estimates of how long it takes to compute a Merkle root of a full tree of various depths on typical consumer hardware? I would guess things stop becoming practical at a depth of 20-30.
>
> On Thu, Nov 22, 2018 at 9:28 AM Johnson Lau <jl2012 at xbt.hk> wrote:
> With MAST in taproot, OP_IF etc become mostly redundant, with worse privacy. To maximise fungibility, we should encourage people to use MAST, instead of improve the functionality of OP_IF and further complicate the protocol.
>
>
>> On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> So my question is whether anyone can see ways in which this introduces
>> redundant flexibility, or misses obvious use cases?
>>
>> Hopefully my comment is on-topic for this thread:
>>
>> Given that we want to move away from OP_CODESEPARATOR, because each call to this operation effectively takes O(script-size) time, we need a replacement for the functionality it currently provides. While perhaps the original motivation for OP_CODESEPARTOR is surrounded in mystery, it currently can be used (or perhaps abused) for the task of creating signature that covers, not only which input is being signed, but which specific branch within that input Script code is being signed for.
>>
>> For example, one can place an OP_CODESEPARATOR within each branch of an IF block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG operation. By doing so, signatures created for one clause cannot be used as signatures for another clause. Since different clauses in Bitcoin Script may be enforcing different conditions (such as different time-locks, hash-locks, etc), it is useful to be able to sign in such a way that your signature is only valid when the conditions for a particular branch are satisfied. In complex Scripts, it may not be practical or possible to use different public keys for every different clause. (In practice, you will be able to get away with fewer OP_CODESEPARATORS than one in every IF block).
>>
>> One suggestion I heard (I think I heard it from Pieter) to achieve the above is to add an internal counter that increments on every control flow operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the signature cover the value of this counter. Equivalently we divide every Bitcoin Script program into blocks deliminated by these control flow operator and have the signature cover the index of the block that the OP_CHECKSIG occurs within. More specifically, we will want a SigHash flag to enables/disable the signature covering this counter.
>>
>> There are many different ways one might go about replacing the remaining useful behaviour of OP_CODESEPARATOR than the one I gave above. I would be happy with any solution.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 20:15:17 CEST

- reply

📅 Original date posted:2018-11-24
📝 Original message:> On 23 Nov 2018, at 5:40 PM, Christian Decker via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Anthony Towns <aj at erisian.com.au> writes:
>> Commiting to just the sequence numbers seems really weird to me; it
>> only really prevents you from adding inputs, since you could still
>> replace any input that was meant to be there by almost any arbitrary
>> other transaction...
>
> It's a really roundabout way of committing to the inputs, I
> agree. I'm actually wondering if it makes sense to correct that
> additional blanked field in BIP118 at all since it seems there is no
> real use-case for NOINPUT that doesn't involve blanking the
> `hashSequence` as well.
I think we just make it as simple as this: Always commit to sequence of the same input. Commit to hashSequence if and only if all inputs and all outputs are signed.
The next-generation SIGHASH will introduce not only NOINPUT, but also signing of fees, previous scriptPubKey, and all input values, etc. So it won’t be a simple hack over BIP143. BIP118 might be better changed to be an informational BIP, focus on the rationale and examples of NOINPUT, and be cross-referenced with the consensus BIP.

2023-06-07 20:15:16 CEST

- 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 ENDIF <q> ...
>
> or:
>
> IF OP_MASK ENDIF ...
>
> 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 20:11:56 CEST

- 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 20:11:55 CEST

- 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 20:10:53 CEST

- reply

📅 Original date posted:2018-02-16
📝 Original message:Short history
----------------
Satoshi introduced sigops counting as a softfork to limit the number of signature operation in a block. He statically counted all OP_CHECK(MULTI)SIG(VERIFY) in both scriptSig and scriptPubKey, assumed a OP_CHECKMULTISIG is equivalent to 20 OP_CHECKSIG, and enforced a block limit of 20000 sigop. The counting is not contextual, i.e. one doesn’t need the UTXO set to determine the number of sigop. The counting was also static so one doesn’t need to execute a script in order to count sigop. However, this is completely wrong for few reasons: a) opcodes in scriptPubKey are not executed; b) scriptPubKey of spent UTXO, which are actually executed, are not counted at all; c) it greatly overestimate the cost of multi-sig; d) it counts sigop in unexecuted branch.
As P2SH was introduced, sigop counting also covered the sigop redeemScript. This is good because redeemScript is what being executed. It also improved the counting of OP_CHECKMULTISIG. If it is in certain canonical form, it would count the number of public keys instead of assuming it as 20. On the other hand, counting sigop becomes not possible without the UTXO set, since one needs UTXO to identify P2SH inputs. Also, the canonical OP_CHECKMULTISIG counting is not quite elegant and created more special cases in the code.
Segwit (BIP141) scaled the legacy sigop limit by 4x. So every legacy sigop becomes 4 new sigop, with a block limit of 80000 new sigop. P2WPKH is counted as 1 new sigop, and P2WSH is counted in the same way as P2SH.
Problem
------------
We now have multiple 2nd generation script proposals, such as BIP114, BIP117, taproot, etc. BIP114 and taproot allows static sigop counting, but not BIP117 as it requires execution to determine what would be run as script (like OP_EVAL). As we want to allow more complicated script functions, static sigop counting might not be easy. However, we still want to have a limit to avoid unexpected DoS attack.
Proposal
------------
Since we have a block weight limit of 4,000,000 and sigop limit of 80,000, each sigop could not use more than 50 weight unit on average. For new script proposals we could count the actual number of sigop at execution (i.e. skip unexecuted sigop, skip 0-size signature, count the actual checksig operations in multi-sig), and make sure the number of executed sigop * 50 is not greater than the size of the input.
The minimal size of each input is 32 (prevout.hash) + 4 (prevout.n) + 4 (nSequence) + 1 (empty scriptSig) = 41 bytes or 164 weight unit. So the new rule would require that (164 + input witness size) >= (actual_sigop * 50). This is a per-input limit, as script validation is parallel.
Since a compressed key is 33 bytes and a normal compact signature is 64 bytes, the 1:50 ratio should be more than enough to allow any normal use of CHECKSIG, unless people are doing weird things like 2DUP 2DUP 2DUP……..CHECKSIG CHECKSIG CHECKSIG CHECKSIG , which would have many sigop with a relatively small witness. Interactive per-tx signature aggregation allows 64bytes/tx signature, and per-block non-interatcitve signature aggregation allows 32bytes/signature (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html>). In such cases, the 1:50 ratio might not be enough if many signatures are aggregated. Depends on the number of sigop we could tolerate, the 1:50 ratio might be reduced to 1:32 or lower to make sure legitimate use would never hit the limit. I think 32 is reasonable as it is about the size of a public key, which would guarantee each pubkey must get a sigop slot.
So a relay node could be certain that a tx won’t spend excessive CPU power by just looking at its size. If it spends too much, it is invalid and script execution could be terminated early.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180216/296ee3ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180216/296ee3ec/attachment.sig>

2023-06-07 20:07:50 CEST

- 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 20:05:40 CEST

- reply

📅 Original date posted:2017-09-20
📝 Original message:> On 19 Sep 2017, at 11:09 AM, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
> wrote:
>> After the main discussion session it was observed that tail-call semantics
>> could still be maintained if the alt stack is used for transferring
>> arguments to the policy script.
>
> Isn't this a bug in the cleanstack rule?
>
> (Unrelated...)
>
> Another thing that came up during the discussion was the idea of replacing all
> the NOPs and otherwise-unallocated opcodes with a new OP_RETURNTRUE
> implementation, in future versions of Script. This would immediately exit the
> program (perhaps performing some semantic checks on the remainder of the
> Script) with a successful outcome.
>
> This is similar to CVE-2010-5141 in a sense, but since signatures are no
> longer Scripts themselves, it shouldn't be exploitable.
>
> The benefit of this is that it allows softforking in ANY new opcode, not only
> the -VERIFY opcode variants we've been doing. That is, instead of merely
> terminating the Script with a failure, the new opcode can also remove or push
> stack items. This is because old nodes, upon encountering the undefined
> opcode, will always succeed immediately, allowing the new opcode to do
> literally anything from that point onward.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I have implemented OP_RETURNTRUE in an earlier version of MAST (BIP114) but have given up the idea, for 2 reasons:
1. I’ve updated BIP114 to allow inclusion of scripts in witness, and require them to be signed. In this way users could add additional conditions for the validity of a signature. For example, with OP_CHECKBLOCKHASH, it is possible to make the transaction valid only in the specified chain. (More discussion in https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki#Additional_scripts_in_witness <https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki#Additional_scripts_in_witness> )
2. OP_RETURNTRUE does not work well with signature aggregation. Signature aggregation will collect (pubkey, message) pairs in a tx, combine them, and verify with one signature. However, consider the following case:
OP_RETURNTRUE OP_IF <pubkey> OP_CHECKSIGVERIFY OP_ENDIF OP_TRUE
For old nodes, the script terminates at OP_RETURNTRUE, and it will not collect the (pubkey, message) pair.
If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing the number 17 to the stack), new nodes will collect the (pubkey, message) pair and try to aggregate with other pairs. This becomes a hardfork.
--------
Technically, we could create ANY op code with an OP_NOP. For example, if we want OP_MUL, we could have OP_MULVERIFY, which verifies if the 3rd stack item is the product of the top 2 stack items. Therefore, OP_MULVERIFY OP_2DROP is functionally same as OP_MUL, which removes the top 2 items and returns the product. The problem is it takes more witness space.
If we don’t want this ugliness, we could use a new script version for every new op code we add. In the new BIP114 (see link above), I suggest to move the script version to the witness, which is cheaper.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170920/c37d065c/attachment-0001.html>

2023-06-07 20:00:57 CEST

- 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 19:59:41 CEST

- 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 19:59:41 CEST

- 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 19:58:10 CEST

- 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 19:58:04 CEST

- reply

📅 Original date posted:2017-03-29
📝 Original message:> On 29 Mar 2017, at 04:50, Tom Zander <tomz at freedommail.ch <mailto:tomz at freedommail.ch>> wrote:
>
> On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote:
>> So if we really want to get prepared for a potential HF with unknown
>> parameters,
>
> That was not suggested.
>
> Maybe you can comment on the very specific suggestion instead?
>
> --
> Tom Zander
> Blog: https://zander.github.io <https://zander.github.io/>
> Vlog: https://vimeo.com/channels/tomscryptochannel <https://vimeo.com/channels/tomscryptochannel>
Just take something like FlexTran as example. How you could get prepared for that without first finalising the spec?
Or changing the block interval from 10 minutes to some other value?
Also, fixing the sighash bug for legacy scripts?
There are many other ideas that require a HF:
https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas <https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9f5a04ec/attachment.html>

2023-06-07 19:58:03 CEST

- reply

📅 Original date posted:2017-03-28
📝 Original message:You are probably not the first one nor last one with such idea. Actually, Luke wrote up a BIP with similar idea in mind:
https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki <https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>
Instead of just lifting the block size limit, he also suggested to remove many other rules. I think he has given up this idea because it’s just too complicated.
If we really want to prepare for a hardfork, we probably want to do more than simply increasing the size limit. For example, my spoonnet proposal:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html>
In a HF, we may want to relocate the witness commitment to a better place. We may also want to fix Satoshi's sighash bug. These are much more than simple size increase.
So if we really want to get prepared for a potential HF with unknown parameters, I’d suggest to set a time bomb in the client, which will stop processing of transactions with big warning in GUI. The user may still have an option to continue with old rules at their own risks.
Or, instead of increasing the block size, we make a softfork to decrease the block size to 1kB and block reward to 0, activating far in the future. This is similar to the difficulty bomb in ETH, which will freeze the network.
> On 29 Mar 2017, at 00:59, Wang Chun via bitcoin-dev <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
> 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/f4f40e72/attachment.html>

2023-06-07 19:55:37 CEST

- reply

📅 Original date posted:2017-01-27
📝 Original message:> On 26 Jan 2017, at 03:32, Tom Harding <tomh at thinlink.com> wrote:
>
> On 1/24/2017 8:03 PM, Johnson Lau wrote:
>> it seems they are not the same: yours is opt-out, while mine is opt-in.
>
> I missed this. So in fact you propose a self-defeating requirement on the new network, which would force unmodified yet otherwise compatible systems to change to support the new network at all. This is unlikely to be included in new network designs.
>
> I suggest that the opt-out bits proposal comes from a more realistic position that would actually make sense for everyone.
>
I think there are some misunderstanding. You’d better read my source code if my explanation is not clear.
From my understanding our proposals are the same, just with a bitwise not (~) before the network characteristic byte. So you set a bit to opt-out a network, while I set a bit to opt-in a network (and opt-out any other)

2023-06-07 19:55:37 CEST

- 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 19:55:36 CEST

- reply

📅 Original date posted:2017-01-24
📝 Original message:This is a pre-BIP. Just need some formatting to make it a formal BIP
Motivation:
In general, hardforks are consensus rule changes that make currently invalid transactions / blocks valid. It requires a very high degree of consensus and all economic active users migrate to the new rules at the same time. If a significant amount of users refuse to follow, a permanent ledger split may happen, as demonstrated by Ethereum (“DAO hardfork"). In the design of DAO hardfork, a permanent split was not anticipated and no precaution has been taken to protect against transaction replay attack, which led to significant financial loss for some users.
A replay attack is an attempt to replay a transaction of one network on another network. It is normally impossible, for example between Bitcoin and Litecoin, as different networks have completely different ledgers. The txid as SHA256 hash guarantees that replay across network is impossible. In a blockchain split, however, since both forks share the same historical ledger, replay attack would be possible, unless some precautions are taken.
Unfortunately, fixing problems in bitcoin is like repairing a flying plane. Preventing replay attack is constrained by the requirement of backward compatibility. This proposal has the following objectives:
A. For users on both existing and new fork, anti-replay is an option, not mandatory.
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.
C. It doesn’t require any consensus changes in the existing network to avoid unnecessary debate.
D. As a beneficial side effect, the O(n^2) signature checking bug could be fixed for non-segregated witness inputs, optionally.
Definitions:
“Network characteristic byte” is the most significant byte of the nVersion field of a transaction. It is interpreted as a bit vector, and denotes up to 8 networks sharing a common history.
“Masked version” is the transaction nVersion with the network characteristic byte masked.
“Existing network” is the Bitcoin network with existing rules, before a hardfork. “New network” is the Bitcoin network with hardfork rules. (In the case of DAO hardfork, Ethereum Classic is the existing network, and the now called Ethereum is the new network)
“Existing network characteristic bit” is the lowest bit of network characteristic byte
“New network characteristic bit” is the second lowest bit of network characteristic byte
Rules in new network:
1. If the network characteristic byte is non-zero, and the new network characteristic bit is not set, this transaction is invalid in the new network. (softfork)
2. If the network characteristic byte is zero, go to 4
3. If the network characteristic byte is non-zero, and the new network characteristic bit is set, go to 4, regardless of the status of the other bits.
4. If the masked version is 2 or below, the new network must verify the transaction with the existing script rules. (no change)
5. If the masked version is 3 or above, the new network must verify the signatures with a new SignatureHash algorithm (hardfork). Segwit and non-segwit txs will use the same algorithm. It is same as BIP143, except that 0x2000000 is added to the nHashType before the hash is calculated.
Rules in the existing network:
6. No consensus rule changes is made in the existing network.
7. If the network characteristic byte is non-zero, and the existing network characteristic bit is not set, this transaction is not relayed nor mined by default (no change)
8. If the network characteristic byte is zero, no change
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)
10. Wallet may provide an option for setting the existing network characteristic bit.
Rationales (by rule number):
1. This makes sure transactions with only existing network characteristic bit set is invalid in the new network (opt-in anti-replay for existing network transactions on the new network, objective A)
2+4. This makes sure time-locked transactions made before this proposals are valid in the new network (objective B)
2+5. This makes sure transactions made specifically for the new network are invalid in the existing network (anti-replay for new network transactions on the old network); also fixing the O(n^2) bug (objectives A and D)
3. This is to prepare for the next hardfork from the new network (objective A)
6, 7, 8. These minimise the change to the existing network (objective C)
9, 10. These are not strictly needed until a hardfork is really anticipated. Without a significant portion of the network and miners implement this policy, however, no one should create such transactions. (objective A)
Limitations:
* It is not possible to protect transactions made before the proposal. To avoid a replay of such transactions, users should first spend at least a relevant UTXO on the new network so the replay transaction would be invalidated.
* It is up to the designer of a hardfork to decide whether this proposal is respected. As the DAO hardfork has shown how harmful replay attack could be, all hardfork proposals (except trivial and totally uncontroversial ones) should take this into account
* The size of network characteristic byte is limited to 8 bits. However, if we are sure that some of the networks are completely abandoned, the bits might be reused.
Reference implementation:
A demo is available in my forcenet2 branch: https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a <https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170124/a3516bfa/attachment.html>

2023-06-07 19:54:44 CEST

- reply

📅 Original date posted:2016-12-14
📝 Original message:I think that’s too much tech debt just for softforkability.
The better way would be making the sum tree as an independent tree with a separate commitment, and define a special type of softfork (e.g. a special BIP9 bit). When the softfork is activated, the legacy full node will stop validating the sum tree. This doesn’t really degrade the security by more than a normal softfork, as the legacy full node would still validate the total weight and nSigOp based on its own rules. The only purpose of the sum tree is to help SPV nodes to validate. This way we could even completely redefine the structure and data committed in the sum tree.
I’d like to combine the size weight and sigOp weight, but not sure if we could. The current size weight limit is 4,000,000 and sigop limit is 80,000. It’s 50:1. If we maintain this ratio, and define
weight = n * (total size + 3 * base size) + sigop , with n = 50
a block may have millions of sigops which is totally unacceptable.
On the other hand, if we make n too low, we may allow either too few sigop, or a too big block size.
Signature aggregation will make this a bigger problem as one signature may spend thousands of sigop
> On 14 Dec 2016, at 20:52, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>
>
> On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <jl2012 at xbt.hk <mailto:jl2012 at xbt.hk>> wrote:
> In a sum tree, however, since the nSigOp is implied, any redefinition requires either a hardfork or a new sum tree (and the original sum tree becomes a placebo for old nodes. So every softfork of this type creates a new tree)
>
> That's a good point.
>
> The only way to fix this is to explicitly commit to the weight and nSigOp, and the committed value must be equal to or larger than the real value. Only in this way we could redefine it with softfork. However, that means each tx will have an overhead of 16 bytes (if two int64 are used)
>
> The weight and sigop count could be transmitted as variable length integers. That would be around 2 bytes for the sigops and 3 bytes for the weight, per transaction.
>
> It would mean that the block format would have to include the raw transaction, "extra"/tree information and witness data for each transaction.
>
> On an unrelated note, the two costs could be combined into a unified cost. For example, a sigop could have equal cost to 250 bytes. This would make it easier for miners to decide what to charge.
>
> On the other hand, CPU cost and storage/network costs are not completely interchangeable.
>
> Is there anything that would need to be summed fees, raw tx size, weight and sigops that the greater or equal rule wouldn't cover?
>
> On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke at dashjr.org <mailto:luke at dashjr.org>> wrote:
>> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:
>> > Any new merkle algorithm should use a sum tree for partial validation and
>> > fraud proofs.
>>
>> PR welcome.
>>
>> Fair enough. It is pretty basic.
>>
>> https://github.com/luke-jr/bips/pull/2 <https://github.com/luke-jr/bips/pull/2>
>>
>> It sums up sigops, block size, block cost (that is "weight" right?) and fees.
>> _______________________________________________
>> 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161214/14889378/attachment.html>

2023-06-07 19:54:43 CEST

- reply

📅 Original date posted:2016-12-14
📝 Original message:I think the biggest problem of sum tree is the lack of flexibility to redefine the values with softforks. For example, in the future we may want to define a new CHECKSIG with witness script version 1. That would be counted as a SigOp. Without a sum tree design, that’d be easy as we could just define new SigOp through a softfork (e.g. the introduction of P2SH SigOp, and the witness v0 SigOp). In a sum tree, however, since the nSigOp is implied, any redefinition requires either a hardfork or a new sum tree (and the original sum tree becomes a placebo for old nodes. So every softfork of this type creates a new tree)
Similarly, we may have secondary witness in the future, and the tx weight would be redefined with a softfork. We will face the same problem with a sum tree
The only way to fix this is to explicitly commit to the weight and nSigOp, and the committed value must be equal to or larger than the real value. Only in this way we could redefine it with softfork. However, that means each tx will have an overhead of 16 bytes (if two int64 are used)
You could find related discussion here: https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee7a17208 <https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee7a17208>
Maybe we could make this optional: for nodes running exactly the same rules, they could omit the weight and nSigOp value in transmission. To talk to legacy nodes, they need to transmit the newly defined weight and nSigOp. But this makes script upgrade much complex.
> On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke at dashjr.org <mailto:luke at dashjr.org>> wrote:
> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:
> > Any new merkle algorithm should use a sum tree for partial validation and
> > fraud proofs.
>
> PR welcome.
>
> Fair enough. It is pretty basic.
>
> https://github.com/luke-jr/bips/pull/2 <https://github.com/luke-jr/bips/pull/2>
>
> It sums up sigops, block size, block cost (that is "weight" right?) and fees.
> _______________________________________________
> 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/20161214/3efb104f/attachment.html>

2023-06-07 19:54:42 CEST

- reply

📅 Original date posted:2016-12-14
📝 Original message:> On 5 Dec 2016, at 04:00, adiabat <rx at awsomnet.org> wrote:
>
> Interesting stuff! I have some comments, mostly about the header.
>
> 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)
>
> First, I'd really rather not have variable length fields in the header. It's so much nicer to just have a fixed size.
>
> Is having both TMR and WMR really needed? As segwit would be required with this header type, and the WMR covers a superset of the data that the TMR does, couldn't you get rid of the TMR? The only disadvantage I can see is that light clients may want a merkle proof of a transaction without having to download the witnesses for that transaction. This seems pretty minor, especially as once they're convinced of block inclusion they can discard the witness data, and also the tradeoff is that light clients will have to download and store and extra 32 bytes per block, likely offsetting any savings from omitting witness data.
>
I foresee there will be 2 types of headers under this system: the 80 bytes short header and the variable length full header. Short headers are enough to link everything up. SPV needs the full header only if they are interested in any tx in a block.
> The other question is that there's a bit that's redundant: height is also committed to in the coinbase tx via bip 34 (speaking of which, if there's a hard-fork, how about reverting bip 34 and committing to the height with coinbase tx nlocktime instead?)
you could omit the transmission of nHeight, as it is implied (saving 4bytes). Storing nHeight of headers is what every full and SPV nodes would do anyway
>
> Total size / weight / number of txs also feels pretty redundant. Not a lot of space but it's hard to come up with a use for them. Number of tx could be useful if you want to send all the leaves of a merkle tree, but you could also do that by committing to the depth of the merkle tree in the header, which is 1 byte.
Yes, I agree with you that these are not particularly useful. Sum tree is more useful but it has other problems (see my other reply)
Related discussion: https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee7a17208 <https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee7a17208>
>
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
No need. See my other reply
>
> Maybe this is too nit-picky; maybe it's better to put lots of stuff in for testing the forcenet and then take out all the stuff that wasn't used or had issues as it progresses.
>
> Thanks and looking forward to trying out forcenet!
>
> -Tadge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161214/fcada227/attachment-0001.html>

2023-06-07 19:54:42 CEST

- reply

📅 Original date posted:2016-12-14
📝 Original message:> On 14 Dec 2016, at 19:07, Luke Dashjr <luke at dashjr.org> wrote:
>
> On Wednesday, December 14, 2016 11:01:58 AM Johnson Lau via bitcoin-dev wrote:
>> There is no reason to use a timestamp beyond 4 bytes.
>
> Actually, there is: lock times... my overflow solution doesn't have a solution
> to that. :x
You could steal a few bits form tx nVersion through a softfork

2023-06-07 19:54:41 CEST

- 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 19:54:13 CEST

- 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 19:52:55 CEST

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