Nostr notes by

📅 Original date posted:2023-07-27 🗒️ Summary of this ...

2023-07-28T17:08:07+02:00

In reply to nevent1q…ukaj
_________________________

📅 Original date posted:2023-07-27
🗒️ Summary of this message: Not taking action against spam could be seen as acceptance. Some argue blocking spam is censorship and could lead to blocking regular transactions.
📝 Original message:
> not taking action against these inscription could be interpreted by spammers as tacit acceptance of their practice.

Note that some people, even on this mailing list, do not consider Ordinals as spam: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html

See? It was discussed when it started. Some people believe that blocking Ordinals is censorship, and could lead to blocking regular transactions in the future, just based on other criteria. That means, even if developers would create some official version with that option, then some people would not follow them, or even block Ordinals-filtering nodes, exactly as described in the linked thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html

> as spammers might perceive that the Bitcoin network tolerates this kind of behavior

But it is true, you have the whole pages, where you can find images, files, or other data, that was pushed on-chain long before Ordinals. The whole whitepaper was uploaded just on 1-of-3 multisig outputs, see transaction 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You have the whole altcoins that are connected to Bitcoin by using part of the Bitcoin's UTXO set as their database.

That means, as long as you won't solve IBD problem and UTXO set growing problem, you will go nowhere, because if you block Ordinals specifically, people won't learn "this is bad, don't do that", they could read it as "use the old way instead", as long as you won't block all possible ways. And doing that, requires for example creating new nodes, without synchronizing non-consensus data, like it could be done in "assume UTXO" model.

Also note that as long as people use Taproot to upload a lot of data, you can still turn off the witness, and become a pre-Segwit node. But if you block those ways, then people will push data into legacy parts, and then you will need more code to strip it correctly. The block 774628 maybe contains almost 4 MB of data from the perspective of Segwit node, but the legacy part is actually very small, so by turning witness off, you can strip it to maybe just a few kilobytes.

> I want to emphasize that my proposal does not involve implementing a soft fork in any way. On the contrary, what I am asking is simply to consider adding a standardization option. This option would allow the community to freely decide whether it should be activated or not.

1. Without a soft-fork, those data will be pushed by mining pools anyway, as it happened in the block 774628.
2. Adding some settings won't help, as most people use the default configuration. For example, people can configure their nodes to allow free transactions, without recompiling anything. The same with disabling dust amounts. But good luck finding a node in the wild that does anything unusual.
3. This patch produced by Luke Dashjr does not address all cases. You could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used by Ordinals, and easily bypass those restrictions. This will be just a cat and mouse game, where spammers will even use P2PK, if they will be forced to. The Pandora's box is already opened, that fix could be good for February or March, but not now.

On 2023-07-26 11:47:09 user leohaf at orangepill.ovh wrote:
> I understand your point of view. However, inscription represent by far the largest spam attack due to their ability to embed themselves in the witness with a fee reduction.

Unlike other methods, such as using the op_return field which could also be used to spam the chain, the associated fees and the standardization rule limiting op_return to 80 bytes have so far prevented similar abuses.

Although attempting to stop inscription could lead to more serious issues, not taking action against these inscription could be interpreted by spammers as tacit acceptance of their practice. This could encourage more similar spam attacks in the future, as spammers might perceive that the Bitcoin network tolerates this kind of behavior.

I want to emphasize that my proposal does not involve implementing a soft fork in any way. On the contrary, what I am asking is simply to consider adding a standardization option. This option would allow the community to freely decide whether it should be activated or not.

> Le 26 juil. 2023 à 07:30, vjudeu at gazeta.pl a écrit :
>
>> and I would like to understand why this problem has not been addressed more seriously
>
> Because if nobody has any good solution, then status quo is preserved. If tomorrow ECDSA would be broken, the default state of the network would be "just do nothing", and every solution would be backward-compatible with that approach. Burn old coins, and people will call it "Tether", redistribute them, and people will call it "BSV". Leave everything untouched, and the network will split into N parts, and then you pick the strongest chain to decide, what should be done.
>
>> However, when it comes to inscriptions, there are no available options except for a patch produced by Luke Dashjr.
>
> Because the real solution should address some different problem, that was always there, and nobody knows, how to deal with it: the problem of forever-growing initial blockchain download time, and forever-growing UTXO set. Some changes with "assume UTXO" are trying to address just that, but this code is not yet completed.
>
>> So, I wonder why there are no options to reject inscriptions in the mempool of a node.
>
> Because it will lead you to never ending chase. You will block one inscriptions, and different ones will be created. Now, they are present even on chains, where there is no Taproot, or even Segwit. That means, if you try to kill them, then they will be replaced by N regular indistinguishable transactions, and then you will go back to those more serious problems under the hood: IBD time, and UTXO size.
>
>> Inscriptions are primarily used to sell NFTs or Tokens, concepts that the Bitcoin community has consistently rejected.
>
> The community also rejected things like sidechains, and they are still present, just in a more centralized form. There are some unstoppable concepts, for example soft-forks. You cannot stop a soft-fork. What inscription creators did, is just non-enforced soft-fork. They believe their rules are followed to the letter, but this is not the case, as you can create a valid Bitcoin transaction, that will be some invalid Ordinals transaction (because their additional rules are not enforced by miners and nodes).
>
>
>

📅 Original date posted:2023-07-26 🗒️ Summary of this ...

2023-07-27T02:26:35+02:00

In reply to nevent1q…uepv
_________________________

📅 Original date posted:2023-07-26
🗒️ Summary of this message: The problem of inscriptions in Bitcoin has not been addressed seriously because there is no good solution and it would lead to other serious problems like initial blockchain download time and UTXO set growth. Rejecting inscriptions in the mempool would result in a never-ending chase and the creation of different inscriptions. The Bitcoin community has consistently rejected concepts like NFTs and Tokens, but some unstoppable concepts like soft-forks still exist. Inscription creators have created a non-enforced soft-fork with their rules.
📝 Original message:
> and I would like to understand why this problem has not been addressed more seriously

Because if nobody has any good solution, then status quo is preserved. If tomorrow ECDSA would be broken, the default state of the network would be "just do nothing", and every solution would be backward-compatible with that approach. Burn old coins, and people will call it "Tether", redistribute them, and people will call it "BSV". Leave everything untouched, and the network will split into N parts, and then you pick the strongest chain to decide, what should be done.

> However, when it comes to inscriptions, there are no available options except for a patch produced by Luke Dashjr.

Because the real solution should address some different problem, that was always there, and nobody knows, how to deal with it: the problem of forever-growing initial blockchain download time, and forever-growing UTXO set. Some changes with "assume UTXO" are trying to address just that, but this code is not yet completed.

> So, I wonder why there are no options to reject inscriptions in the mempool of a node.

Because it will lead you to never ending chase. You will block one inscriptions, and different ones will be created. Now, they are present even on chains, where there is no Taproot, or even Segwit. That means, if you try to kill them, then they will be replaced by N regular indistinguishable transactions, and then you will go back to those more serious problems under the hood: IBD time, and UTXO size.

> Inscriptions are primarily used to sell NFTs or Tokens, concepts that the Bitcoin community has consistently rejected.

The community also rejected things like sidechains, and they are still present, just in a more centralized form. There are some unstoppable concepts, for example soft-forks. You cannot stop a soft-fork. What inscription creators did, is just non-enforced soft-fork. They believe their rules are followed to the letter, but this is not the case, as you can create a valid Bitcoin transaction, that will be some invalid Ordinals transaction (because their additional rules are not enforced by miners and nodes).

📅 Original date posted:2023-02-17 🗒️ Summary of this ...

2023-06-08T01:19:34+02:00

In reply to nevent1q…2d4c
_________________________

📅 Original date posted:2023-02-17
🗒️ Summary of this message: The debate on how strict the rules should be for discouraging upgradable NOPs in Bitcoin script continues. Some suggest using commitments to handle timestamping and data storage instead of OP_RETURN. The question remains whether to allow spamming the blockchain or create an official alternative.
📝 Original message:> [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831

I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. Because "OP_FALSE OP_IF <anything> OP_ENDIF" is effectively the same as "OP_NOP", and putting NOPs in many places is considered non-standard. The same is true for "OP_TRUE OP_NOTIF <anything> OP_ENDIF", and also there are many variants, where someone could use "OP_FALSE OP_NOT" instead of "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" (instead of putting "OP_TRUE").

There are endless combinations, and even if there will be a rule to evaluate constant values on the input stack, and put OP_NOP, where any non-empty set of opcodes will evaluate into nothing, then still, there are ways to include spam on-chain. So, the question is: how strict should those rules be?

> "I disapprove of what you say, but I will defend to the death your right to say it."

Yes, I disapprove spamming the blockchain. But because people will rather die than stop it, creating some kind of official alternative is needed. I think most of the time it is not needed to store that data on-chain, all that is needed, is just proving they existed, and that they are connected to a certain transaction (so, it is about timestamping, not about storage).

When it comes to the solution, I think a commitment to a signature should handle all cases. In this way, it can be done for any address type that can support OP_CHECKSIG. To validate such commitment, all that is needed, is converting R-value of a signature into the Taproot address, and then checking if a given commitment matches such key.

> I agree with Peter that, given that users have found ways to store arbitrary amounts of data on-chain if they really want, we might as well just make OP_RETURN a free-for-all.

I think we should go in the opposite direction. Using OP_RETURN means that all nodes will store such data. Using witness means that only witness nodes will keep that. So, if it is already possible to have a node that cannot see witness data, and still remain in the network, I think commitments should be stored only by nodes that will enable them explicitly. So, from that point of view, commitment is "a witness of a signature", it is additional information that can be skipped if needed.

On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,

There is a famous quote attributed to Evelyn Beatrice Hall in her biography of Voltaire: "I disapprove of what you say, but I will defend to the death your right to say it." I'm curious to know how many Bitcoin developers share this sentiment.

Recently there was a lot of enthusiasm on social media to run bitcoin core with a [patch][0] that would reject some transactions in mempool. Bitcoin Knots already has an option to reject transactions that reuse addresses. What if such practices become common and some projects that provide easy to use node software start censoring transactions? How would government agencies take advantage of this whole drama?

I understand it is difficult to censor different type of transaction because there will be some nodes relaying them and miners including in blocks. It is still important to discuss this and different ways to test censorship resistance.

- Peter Todd had written a [blog post][1] in which counting number of INVs (step 5,6,7 and 8) helps in testing if your transactions are getting relayed by the connected peers.
- I had tried broadcasting transaction to specific nodes using [libbtc][2]. Based on my understanding it uses GETDATA to confirm your transaction was seen on other nodes after broadcasting.

What would an ideal tool for testing censorship resistance look like?

- Allows user to construct different types of transactions that might be considered "bad" by some people. Example: OFAC address in output, Inscription, OP_RETURN, Address reuse etc.
- Option to broadcast transaction to specific nodes
- Verify if the transaction was relayed successfully or rejected
- Ban such peers using [setban][3] RPC as it would increase the probability of tx getting propagated to miners

There was even some discussion about an [external mempool][4] that could be used for non-standard transactions. It could also help in avoiding censorship in some cases. I welcome your thoughts and feedback on this topic.

[0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
[1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
[2]: https://twitter.com/1440000bytes/status/1574225052240777216
[3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/
[4]: https://twitter.com/jamesob/status/1623827708168863747

/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-08-10 📝 Original message:> I ...

2023-06-08T01:12:38+02:00

In reply to nevent1q…akm3
_________________________

📅 Original date posted:2022-08-10
📝 Original message:> I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery

You can always perform key recovery for legacy ECDSA: "<signature> OP_SWAP OP_CHECKSIG" is always spendable, for any valid <r,s> DER-encoded pair. Here, if "<signature> <messageHash> <pubkey> OP_CHECKDATASIG" works for signature verification BIP, then you only need to provide "<signature>" as an input, the rest could be placed in some output, and your program could easily compute that. Or you can use "OP_DUP OP_HASH160 <address> OP_EQUALVERIFY <messageHash> OP_SWAP OP_CHECKDATASIG" as your output script, then the signer has to provide a valid signature, and a valid public key explicitly, but if you only have some signature, then you can always recover that key by yourself.

Because if OP_CHECKDATASIG is not handled, then still, signing by scripts can handle that, but the Script would be unnecessarily complex. And because there is no need to introduce OP_CHECKDATASIG on-chain, it can be safely done inside this BIP.

> I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

Because if you want to support any script, and you want to add a new opcode, you have to make it somehow compatible with existing schemes. You have to assign some byte for OP_CHECKDATASIG or for any new opcodes you want to add. And you don't want to assign just the next free opcode, because you will get OP_CHECKSIGADD or other opcodes from TapScript, so your script decoder will no longer handle two script versions at once. Unless you want to make it also compatible with altcoins like BCH, but I guess it is not needed.

On 2022-08-10 15:53:31 user Ali Sherief <ali at notatether.com> wrote:
> > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message".

I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.

But the implementations would have to decode the Base58 address into "0x00" plus the address hash. As the only supported invoice type for the Legacy signing methods, this should be straight forward to do.

> And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction".

I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

- Ali

On Wed, 10 Aug 2022 04:59:46 +0200, vjudeu at gazeta.pl wrote:
> > I'm not sure what is to be gained from adding an opcode
>
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message". And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction". It is also possible to assign some unused opcode, but then it will be more complex, because in Script, those opcodes make transaction invalid, but inside TapScript, those opcodes are defined as OP_SUCCESS, and make things automatically valid.
>
>
> On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Although there is a Github issue/PR at https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of BIP322, I decided to throw it in the mailing list again to see if anyone else has suggestions for dealing with them.
>
> So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the some TODO items, and I will copy-paste the ones in the Specification section (for full proofs) here:
>
> > TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> > TODO: Some invalid opcode to allow only in various proof types?
> > TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility
>
> So to start with, I believe it will be very helpful to limit what opcodes scriptPubKeys to be elligible to sign from them. The specification already does so to a point, but in order for these to be recognizable, it's my opinion that one of the NOPs should be placed at the beginning of the script to activate proof parsing mode.
>
> Of course, an opcode is not necessary at all, if the program is able to infer from context where the proof is coming from. After all, since they cannot be broadcasted, they can't be mined in blocks, so will never be encountered in a full node's usual verifier. I'm not sure what is to be gained from adding an opcode - the only source for real transactions is from P2P-obtained blocks, so when a human inputs a signature to be verified, it can check that a real transaction is not being inserted by looking for the invalid input.
>
> For Silent Transactions, I have already given my suggestion in the PR, that some subsection can be made saying that it can operate with them by using its scriptPubKey (and other stuff that may be necessary - I am not excatly sure what goes inside the Witness stack of message_signature).
>
> In the case of the last TODO, related to delegation to another scriptPubKey, I am not quite sure at the moment what to do about it - perhaps you guys can place a MAST (two Merkle branches, to be specific) - the first branch has the original signer's scriptPubKey, the second branch contains the delegated signer's scriptPubKey.
>
> - Ali

📅 Original date posted:2022-08-09 📝 Original message:> ...

2023-06-08T01:12:37+02:00

In reply to nevent1q…584m
_________________________

📅 Original date posted:2022-08-09
📝 Original message:> I'm not sure what is to be gained from adding an opcode

Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message". And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction". It is also possible to assign some unused opcode, but then it will be more complex, because in Script, those opcodes make transaction invalid, but inside TapScript, those opcodes are defined as OP_SUCCESS, and make things automatically valid.

On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Although there is a Github issue/PR at https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of BIP322, I decided to throw it in the mailing list again to see if anyone else has suggestions for dealing with them.

So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the some TODO items, and I will copy-paste the ones in the Specification section (for full proofs) here:

> TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> TODO: Some invalid opcode to allow only in various proof types?
> TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility

So to start with, I believe it will be very helpful to limit what opcodes scriptPubKeys to be elligible to sign from them. The specification already does so to a point, but in order for these to be recognizable, it's my opinion that one of the NOPs should be placed at the beginning of the script to activate proof parsing mode.

Of course, an opcode is not necessary at all, if the program is able to infer from context where the proof is coming from. After all, since they cannot be broadcasted, they can't be mined in blocks, so will never be encountered in a full node's usual verifier. I'm not sure what is to be gained from adding an opcode - the only source for real transactions is from P2P-obtained blocks, so when a human inputs a signature to be verified, it can check that a real transaction is not being inserted by looking for the invalid input.

For Silent Transactions, I have already given my suggestion in the PR, that some subsection can be made saying that it can operate with them by using its scriptPubKey (and other stuff that may be necessary - I am not excatly sure what goes inside the Witness stack of message_signature).

In the case of the last TODO, related to delegation to another scriptPubKey, I am not quite sure at the moment what to do about it - perhaps you guys can place a MAST (two Merkle branches, to be specific) - the first branch has the original signer's scriptPubKey, the second branch contains the delegated signer's scriptPubKey.

- Ali

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-08-03 📝 Original message:It is ...

2023-06-08T01:12:22+02:00

In reply to nevent1q…m6xa
_________________________

📅 Original date posted:2022-08-03
📝 Original message:It is possible, because you can find nodes that accept low-fee transactions. And on some statistics, for example https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero to one satoshi per virtual byte transactions could take more space than other transactions. You can be convinced that those charts are not fake by running a full node and reaching some nodes with different fee settings. If miners don't want to accept them, well, it is their choice to leave that money on the table. As long as the basic block reward is sufficient, they don't have to accept such low fee transactions, because they can wait instead, to receive them in some batched form.

Also, some miners could accept only 10 sats/vB or higher, because why not. As long as your transaction will reach enough nodes to be confirmed, you can safely pick lower fees. For now, de-facto standard is one satoshi per virtual byte, but:

1) it is only declared, so you can rely only on declarations, not on hard consensus rules
2) there is no way to make sure if some transaction was truly rejected by some miner, or maybe it was saved somewhere
3) you can never be sure if some node is a miner and can enforce those different fee rules or not

So, you can really judge only by how nodes behave, you cannot make sure in any way if anyone is running some additional rules. And fees are not a part of the consensus, so they can be freely adjusted by each node, and there is no way to make sure, what rules are really executed, you can only assume that, based on what transactions are included in blocks.

On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
So, can we conclude by something, whether or not it would be possible and feasible in the future?

On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote:
> > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> > like a hashcash-based alternative broadcast scheme.
> Hi Peter,
> I've been mulling the idea of attaching work to low fee txns, both as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfortunately, both suffer from ASICs:
> For spam proof case, the adversary can easily buy a used/obsolete device to produce lots of spam txns very cheaply, unless you put the bar very high, making it almost impossible for average users to even try.
> The compensation scenario is pretty off-topic, still, interesting enough for 1 min read:
> Wallets commit to the latest blockchain state in the transaction AND attach work.
> It is considered contribution to the security (illegitimate chains can't include the txn), hence isrewarded by fee discount/exemption depending on the offset of the state they've committed to (the closer, the better) and the amount of work attached.
> For this to work, block difficulty is calculated inclusive with the work embedded in the txns, it contains. Sophisticated and consequential, yet not infeasible per se.
>
> Unfortunately, this scheme is hard to balance with ASICs in the scene too, for instance, you can't subsidize wallets for their work like with a leverge, because miners can easily do it locally, seizing the subsidies for themselves, long story, not relevant just ignore it.

We're not talking about a consensus system here. Just a way to rate-limit
access to a broadcast network used by a small minority of nodes. It's
completely ok to simply change the PoW algorithm in the _highly_ unlikely event
someone bothers to build an ASIC for it. Since this isn't a consensu system,
it's totally ok if multiple versions of the scheme run in parallel.

📅 Original date posted:2022-07-14 📝 Original message:> ...

2023-06-08T01:11:48+02:00

In reply to nevent1q…yhsz
_________________________

📅 Original date posted:2022-07-14
📝 Original message:> This specific approach would obviously not work as most of those outputs would be dust and the miner would need to waste an absurd amount of block space just to grab them, but maybe there's a smarter way to do it.

There is a smarter way. Just send 0.01 BTC per block to the timelocked outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage will grow over time, as basic block reward will shrink, and we will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means you can lock 2,100 BTC in an endless circulation loop, and avoid this "tail supply attack".

So, fortunately, even if "tail supply attackers" will win, we will still have a chance to counter-attack by burning those coins, or (even better) by locking them in an endless circulation loop, just to satisfy their malicious soft-fork, whatever amount it will require. Because even if it will be mandatory to timelock 0.01 BTC to the current block number plus 210,000, then it is still perfectly valid to move that amount endlessly, without taking it, just to resist this "tail supply attack".

On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ?

This would be a hard fork afaict as it would go against the rules of the coinbase transaction following the usual halving schedule.

However, if instead we added a rule that fees have to be sent to an anyone can spend output with a timelock we might be able to achieve a similar thing.

Highly inefficient example:

- Split blocks into 144 (about a day)
- A mined block takes all the fees and distributes them equally into 144 new outputs (anyone can spend) time locked to each of the 144 blocks of the next day.
- Next day, for each block, we'd have available an amount equivalent to the previous day total fees / 144. So we deliver previous day's fees smoothed out.

Notes:
144 is arbitrary in the example.
This specific approach would obviously not work as most of those outputs would be dust and the miner would need to waste an absurd amount of block space just to grab them, but maybe there's a smarter way to do it.

Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> escreveu no dia quarta, 13/07/2022 à(s) 13:19:
What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ?

Benefits :
- Miners would still be incentivized to collect higher fees transaction with the indirect perspective to generate more reward in future.
- Revenues are equally distributed over time to all participants and we solve the overnight discrepancy.
- Increased velocity of money will reduce the immediate supply of bitcoin cooling down the economy.
- Reduction of velocity will have an impact on miners only if it persevere in the long term but short term they will still perceive the buffered reward.

I don't have ideas yet on how to elegantly implement this.

On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <bitcoin-dev at lists.linuxfoundation.org> wrote:
> The emission curve lasts over 100 years because Bitcoin success state requires it to be entrenched globally.

It effectively doesn't. The last 100 years from 2040-2140 only emits a
pittance of about 0.4 of all bitcoin.

What matters for proper distribution is the shape of the emission
curve. If you emit 99% in the first year and 1% in the next 100 years,
your emission "lasts" over 100 years, and you achieve a super low
supply inflation rate immediately after 1 year, but it's obviously a
terrible form of distribution.

This is easy to quantify as the expected time of emission which would
be 0.99 * 0.5yr + 0.01* 51yr = 2 years.
Bitcoin is not much better in that the expected time of emission of an
bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.

Monero appears much better since its tail emission yields an infinite
expected time of emission, but if we avoid infinities by looking at
just the soft total emission [1], which is all that is emitted before
a 1% yearly inflation, then Monero is seen to actually be a lot worse
than Bitcoin, due to emitting over 40% in its first year and halving
the reward much faster. Ethereum is much worse still with its huge
premine and PoS coins like Algorand are scraping the bottom with their
expected emission time of 0.

There's only one coin whose expected (soft) emission time is larger
than bitcoin's, and it's about an order of magnitude larger, at 50
years.

[1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
_______________________________________________
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

📅 Original date posted:2022-07-11 📝 Original message:This ...

2023-06-08T01:11:40+02:00

In reply to nevent1q…j4p8
_________________________

📅 Original date posted:2022-07-11
📝 Original message:This problem can be solved by mining decentralization.

> What's likely to happen is that at first there will simply be no or very few blocks mined overnight.

Why? When it comes to energy usage, there are also cycles, because energy usage during the day is definitely higher than at night. You can clearly see that there are different prices for energy usage, and it depends if you use that energy overnight or not (usually, energy at night is cheaper, in the same way as other resources like Internet bandwidth limits, which are lower at night).

If less energy is used at night, then that energy is cheaper, and that means mining at night is more profitable.

> There are likely to be some, as miners at first turn off their mining rigs completely overnight then adopt the more sophisticated strategy of waiting until there are enough fees in the mempool to warrant attempting to make a block and only then doing it.

Again, that's the problem that should be solved by decentralized mining. Each reward of each miner should depend on all fees collected by that miner. It is easier to think about it if you assume zero basic block reward, where the whole coinbase transaction is based only on transaction fees. So, all that is needed, is to make it possible to get some transaction fees, related to mined transactions. So, it is far better to think about some kind of commit-and-reveal scheme, where each miner will independently mine a share of the block, and commit the block header on-chain. Then, it will be later possible to prove that such share was created at a given point in time, and to claim some reward (even off-chain), based on that proof.

> Eventually the miners with lower costs of operation will figure out that they can collectively reorg the last hour (or some time period) of the day overnight and this will be profitable.

That would mean on-chain transaction fees are very low. And that would mean off-chain transaction fees are higher (because if that's not the case, then it would mean that people stopped making any transactions at all, on all monetary systems globally, including all altcoins, and all fiat currencies). So, that case is possible in a situation, where Lightning Network will handle the most of the traffic, and where there will be almost no need to touch on-chain coins, because all of them will fly inside other networks like LN, sidechains, or Merge-Mined altcoins.

> In short, relying completely on transaction fees for security is likely to be a disaster.

Note that if you want to rely on something else than fees, then you have three options: big blocks, tail supply, or Merged Mining. Big blocks were discussed heavily in the past, tail supply is discussed now, and Merged Mining is still not touched correctly (to get it right, it is needed to track the heaviest chain of Proof of Work headers, and to distribute a fractions of coins, based on that, not like NameCoin, where you have a separate difficulty, so you can 51% attack NameCoin, even if you don't have 51% on Bitcoin). So, why not Merged Mining? Or what else could it be? And if it will be tail supply, then why hard-fork is needed at all? Make it explicitly, take single satoshis from all UTXOs in existence, and make it crystal clear, what this proposal is about: it is about taking a tiny fractions of satoshis or even smaller amounts from all UTXOs to form the future block rewards, that's what it is truly about, and users should be aware of that.

> One would be to drag most of east asia eastward to a later time zone thus smoothing out the day/night cycle but that's probably unrealistic.

What is unrealistic? Trustless mining on someone's behalf and being rewarded for doing that in P2P way is unrealistic? It is perfectly possible to deploy any "I will pay you for increasing block reward for block 1000000" scheme. We have OP_CHECKLOCKTIMEVERIFY for that, anyone can do that, even non-mining users can send their own coins to the future block numbers to increase future rewards with their own coins.

> Another would be to hard fork in fixed rewards in perpetuity, which is slightly less unrealistic but still extremely problematic.

No hard-fork is needed. Moving coins to OP_CHECKLOCKTIMEVERIFY outputs is a no-fork. Enforcing that on consensus level to make block rewards more smooth is a soft-fork. Creating a Merge-Mined sidechain for that is a no-fork (because new coins are produced out of thin air, so Proof of Work alone, and tracking the main chain is enough, no new rules are needed on the main chain).

> Much more actionable are measures which smooth out fees over time.

What about RSK and their way of making fees more smooth?

On 2022-07-11 20:19:51 user Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
If transaction fees came in at an even rate over time all at the exact same level then they work fine for security, acting similarly to fixed block rewards. Unfortunately that isn't how it works in the real world. There's a very well established day/night cycle with fees going to zero overnight and even longer gaps on weekends and holidays. If in the future Bitcoin is entirely dependent on fees for security (scheduled very strongly) and this pattern keeps up (overwhelmingly likely) then this is going to become a serious problem.

What's likely to happen is that at first there will simply be no or very few blocks mined overnight. There are likely to be some, as miners at first turn off their mining rigs completely overnight then adopt the more sophisticated strategy of waiting until there are enough fees in the mempool to warrant attempting to make a block and only then doing it. Unfortunately the gaming doesn't end there. Eventually the miners with lower costs of operation will figure out that they can collectively reorg the last hour (or some time period) of the day overnight and this will be profitable. That's likely to cause the miners with more expensive operations to stop attempting mining the last hour of the day preemptively.

What happens after that I'm not sure. There are a small enough number of miners with a quirky enough distribution of costs of operation and profitability that the dynamic is heavily dependent on those specifics, but the beginnings of a slippery slope to a mining cabal which reorgs everyone else out of existence and eventually 51% attacks the whole thing have begun. It even gets worse than that because once there's a cabal aggressively reorging anyone else out when they make a block other miners will shut down and rapidly lose the ability to quickly spin up again, so the threshold needed for that 51% attack will keep going down.

In short, relying completely on transaction fees for security is likely to be a disaster. What we can say from existing experience is that having transaction fees be about 10% of rewards on average works well. It's enough to incentivize collecting fees but not so much that it makes incentives get all weird. 90% transaction fees is probably very bad. 50% works but runs the risk of spikes getting too high.

There are a few possible approaches to fixes. One would be to drag most of east asia eastward to a later time zone thus smoothing out the day/night cycle but that's probably unrealistic. Another would be to hard fork in fixed rewards in perpetuity, which is slightly less unrealistic but still extremely problematic.

Much more actionable are measures which smooth out fees over time. Having wallets opportunistically collect their dust during times of low transaction fees would help and would save users on fees. Also making UX which clarifies when things are likely to take a day or week but that it's reliable would be a reasonable thing to do, but users unfortunately are very averse to transactions taking a while.

📅 Original date posted:2022-07-10 📝 Original message:> ...

2023-06-08T01:11:31+02:00

In reply to nevent1q…x9sj
_________________________

📅 Original date posted:2022-07-10
📝 Original message:> Adding tail emission to Bitcoin would be a hard fork: a incompatible rule change that existing Bitcoin nodes would reject as invalid.

It won't, because we have zero satoshis. That means, it is possible to create any backward-compatible way of storing amounts. And if we will ever implement things like hiding amounts, then using zero would be a good way to maintain this backward compatibility.

> Ultimately, as long as a substantial fraction of the Bitcoin community continue to run full nodes, the only way tail emission could ever be added to Bitcoin is by convincing that same community that it is a good idea.

Not really, because people that run full nodes, just accepted Segwit and Taproot. They had no choice. And in case of zero satoshis, it could be the same: you would see zero if you look at raw bytes, but you will see non-zero values, if you use some upgraded client, that will support amount hiding, or other features.

Segwit: old nodes see no new signatures, new nodes see all signatures
Zero satoshis: old nodes see new zero amounts, new nodes see all amounts

It is that simple.

On 2022-07-09 14:47:14 user Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> New blog post:

https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary

tl;dr: Due to lost coins, a tail emission/fixed reward actually results in a
stable money supply. Not an (monetarily) inflationary supply.

...and for the purposes of reply/discussion, attached is the article itself in
markdown format:

---
layout: post
title: "Surprisingly, Tail Emission Is Not Inflationary"
date: 2022-07-09
tags:
- bitcoin
- monero
---

At present, all notable proof-of-work currencies reward miners with both a block
reward, and transaction fees. With most currencies (including Bitcoin) phasing
out block rewards over time. However in no currency have transaction fees
consistently been more than 5% to 10% of the total mining
reward[^fee-in-reward], with the exception of Ethereum, from June 2020 to Aug 2021.
To date no proof-of-work currency has ever operated solely on transaction
fees[^pow-tweet], and academic analysis has found that in this condition block
generation is unstable.[^instability-without-block-reward] To paraphrase Andrew
Poelstra, it's a scary phase change that no other coin has gone through.[^apoelstra-quote]

[^pow-tweet]: [I asked on Twitter](https://twitter.com/peterktodd/status/1543231264597090304) and no-one replied with counter-examples.

[^fee-in-reward]: [Average Fee Percentage in Total Block Reward](https://bitinfocharts.com/comparison/fee_to_reward-btc-eth-bch-ltc-doge-xmr-bsv-dash-zec.html#alltime)

[^instability-without-block-reward]: [On the Instability of Bitcoin Without the Block Reward](https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf)

[^apoelstra-quote]: [From a panel at TABConf 2021](https://twitter.com/peterktodd/status/1457066946898317316)

Monero has chosen to implement what they call [tail
emission](https://www.getmonero.org/resources/moneropedia/tail-emission.html):
a fixed reward per block that continues indefinitely. Dogecoin also has a fixed
reward, which they widely - and incorrectly - refer to as an "abundant" supply[^dogecoin-abundant].

[^dogecoin-abundant]: Googling "dogecoin abundant" returns dozens of hits.

This article will show that a fixed block reward does **not** lead to an
abundant supply. In fact, due to the inevitability of lost coins, a fixed
reward converges to a **stable** monetary supply that is neither inflationary
nor deflationary, with the total supply proportional to rate of tail emission
and probability of coin loss.

Credit where credit is due: after writing the bulk of this article I found out
that Monero developer [smooth_xmr](https://www.reddit.com/user/smooth_xmr/)
also observed that tail emission results in a stable coin supply
[a few years ago](https://www.reddit.com/r/Monero/comments/4z0azk/maam_28_monero_ask_anything_monday/d6sixyi/).
There's probably others too: it's a pretty obvious result.

<div markdown="1" class="post-toc">
# Contents
{:.no_toc}
0. TOC
{:toc}
</div>

## Modeling the Fixed-Reward Monetary Supply

Since the number of blocks is large, we can model the monetary supply as a
continuous function $$N(t)$$, where $$t$$ is a given moment in time. If the
block reward is fixed we can model the reward as a slope $$k$$ added to an
initial supply $$N_0$$:

$$
N(t) = N_0 + kt
$$

Of course, this isn't realistic as coins are constantly being lost due to
deaths, forgotten passphrases, boating accidents, etc. These losses are
independent: I'm not any more or less likely to forget my passphrase because
you recently lost your coins in a boating accident — an accident I probably
don't even know happened. Since the number of individual coins (and their
owners) is large — as with the number of blocks — we can model this loss as
though it happens continuously.

Since coins can only be lost once, the *rate* of coin loss at time $$t$$ is
proportional to the total supply *at that moment* in time. So let's look at the
*first derivative* of our fixed-reward coin supply:

$$
\frac{dN(t)}{dt} = k
$$

...and subtract from it the lost coins, using $$\lambda$$ as our [coin loss
constant](https://en.wikipedia.org/wiki/Exponential_decay):

$$
\frac{dN(t)}{dt} = k - \lambda N(t)
$$

That's a first-order differential equation, which can be easily solved with
separation of variables to get:

$$
N(t) = \frac{k}{\lambda} - Ce^{-\lambda t}
$$

To remove the integration constant $$C$$, let's look at $$t = 0$$, where the
coin supply is $$N_0$$:

$$
\begin{align}
N_0 &= \frac{k}{\lambda} - Ce^{-\lambda 0} = \frac{k}{\lambda} - C \\
C &= \frac{k}{\lambda} - N_0
\end{align}
$$

Thus:

$$
\begin{align}
N(t) &= \frac{k}{\lambda} - \left(\frac{k}{\lambda} - N_0 \right)e^{-\lambda t} \\
&= \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t}
\end{align}
$$

## Long Term Coin Supply

It's easy to see that in the long run, the second half of the coin supply
equation goes to zero because $$\lim_{t \to \infty} e^{-\lambda t} = 0$$:

$$
\begin{align}
\lim_{t \to \infty} N(t) &= \lim_{t \to \infty} \left[ \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t} \right ] = \frac{k}{\lambda} \\
N(\infty) &= \frac{k}{\lambda}
\end{align}
$$

An intuitive explanation for this result is that in the long run, the initial
supply $$N_0$$ doesn't matter, because approximately all of those coins will
eventually be lost. Thus in the long run, the coin supply will converge towards
$$\frac{k}{\lambda}$$, the point where coins are created just as fast as they
are lost.

## Short Term Dynamics and Economic Considerations

Of course, the intuitive explanation for why supply converges to
$$\frac{k}{\lambda}$$, also tells us that supply must converge fairly slowly:
if 1% of something is lost per year, after 100 years 37% of the initial supply
remains. It's not clear what the rate of lost coins actually is in a mature,
valuable, coin. But 1%/year is likely to be a good guess — quite possibly less.

In the case of Monero, they've introduced tail emission at a point where it
represents a 0.9% apparent monetary inflation rate[^p2pool-tail]. Since the number of
previously lost coins, and the current rate of coin loss, is
unknown[^unknowable] it's not possible to know exactly what the true monetary
inflation rate is right now. But regardless, the rate will only converge
towards zero going forward.

[^unknowable]: Being a privacy coin with [shielded amounts](https://localmonero.co/blocks/richlist), it's not even possible to get an estimate of the total amount of XMR in active circulation.

[^p2pool-tail]: P2Pool operates [a page with real-time date figures](https://p2pool.io/tail.html).

If an existing coin decides to implement tail emission as a means to fund
security, choosing an appropriate emission rate is simple: decide on the
maximum amount of inflation you are willing to have in the worst case, and set
the tail emission accordingly. In reality monetary inflation will be even lower
on day zero due to lost coins, and in the long run, it will converge towards
zero.

The fact is, economic volatility dwarfs the effect of small amounts of
inflation. Even a 0.5% inflation rate over 50 years only leads to a 22% drop.
Meanwhile at the time of writing, Bitcoin has dropped 36% in the past year, and
gained 993% over the past 5 years. While this discussion is a nice excuse to
use some mildly interesting math, in the end it's totally pedantic.

## Could Bitcoin Add Tail Emission?

...and why could Monero?

Adding tail emission to Bitcoin would be a hard fork: a incompatible rule
change that existing Bitcoin nodes would reject as invalid. While Monero was
able to get sufficiently broad consensus in the community to implement tail
emission, it's unclear at best if it would ever be possible to achieve that for
the much larger[^btc-vs-xmr-market-cap] Bitcoin. Additionally, Monero has a
culture of frequent hard forks that simply does not exist in Bitcoin.

[^btc-vs-xmr-market-cap]: [As of writing](https://web.archive.org/web/20220708143920/https://www.coingecko.com/), the apparent market cap of Bitcoin is $409 billion, almost 200x larger than Monero's $2.3 billion.

Ultimately, as long as a substantial fraction of the Bitcoin community continue
to run full nodes, the only way tail emission could ever be added to Bitcoin is
by convincing that same community that it is a good idea.

## Footnotes
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-07-10 📝 Original message:> ...

2023-06-08T01:11:28+02:00

In reply to nevent1q…wdk3
_________________________

📅 Original date posted:2022-07-10
📝 Original message:> We want mining to be is a boring, predictable, business that anyone can do, with as little reward as possible to larger scale miners.

To reach that, miners should earn their block rewards inside Lightning Network. Then, if you want to send some transaction, and you have one satoshi fee, you can produce a Bitcoin block on your CPU, and get a discount on your fee for doing that. Imagine mining a block with difficulty one, and getting some millisatoshis, or even microsatoshis as a reward. Then, to bootstrap that system, it could at first accept any blocks, so existing miners could redirect their shares to such network, then a pool will be able to claim those rewards. And then, when miners will see that the system works as intended, they could switch to solo mining, to get their rewards directly to their addresses.

On 2022-07-10 19:27:28 user Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote:
> Good morning e, and list,
>
> > Yet you posted several links which made that specific correlation, to which I was responding.
> >
> > Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
> >
> > The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
>
> To clarify about censorship resistance and perpetual issuance ("tail emission"):
>
> * Suppose I have two blockchains, one with a constant block subsidy, and one which *had* a block subsidy but the block subsidy has become negligible or zero.
> * Now consider a censoring miner.
> * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
> * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
> * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
> * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
> * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.

Now let's look at an actual, real-world, attempt to censor Bitcoin via mining:

https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin

The Chain Anchor model was to simply straight up bribe and coerce miners into
only accepting compliant transactions. That's only effective when a large % of
miners actually do that - if a small % do the effect on confirmation time is
miniscule. Obviously, censoring transactions is a significant threat to the
value of Bitcoin - and thus all your Bitcoin-only hashing equipment.

So how do you make a Chain Anchor attack cheaper? By reducing total mining
reward, and making it tied to transaction volume rather than the value of
Bitcoin as a whole.

> Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.

The block subsidy directly ties miner revenue to the total value of Bitcoin:
that's exactly how you want to incentivise a service that keeps Bitcoin secure.

> But the block subsidy is still issued whether or not coins being moved are censored or not censored.
> Thus, there is no incentive, considering *only* the block subsidy, to not censor coin movements.
> Only per-transaction fees have an incentive to not censor coin movements.

The strongest incentive not to censor is because it'll keep Bitcoin valuable.
Not some piddling transaction fees.

> Thus, we should instead prepare for a future where the block subsidy *must* be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.

Absolutely not.

The historical reality of transaction fees is they've had huge swings, about
10x more volatile than total miner revenue. In the past three years they've
ranged from $8.4 million USD/30-day-average to as little as $140k/30-day-avg,
with the current amount being $370k/30-day-avg. That's a 60x difference.

Meanwhile miner revenue has ranged from $60 million/30-day-avg to $9
million/30-day-avg, a 7x difference.

https://www.blockchain.com/charts/fees-usd-per-transaction

We want mining to be is a boring, predictable, business that anyone can do,
with as little reward as possible to larger scale miners. That's what you need
for maximal decentralization. Making mining a sophisticated business reduces
the pool of entities that can profitably compete in it, and increases their
visibility to government regulation.

Additionally, we want mining to be predictable to avoid having large gluts of
unprofitable mining equipment laying around: mining equipment that could be
used to attack Bitcoin. Fee revenue is obviously doing a much worse job of
achieving that goal than subsidy revenue.

If transaction-fee-only mining was such a good idea, why hasn't any other coin
done it?

--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-07-08 📝 Original ...

2023-06-08T01:11:16+02:00

In reply to nevent1q…7n4e
_________________________

📅 Original date posted:2022-07-08
📝 Original message:Isn't it enough to just generate a seed in the same way as today, then sort the words alphabetically, and then use that as a seed? I know, the last word is a checksum, but there are only 2048 words, so it is not a big deal to get any checksum we want. If that is insecure, because of lower possible combinations, then it is always possible to increase the number of words to compensate that.

On 2022-07-08 04:27:21 user Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

Without a performance requirement there is no reason you can’t store the BIP39 words in any order you want. So it’s certainly possible, just brute force the recovery. If you have less than a second vs. a few days then it’s a different question.

e

On Jul 7, 2022, at 18:48, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Part of the rules of my challenge is that the 'new' words need to be in the same pool as the 'old' words, so any ordering is okay. Without that requirement it's mathematically very straightforward.

On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak <stick at satoshilabs.com> wrote:
There is. Just encode the index of permutation used to scramble the otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3 words should be enough.

Repetitions make this more difficult, though.

On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
I made a python implementation for a different mnemonic encoding. The encoding requires user to remember words but not the order of those words.
The code is open (MIT license) at https://github.com/sancoder/noomnem

Thanks Anton. There's an interesting mathematical question of whether it's possible to make a code like this which always uses the BIP-39 words for the same key as part of its encoding, basically adding a few words as error correction in case the order is lost or confused. If the BIP-39 contains a duplicate you can add an extra word.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-07-08 📝 Original message:> ...

2023-06-08T01:11:05+02:00

In reply to nevent1q…57xa
_________________________

📅 Original date posted:2022-07-08
📝 Original message:> Simply fork off an inflation coin and test your theory. I mean, that’s the only way it can happen anyway.

That would be an altcoin. But it can be done in a simpler way: we have 21 million coins. It doesn't matter if it is 21 million, if it is 100 million, or if it is in some normalized range from 0 to 1, where you can always know, what fraction of the total supply you have. So, if the total supply is constant, then it is all about proportions. And that means, you can create some system on top of Bitcoin, that would move coins from users to miners. It is all about that: if all coins are mined, then they can move only if users will move them. So if you want to change that, it is all about encouraging them to put their coins in some evil Lightning channel, when they will lose their coins over time. That's how inflation works.

So, imagine some evil channel, where you can put for example 0.01 BTC, and have a time-based fee, so you will pay 1000 satoshis per day. Guess what: 1000 days, and your coins are gone! That means, if anyone want to test inflation, it is possible right here and right now. Good luck to convince people to use your inflationary system in a non-obfuscated way, because that's how it truly looks like: if you double coin supply, you can reach the same by halving all amounts.

On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey to create a fee of 5000x that of 5000tx. This is of course why I stated my assumption. Yet this simple example should make clear that at some point a reduction in confirmation rate reduces reward. Otherwise a rate of zero implies infinite reward.

You cannot support the blanket statement (and absent any assumption) that lower confirmation rates produce “much higher fees” or “better security”.

What you call a “bidding war” is merely market pricing, as it occurs with any good. People *always* will pay as much as they will pay. This is tautological. What you cannot say is how much more someone will pay at any given time for any given good, until they have done it. And I’m pretty sure Bitcoin hasn’t done it.

You cannot prove what the price of anything will be, nor can any “papers”. The absurdity of S2F should have clearly demonstrated that by now. Value is an individual human preference.

If everyone pays 1 sat, then either miners are profitable at 1 sat, or these people are not getting confirmed (economic rationality always assumed).

The assumption of 1 sat txs filling blocks is based on a disproportionately high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood of $200 per tx in fees today, and as $680. As that falls, fees will continue to keep miners at the same profit level. If demand does not rise to compensate (as it always has) then hash rate will fall.

Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin is a market money. Like gold it is produced at market cost. Yet it will prevent Bitcoin from achieving any meaningful level of censorship resistance. This of course should make people look closely at such arguments.

Of course, once you have a censor, block space gets really small for those who want to resist the censor. Then of course only fees can offset the censorship. Without fee-based tx confirmation (for anonymity), and/or with a disproportionate subsidy going to the censor, a censor can operate profitably and indefinitely (under the assumption of constant demand). There is no reason to assume demand for censored txs wouldn’t even increase, given the white market blessing which so many seem to want.

But there is of course no real issue here. Simply fork off an inflation coin and test your theory. I mean, that’s the only way it can happen anyway.

e

On Jul 7, 2022, at 14:11, Erik Aronesty <erik at q32.com> wrote:

The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher.

**the ones moving more sats will win the top spots and will pay as much as is reasonable**

Smaller blocks produce better security for the network both in validation, and in fees.

Without a bidding war for space, everyone can post 1 SAT/byte

With a bidding war for space, larger transactions will pay much higher rates. There have been a number of papers written on this but you can concoct a trivial example to prove it.

On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric at voskuil.org> wrote:

It’s not clear how reducing block size changes the fee aspect of the block reward. Assuming half the space implies twice the fee per avg tx the reward remains constant.

Any additional cost of processing more or less bytes would not matter, because of course this is just a cost that gets nulled out by difficulty — average profit (net income) is the cost of capital.

The reason for smaller vs. larger blocks is to ensure that individuals can afford to validate. That’s a threshold criteria.

Given unlimited size blocks, miners would still have to fix a point in time to mine, gathering as much fee as they can optimize in some time period presumably less than 10 minutes. The produces a limit to transaction volume, yet neither reward nor profit would be affected given the above assumptions. The difference would be in a tradeoff of per tx fee against the threshold.

Given Moore’s Law, that threshold is constantly decreasing, which will make it cheaper over time for more individuals to validate. But the difference for miners for smaller blocks is largely inconsequential relative to their other costs.

Increasing demand is the only thing that increases double spend security (and censorship resistance assuming fee-based reward). With rising demand there is rising overall hash rate, despite block reward and profit remaining constant. This makes the cost of attempting to orphan a block higher, therefore lowering the depth/time requirement implied to secure a given tx amount.

These are the two factors, demand and time. Less demand implies more time to secure a given amount against double spend, and also implies a lower cost to subsidize a censorship regime. But the latter requires a differential in reward between the censor and non-censoring miners. While this could be paid in side fees, that is a significant anonymity issue.

e

On Jul 7, 2022, at 10:37, Erik Aronesty <erik at q32.com> wrote:

> > We should not imbue real technology with magical qualities.

> Precisely. It is economic forces (people), not technology, that provide security.

Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives.

In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators.

Changes to inflation are, very likely, off the table.

On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote:
>> Billy,
>>
>> Proof of work and the difficulty adjustment function solve literally
>> everything you are talking about already.
>
> Unfortunately you are quite wrong: the difficulty adjustment function merely
> adjusts for changes in the amount of observable, non-51%-attacking, hashing
> power. In the event of a chain split, the difficulty adjustment function does
> nothing; against a 51% attacker, the difficulty adjustment does nothing;
> against a censor, the difficulty adjustment does nothing.

Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again.

Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition.

With falling difficulty this incentive is compounded.

Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario.

Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards).

Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making.

It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance.

> We should not imbue real technology with magical qualities.

Precisely. It is economic forces (people), not technology, that provide security.

e

>> Bitcoin does not need active economic governanance by devs or meddlers.
>
> Yes, active governance would definitely be an exploitable mechanism. On the
> other hand, the status quo of the block reward eventually going away entirely
> is obviously a risky state change too.
>
>>>> There is also zero agreement on how much security would constitute such
>>> an optimum.
>>>
>>> This is really step 1. We need to generate consensus on this long before
>>> the block subsidy becomes too small. Probably in the next 10-15 years. I
>>> wrote a paper
>
> The fact of the matter is that the present amount of security is about 1.7% of
> the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also
> already an amount low enough that it's much smaller than economic volatility.
>
> Obviously 0% is too small.
>
> There's zero reason to stress about finding an "optimal" amount. An amount low
> enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5%
> would probably be fine; 0.1% would probably be fine.
>
> Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on
> savings; 0.1% works out to be 7.2%
>
> These are all amounts that are likely to be dwarfed by economic shifts.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> 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

📅 Original date posted:2022-03-19 📝 Original message:> ...

2023-06-08T01:06:12+02:00

In reply to nevent1q…hkkc
_________________________

📅 Original date posted:2022-03-19
📝 Original message:> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.

It should not be expressed in percents, but in amounts. It would be easier and more compatible with votes where there is 100% oppose or 100% support (and also easier to handle if some LN user would move one satoshi, because rounding percents would be tricky). Anyway, you need to convert percents to amounts, so better use amounts from the very beginning. Also, it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN <commitment>" in your input, in this way your signature would be useless in a different context than voting.

Also note that such voting would be some kind of Proof of Stake. And it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else. It would be Proof of Stake, where users would put their coins at stake to vote. Also, you probably solved "nothing at stake" problem in a nice way, because it would be protected by Proof of Work chain to decide who can vote. So, voters could only freeze their coins for getting some voting power or move their coins and lose their votes.

For me, it sounds similar to "Merged Signing" proposed by stwenhao here: https://bitcointalk.org/index.php?topic=5390027.0. I think it is kind of dangerous and unstoppable (so nobody could stop you if you would ignore any criticism and implement that). Fortunately, it is also possible to add some Proof of Work if any staking-like system would be present in Bitcoin, just OP_SUBSTR would do the trick (if enabled; if not, we could still use OP_HASH256 and force the target by some kind of soft-fork on top of your voting system).

On 2022-03-17 20:58:35 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.

Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been spent.
C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent.

This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent.

Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual).

This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing.

> In perfect competition the mining power costs per chain tends to equal the rewards offered by that chain, both in subsidy and transaction fees.

Agreed, but it takes time for an economic shock to reach its new equilibrium. That period of time, which might be rather precarious, should be considered in a plan to preserve a minority fork.

> Would you rather that proposal be deployed with speedy trial activation or with BIP8+LOT=true activation?

For a proposal I don't want to succeed, I absolutely would prefer speedy trial over BIP8+LOT=true. Speedy trial at 90% signaling threshold can quickly determine that the proposal (hopefully) does not have enough consensus among miners. By contrast, BIP8+LOT=true could polarize the debate, worsening the community's ability to communicate and talk through issues. It would also basically guarantee that a fork happens, which in the best case (in my hypothetical point of view where I don't like the proposal) would mean some small minority forks off the network, which reduces the main chain's value somewhat (at least temporarily). Worst case a small majority forces the issue at near 50% which would cause all sorts of blockchain issues and would have a high probability of leading to a hardfork by the minority.

All this sounds rather more tenable with speedy trial. Any proposal has less chance of causing an actual fork (soft or otherwise) with speedy trial vs LOT=true. LOT=true guarantees a fork if even a single person is running it. LOT=true could certainly come in handy to initiate a UASF, but IMO that's better left as a plan B or C.

> segwit... all the consequences of the change are not opt in.

I definitely agree there. The consequences of a soft fork are not always opt in. That's basically what my example of a "dumb majority soft fork" is, and sounds like what your "evil fork" basically is.

On Thu, Mar 17, 2022 at 7:19 AM Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
> A mechanism of soft-forking against activation exists. What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin? That simply isn't reasonable, but if you think it is, I invite you to create such a fork.

I want BIP+LOT=true to be used. I want speedy trial not to be used.
Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
write it myself, yes.
If you think that's not reasonable code to ever run, I don't think
you're really getting the "softfork THAT YOU OPPOSE" part of the
hypothetical right. Let me try to help with an example, although I
hope we don't get derailed in the implementation details of the
hypothetical evil proposal.

Suppose someone proposes a weight size limit increase by a extension
block softfork.
Or instead of that, just imagine the final version of the covenants
proposal has a backdoor in it or something.

Would you rather that proposal be deployed with speedy trial
activation or with BIP8+LOT=true activation?

>>
>> Please, try to imagine an example for an activation that you wouldn't like yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade my node, which was option 2. I don't know why you dismissed it.

Not upgrading your node doesn't prevent the softfork from being
activated in your chain.
A softfork may affect you indirectly even if you don't use the new
features yourself directly.
You may chose to stay in the old chain even if you don't consider
you're "in the economic majority" at that moment.

> Not much can prevent a miner cartel from enforcing rules that users don't want other than hard forking a replacement POW. There is no effective difference between some developers releasing a malicious soft-fork of Bitcoin and the miners releasing a malicious version themselves. And when the miner cartel forms, they aren't necessarily going to be polite enough to give a transparent signal of their new rules. However, without the economic majority enforcing their set of rules, the cartel continuously risks falling apart from the temptation of transaction fees of the censored transactions.

It is true that a mining cartel doesn't need to use speedy trial or
BIP8+LOT=true to apply rule changes they want just because we do.
But they would do if they wanted to maintain the appearance of benevolence.

> On the other hand, If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin. Look, you cannot have the perfect system of money all by your lonesome self. Money doesn't have economic value if no one else wants to trade you for it. Just ask that poor user who YOLO'd his own taproot activation in advance all by themselves. I'm sure they think they've got just the perfect money system, with taproot early and everything. But now their node is stuck at block 692261 and hasn't made progress since. No doubt they are hunkered down for the long term, absolutely committed to their fork and just waiting for the rest of the world to come around to how much better their version of Bitcoin is than the rest of us.

Well, you could also have the option to stay in the old chain with the
economic minority, it doesn't have to be you alone.
We agree that one person alone can't use a currency.

> Even though you've dismissed it, one of the considerations of taproot was that it is opt-in for users to use the functionality. Future soft-forks ought to have the same considerations to the extent possible.

Well, the same could be said about segwit. And yet all the
consequences of the change are not opt in.
For example, segwit contained a block size limit increase.
Sure, you can just not validate the witnesses, but then you're no
longer a full node.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-03-22 📝 Original message:> ...

2023-06-08T01:06:11+02:00

In reply to nevent1q…nsnx
_________________________

📅 Original date posted:2022-03-22
📝 Original message:> What do you mean "capture that" and "your network"? I was imagining a scenario where these poll messages are always broadcast globally. Are you implying more of a private poll?

If you vote by making a Bitcoin transaction, then someone could move real bitcoins, just by including your transaction into a block. I thought you only want to get some feedback, in this case you only need to sign things, not to move real coins. So, there will be one network for moving bitcoins and one network for signalling/voting/whatever. If you combine both of them to be the same network, then you end up in a situation, where moving coins is needed to signal anything (that may quickly fill mempools and increase on-chain fees).

Also, as you earlier proposed custom data format for signing, I thought you want to create a separate network.

> I still don't understand. Why would a signed transaction be invalid anywhere? Wouldn't a signed transaction be valid everywhere?

It depends what is signed and how it is signed. A transaction moving "1 BTC -> 1.5 BTC" with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY cannot be included directly into a block, but can be turned into a valid transaction, just by attaching more inputs. A signed "Bitcoin Message" can be used to prove ownership, but cannot be included into a block as a valid transaction. So, if you want to move coins and vote, you can just sign a transaction (or even just observe your mempool and receive new blocks, then you can use existing transactions and pretend they are all signalling for or against something). But if you want to only move coins or to only vote, then you need to carefully choose data for signing, just to do one thing and not the other.

> Perhaps I don't understand how signet works well enough to understand this, but I would think that signing an message would work with signet just as well as mainnet. I get the feeling perhaps we're misunderstanding each other in some fundamental way.

In signet, whole transactions are signed. There are separate BIP's that describe signing in a different way than famous "Bitcoin Message". Because if you sign just some message, extending such format is complicated. But if you sign a transaction, then you can sign P2SH address, P2WSH address, Taproot address, and potentially even not-yet-implemented-future-soft-fork-address.

> But it would require an on-chain transaction. We don't want 6 billion people to have to send an on-chain transaction all in the same week in order to register their preference on something.

It would require an on-chain transaction every sometimes, not every vote. If someone is going to do some on-chain transaction, then that person could attach some commitment for the whole network. So, instead of just doing regular transaction, people could attach commitments at the same cost, with the same on-chain transaction size. The only needed change is just tweaking their own keys and informing your network about pushed commitment.

On 2022-03-22 16:19:49 user Billy Tetrud <billy.tetrud at gmail.com> wrote:
> If you vote by making transactions, then someone could capture that and broadcast to nodes
> you can only send that to your network

What do you mean "capture that" and "your network"? I was imagining a scenario where these poll messages are always broadcast globally. Are you implying more of a private poll?

> If it will be sent anywhere else, it will be invalid

I still don't understand. Why would a signed transaction be invalid anywhere? Wouldn't a signed transaction be valid everywhere?

> Another reason to sign transactions and not just some custom data is to make it compatible with "signet way of making signatures", the same as used in signet challenge.

Perhaps I don't understand how signet works well enough to understand this, but I would think that signing an message would work with signet just as well as mainnet. I get the feeling perhaps we're misunderstanding each other in some fundamental way.

> Even if it is not needed, it is kind of "free" if you take transaction size into account

But it would require an on-chain transaction. We don't want 6 billion people to have to send an on-chain transaction all in the same week in order to register their preference on something.

On Mon, Mar 21, 2022 at 10:56 AM <vjudeu at gazeta.pl> wrote:

> I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?

It is simple. If you vote by making transactions, then someone could capture that and broadcast to nodes. If your signature is "useless in a different context", then you can only send that to your network. If it will be sent anywhere else, it will be invalid, so also useless. Another reason to sign transactions and not just some custom data is to make it compatible with "signet way of making signatures", the same as used in signet challenge.

> I don't think any kind of chain is necessary to store this data.

Even if it is not needed, it is kind of "free" if you take transaction size into account. Because each person moving coins on-chain could attach "OP_RETURN <commitment>" in TapScript, just to save commitments. Then, even if someone is not in your network from the very beginning, that person could still collect commitments and find out how they are connected with on-chain transactions.

> Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders.

If it will be ever implemented, it should be done in a similar way as difficulty: if you want 90%, you should calculate, what amount in satoshis is needed to reach that 90%, and update it every two weeks, based on all votes. In this way, you reduce floating-point operations to a bare minimum, and have a system, where you can compare uint64 amounts to quickly get "yes/no" answer to the question, if something should be triggered (also, you can compress it to 32 bits in the same way as 256-bit target is compressed).

> But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages.

As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce all commitments of arbitrary size for "free", so that on-chain transaction size is constant, no matter how large that commitment is. And about storage: you could create a separate chain for that, you could store that in the same way as LN nodes store data, you could use something else, it doesn't really matter, because on-chain commitments could be constructed in the same way (also, as long as the transaction creator keeps those commitments as a secret, there is no way to get them; that means you can add them later if needed and easily pretend that "it was always possible").

On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Good Evening ZmnSCPxj,

> I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.

You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a newer block hash overrides the old poll message at the block with that hash and later blocks. That way if a channel balance changes significantly, a new poll message can be sent out.

Or you could remove the ability to specify fractional support/opposition and exclude multiparty UTXOs from participation. I tend to like the idea of the possibility of full participation tho, even in a world that mainly uses lightning.

> if the signaling is done onchain

I don't think any of this signaling needs to be done on-chain. Anyone who wants to keep a count of the poll can simply collect together all these poll messages and count up the weighted preferences. Yes, it would be possible for one person to send out many conflicting poll messages, but this could be handled without any commitment to the blockchain. A simple thing to do would be to simply invalidate poll messages that conflict (ie include them both in your list of counted messages, but ignore them in your weighted-sums of poll preferences). As long as these polls are simply used to inform action rather than to trigger action, it should be ok that someone can produce biased incomplete counts, since anyone can show a provably more complete set (a superset) of poll messages. Also, since this would generally be a time-bound thing, where this poll information would for example be used to gauge support for a soft fork, there isn't much of a need to keep the poll messages on an immutable ledger. Old poll data is inherently not very practically useful compared to recent poll data. So we can kind of side step things like history attacks by simply ignoring polls that aren't recent.

> Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

I'm not sure I agree with those semantics as a hard rule. I don't consider a "key" to be an owner of anything. A person owns a key, which gives them access to funds. A key is a tool, and the owner of a key or wallet vault can define whatever semantics they want. If they want to designate a hot key as their poll-signing key, that's their prerogative. If they want to require a cold-key as their message-signing key or even require multisig signing, that's up to them as well. You could even mirror wallet-vault constructs by overriding a poll message signed with fewer key using one signed with more keys. The trade offs you bring up are reasonable considerations, and I think which trade offs to choose may vary by the individual in question and their individual situation. However, I think the time-bound and non-binding nature of a poll makes the risks here pretty small for most situations you would want to use this in (eg in a soft-fork poll). It should be reasonable to consider any signed poll message valid, regardless of possibilities of theft or key renting shinanigans. Nacho keys nacho coins would of course be important in this scenario.

> if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

If such a thing did need a soft fork, the chicken and egg question would be easy to answer: the soft fork comes first. We've done soft forks before having this mechanism, and if necessary we could do another one to enable it.

However, I think taproot can enable this mechanism without a soft fork. It should be possible to include a taproot leaf that has the data necessary to validate a signaling signature. The tapleaf would contain an invalid script that has an alternative interpretation, where your poll message can include the merkle path to tapleaf (the invalid-script), and the data at that leaf would be a public key you can then verify the signaling signature against.

@vjudeu

> It should not be expressed in percents, but in amounts

Agreed. You make a good case for that.

> it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN <commitment>" in your input, in this way your signature would be useless in a different context than voting.

I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?

> it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else

I don't think any kind of chain is necessary to store this data. I'm primarily suggesting this as a method to help the debate about a soft fork have better information about what broader users think about a particular soft fork proposal, so such data would simply inform whether or not we decide to continue work on an upgrade. I don't think you'd want to require any validation of this data by all full nodes, because the data could be hundreds of gigabytes in size (let's say 1 billion people respond). You'd have to run some kind of random sampling (more like actual proof of stake) to get this data down to a manageable size.

> It would be Proof of Stake, where users would put their coins at stake to vote.

Sure, as long as by this you mean simply proof of coin ownership. Just as any bitcoin transaction involves proof of coin ownership.

I was pretty careful to avoid the word "voting", since I'm not proposing that this be used with definite thresholds that trigger action, but more of an information gathering mechanism. Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders. We would want to take that into account when deciding how to interpret the data. Even with biased data tho, it could be a useful tool for resolving some contention.

But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages. Those messages could be then read through to gain a better understanding of why people are supporting and why people are rejecting a particular thing. It could inform how we might change how we explain a technical change to make it easier for less technical folks (who don't post on twitter) to understand. It could potentially give insight into an otherwise quiet majority (or large minority).

> it sounds similar to "Merged Signing"

Interesting. I'm not sure I fully grok his idea, but I think he was suggesting that a proof of stake consensus protocol pay attention to bitcoin transactions formatted in a particular way. I think I've hopefully clarified above why the idea I'm suggesting is rather different from this (eg in that no special commitments need to be made).

Cheers,
BT

On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
Good morning Billy,

> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
> B. A signed message like that is valid only while that UTXO has not been spent.
> C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent.
>
> This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent.
>
> Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual).

This does not quite work, as lightning channel balances can be changed at any time.
I might agree that you have 90% of the channel and I have 10% of the channel right now, but if you then send a request to forward your funds out, I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.
This begins to add complexity.

More pointedly, if the signaling is done onchain, then a forward on the LN requires that I put up invalidations of previous signals, also onchain, otherwise you could cheaty cheat your effective balance by moving your funds around.
But the point of LN is to avoid putting typical everyday forwards onchain.

> This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing.

This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, with "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much as possible for security.

I suppose the "cold" key could be put online just once to create the signal message, but vault owners might not want to vote because of the risk, and their weight might be enough to be important in your voting scheme (consider that the point of vaults is to protect large funds).

A sub-issue here with the spend/signal pubkey idea is that if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

Regards,
ZmnSCPxj

📅 Original date posted:2022-03-21 📝 Original message:> I ...

2023-06-08T01:06:09+02:00

In reply to nevent1q…vc6f
_________________________

📅 Original date posted:2022-03-21
📝 Original message:> I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?

It is simple. If you vote by making transactions, then someone could capture that and broadcast to nodes. If your signature is "useless in a different context", then you can only send that to your network. If it will be sent anywhere else, it will be invalid, so also useless. Another reason to sign transactions and not just some custom data is to make it compatible with "signet way of making signatures", the same as used in signet challenge.

> I don't think any kind of chain is necessary to store this data.

Even if it is not needed, it is kind of "free" if you take transaction size into account. Because each person moving coins on-chain could attach "OP_RETURN <commitment>" in TapScript, just to save commitments. Then, even if someone is not in your network from the very beginning, that person could still collect commitments and find out how they are connected with on-chain transactions.

> Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders.

If it will be ever implemented, it should be done in a similar way as difficulty: if you want 90%, you should calculate, what amount in satoshis is needed to reach that 90%, and update it every two weeks, based on all votes. In this way, you reduce floating-point operations to a bare minimum, and have a system, where you can compare uint64 amounts to quickly get "yes/no" answer to the question, if something should be triggered (also, you can compress it to 32 bits in the same way as 256-bit target is compressed).

> But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages.

As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce all commitments of arbitrary size for "free", so that on-chain transaction size is constant, no matter how large that commitment is. And about storage: you could create a separate chain for that, you could store that in the same way as LN nodes store data, you could use something else, it doesn't really matter, because on-chain commitments could be constructed in the same way (also, as long as the transaction creator keeps those commitments as a secret, there is no way to get them; that means you can add them later if needed and easily pretend that "it was always possible").

On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Good Evening ZmnSCPxj,

> I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.

You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a newer block hash overrides the old poll message at the block with that hash and later blocks. That way if a channel balance changes significantly, a new poll message can be sent out.

Or you could remove the ability to specify fractional support/opposition and exclude multiparty UTXOs from participation. I tend to like the idea of the possibility of full participation tho, even in a world that mainly uses lightning.

> if the signaling is done onchain

I don't think any of this signaling needs to be done on-chain. Anyone who wants to keep a count of the poll can simply collect together all these poll messages and count up the weighted preferences. Yes, it would be possible for one person to send out many conflicting poll messages, but this could be handled without any commitment to the blockchain. A simple thing to do would be to simply invalidate poll messages that conflict (ie include them both in your list of counted messages, but ignore them in your weighted-sums of poll preferences). As long as these polls are simply used to inform action rather than to trigger action, it should be ok that someone can produce biased incomplete counts, since anyone can show a provably more complete set (a superset) of poll messages. Also, since this would generally be a time-bound thing, where this poll information would for example be used to gauge support for a soft fork, there isn't much of a need to keep the poll messages on an immutable ledger. Old poll data is inherently not very practically useful compared to recent poll data. So we can kind of side step things like history attacks by simply ignoring polls that aren't recent.

> Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

I'm not sure I agree with those semantics as a hard rule. I don't consider a "key" to be an owner of anything. A person owns a key, which gives them access to funds. A key is a tool, and the owner of a key or wallet vault can define whatever semantics they want. If they want to designate a hot key as their poll-signing key, that's their prerogative. If they want to require a cold-key as their message-signing key or even require multisig signing, that's up to them as well. You could even mirror wallet-vault constructs by overriding a poll message signed with fewer key using one signed with more keys. The trade offs you bring up are reasonable considerations, and I think which trade offs to choose may vary by the individual in question and their individual situation. However, I think the time-bound and non-binding nature of a poll makes the risks here pretty small for most situations you would want to use this in (eg in a soft-fork poll). It should be reasonable to consider any signed poll message valid, regardless of possibilities of theft or key renting shinanigans. Nacho keys nacho coins would of course be important in this scenario.

> if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

If such a thing did need a soft fork, the chicken and egg question would be easy to answer: the soft fork comes first. We've done soft forks before having this mechanism, and if necessary we could do another one to enable it.

However, I think taproot can enable this mechanism without a soft fork. It should be possible to include a taproot leaf that has the data necessary to validate a signaling signature. The tapleaf would contain an invalid script that has an alternative interpretation, where your poll message can include the merkle path to tapleaf (the invalid-script), and the data at that leaf would be a public key you can then verify the signaling signature against.

@vjudeu

> It should not be expressed in percents, but in amounts

Agreed. You make a good case for that.

> it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN <commitment>" in your input, in this way your signature would be useless in a different context than voting.

I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?

> it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else

I don't think any kind of chain is necessary to store this data. I'm primarily suggesting this as a method to help the debate about a soft fork have better information about what broader users think about a particular soft fork proposal, so such data would simply inform whether or not we decide to continue work on an upgrade. I don't think you'd want to require any validation of this data by all full nodes, because the data could be hundreds of gigabytes in size (let's say 1 billion people respond). You'd have to run some kind of random sampling (more like actual proof of stake) to get this data down to a manageable size.

> It would be Proof of Stake, where users would put their coins at stake to vote.

Sure, as long as by this you mean simply proof of coin ownership. Just as any bitcoin transaction involves proof of coin ownership.

I was pretty careful to avoid the word "voting", since I'm not proposing that this be used with definite thresholds that trigger action, but more of an information gathering mechanism. Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders. We would want to take that into account when deciding how to interpret the data. Even with biased data tho, it could be a useful tool for resolving some contention.

But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages. Those messages could be then read through to gain a better understanding of why people are supporting and why people are rejecting a particular thing. It could inform how we might change how we explain a technical change to make it easier for less technical folks (who don't post on twitter) to understand. It could potentially give insight into an otherwise quiet majority (or large minority).

> it sounds similar to "Merged Signing"

Interesting. I'm not sure I fully grok his idea, but I think he was suggesting that a proof of stake consensus protocol pay attention to bitcoin transactions formatted in a particular way. I think I've hopefully clarified above why the idea I'm suggesting is rather different from this (eg in that no special commitments need to be made).

Cheers,
BT

On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
Good morning Billy,

> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
> B. A signed message like that is valid only while that UTXO has not been spent.
> C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent.
>
> This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent.
>
> Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual).

This does not quite work, as lightning channel balances can be changed at any time.
I might agree that you have 90% of the channel and I have 10% of the channel right now, but if you then send a request to forward your funds out, I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.
This begins to add complexity.

More pointedly, if the signaling is done onchain, then a forward on the LN requires that I put up invalidations of previous signals, also onchain, otherwise you could cheaty cheat your effective balance by moving your funds around.
But the point of LN is to avoid putting typical everyday forwards onchain.

> This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing.

This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, with "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much as possible for security.

I suppose the "cold" key could be put online just once to create the signal message, but vault owners might not want to vote because of the risk, and their weight might be enough to be important in your voting scheme (consider that the point of vaults is to protect large funds).

A sub-issue here with the spend/signal pubkey idea is that if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

Regards,
ZmnSCPxj

📅 Original date posted:2022-03-04 📝 Original message:> ...

2023-06-08T01:05:04+02:00

In reply to nevent1q…lm2g
_________________________

📅 Original date posted:2022-03-04
📝 Original message:> The Taproot address itself has to take up 32 bytes onchain, so this saves nothing.

There is always at least one address, because you have a coinbase transaction and a solo miner or mining pool that is getting the whole reward. So, instead of using separate OP_RETURN's for each sidechain, for each federation, and for every "commitment to the blockchain", all we need is just tweaking that miner's key and placing everything inside unused TapScript. Then, we don't need separate 32 bytes for this and separate 32 bytes for that, we only need a commitment and a MAST-based path that can link such commitment to the address of this miner.

So, instead of having:

<coinbasePubkey>
<opReturn1>
<opReturn2>
...
<opReturnN>

We could have:

<tweakedCoinbasePubkey>

On 2022-03-04 09:42:23 user ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning vjudeu,

> > Continuous operation of the sidechain then implies a constant stream of 32-byte commitments, whereas continuous operation of a channel factory, in the absence of membership set changes, has 0 bytes per block being published.
>
> The sidechain can push zero bytes on-chain, just by placing a sidechain hash in OP_RETURN inside TapScript. Then, every sidechain node can check that "this sidechain hash is connected with this Taproot address", without pushing 32 bytes on-chain.

The Taproot address itself has to take up 32 bytes onchain, so this saves nothing.

Regards,
ZmnSCPxj

📅 Original date posted:2022-02-24 📝 Original message:> ...

2023-06-08T01:04:52+02:00

In reply to nevent1q…a0az
_________________________

📅 Original date posted:2022-02-24
📝 Original message:> Also, tweaking an ECC point (this includes tapscript) in non-deterministic ways also makes it harder to recover from backup, because you can't recover the key without knowing the full commitment.
I don't think so. You can spend coins from taproot by key or by script. If you spend by key, making backup is simple, we have WIF for that. If you spend by script, you only need a part of the tree. So, you can "recover the key without knowing the full commitment", because you can spend coins "without knowing the full commitment". On-chain, you never reveal your "OP_RETURN <data>" or "OP_RETURN <hash>" or "<tapbranch> <tapbranch> <tapbranch> OP_RETURN <chunk_of_data>". Those additional branches are stored only by those who wants their data to be connected with some key, knowing the full script is not needed, because it is not needed for on-chain validation.
> Furthermore, the scheme is not actually equivalent to op_return, because it requires the user to communicate out-of-band to reveal the commitment, whereas with op_return the data is immediately visible (while not popular, BIP47 and various colored coin protocols rely on this).
Yes, but storing that additional data on-chain is not needed. It is expensive. By paying one satoshi per byte, you would pay 0.01 BTC for pushing 1 MB of data. That means 1 BTC for 100 MB of data, so 15 BTC for that 1.5 GB file. And in practice it is the absolute minimum, because you have to wrap your data somehow, you cannot just push 1.5 GB file. By placing that in TapScript, you can use your taproot public key as usual and attach any data into your key for "free", because it takes zero additional bytes on-chain.
On 2022-02-24 11:08:39 user Ruben Somsen <rsomsen at gmail.com> wrote:
Note this has always been possible, and is not specifically related to tapscript. As long as you're committing to an ECC point, you can tweak it to commit data inside it (i.e. pay-to-contract). This includes P2PK and P2PKH.

Committing to 1.5GB of data has equally been possible with OP_RETURN <hash>, or even an entire merkle tree of hashes, as is the case with Todd's opentimestamps.

Also, tweaking an ECC point (this includes tapscript) in non-deterministic ways also makes it harder to recover from backup, because you can't recover the key without knowing the full commitment.

Furthermore, the scheme is not actually equivalent to op_return, because it requires the user to communicate out-of-band to reveal the commitment, whereas with op_return the data is immediately visible (while not popular, BIP47 and various colored coin protocols rely on this).

Cheers,
Ruben

On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Since Taproot was activated, we no longer need separate OP_RETURN outputs to be pushed on-chain. If we want to attach any data to a transaction, we can create "OP_RETURN <anything>" as a branch in the TapScript. In this way, we can store that data off-chain and we can always prove that they are connected with some taproot address, that was pushed on-chain. Also, we can store more than 80 bytes for "free", because no such taproot branch will be ever pushed on-chain and used as an input. That means we can use "OP_RETURN <1.5 GB of data>", create some address having that taproot branch, and later prove to anyone that such "1.5 GB of data" is connected with our taproot address.

Currently in Bitcoin Core we have "data" field in "createrawtransaction". Should the implementation be changed to place that data in a TapScript instead of creating separate OP_RETURN output? What do you think?
_______________________________________________
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/20220224/532d2b75/attachment-0001.html>;

📅 Original date posted:2022-01-01 📝 Original message:> ...

2023-06-08T01:01:46+02:00

In reply to nevent1q…luuc
_________________________

📅 Original date posted:2022-01-01
📝 Original message:> If you don't like the reduction of the block subsidy, well that's a much bigger problem.
It is reversible, because you can also increase the block subsidy by using another kind of soft-fork. For example, you can create spendable outputs with zero satoshis. In this way, old nodes will accept that silently, but new nodes can check something more, because you can specify somewhere else, what is the "real" amount. Finally, if all nodes will upgrade, you will end up in a network, where all transactions spend zero satoshi inputs, create zero satoshi outputs and have zero fee. Old nodes would accept all of that, but new nodes would really see, what is going on, and they will check that all rules are met, and the new subsidy is for example increased x1000 (that could lead to the same situation as moving from satoshis to millisatoshis with some hard-fork, but doing that kind of change with a soft-fork is safer).
On 2021-12-31 10:35:06 user Keagan McClelland via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> But whether or not it is a basic principle of general software engineering kind of misses the point. Security critical software clearly isn't engineered in the same way as a new social media app. Bugs are easily reverted in a new social media app.On top of that we aren't just dealing with security critical software. One of the most important objectives is to keep all the nodes on the network in consensus. Introducing a consensus change before we are comfortable there is community consensus for it is a massive effective bug in itself. The network can split in multiple ways e.g. part of the network disagrees on whether to activate the consensus change, part of the network disagrees on how to resist that consensus change, part of the network disagrees on how to activate that consensus change etc

> A consensus change is extremely hard to revert and probably requires a hard fork, a level of central coordination we generally attempt to avoid and a speed of deployment that we also attempt to avoid.

This seems to assert the idea that soft forks are all the same: they are not. For instance a soft fork, lowering the block subsidy is completely different than changing the semantics of an OP_NOP to have semantics that may reject a subset of the witnesses that attest to the transactions permissibility. As a result, reversion means two entirely different things in these contexts. While a strict reversion of both soft forks is by definition a hard fork, the requirement of reversion as a result of undesired behavior is not the same. In the case of opcodes, there is almost never a requirement to revert it. If you don't like the way the opcodes behave, then you just don't use them. If you don't like the reduction of the block subsidy, well that's a much bigger problem.

I make this point to elucidate the idea that we cannot treat SoftForks™ as a single monolithic idea. Perhaps we need to come up with better terminology to be specific about what each fork actually is. The soft vs. hard distinction is a critical one but it is not enough and treating soft forks that are noninvasive such as OP_NOP tightenings. This has been proposed before [1], and while I do not necessarily think the terms cited are necessarily complete, they admit the low resolution of our current terminology.

> Soft fork features can (and should) obviously be tested thoroughly on testnet, signet, custom signets, sidechains etc on a standalone basis and a bundled basis.

I vehemently disagree that any consensus changes should be bundled, especially when it comes to activation parameters. When we start to bundle things, we amplify the community resources needed to do review, not reduce them. I suspect your opinion here is largely informed by your frustration with the Taproot Activation procedure that you underwent earlier this year. This is understandable. However, let me present the alternative case. If we start to bundle features, the review of the features gets significantly harder. As the Bitcoin project scales, the ability of any one developer to understand the entire codebase declines. Bundling changes reduces the number of people who are qualified to review a particular proposal, and even worse, intimidates people who may be willing and able to review logically distinct portions of the proposal, resulting in lower amounts of review overall. This will likely have the opposite effect of what you seem to desire. BIP8 and BIP9 give us the ability to have multiple independent soft forks in flight at once. Choosing to bundle them instead makes little sense when we do not have to. Bundling them will inevitably degenerate into political horse trading and everyone will be worse off for it.

> part of the network disagrees on whether to activate the consensus change, part of the network disagrees on how to resist that consensus change, part of the network disagrees on how to activate that consensus change etc

Disagreements, and by extension, forks are a part of Bitcoin. What is important is that they are well defined and clean. This is the reason why the mandatory signaling period exists in BIP8/9, so that clients that intend to reject the soft fork change have a very easy means of doing so in a clean break where consensus is clearly divergent. In accordance with this, consensus changes should be sequenced so that people can decide which sides of the forks they want to follow and that the economic reality can reorganize around that. If choose to bundle them, you have one of two outcomes: either consensus atomizes into a mist where people have different ideas of which subsets of a soft fork bundle they want to adopt, or what likely comes after is a reconvergence on the old client with none of the soft fork rules in place. This will lead to significantly more confusion as well given that with sufficient miner consensus some of the rules may stick anyway even if the rest of the user base reconverges on the old client.

It is quite likely less damaging to consensus to have frequent but strictly sequenced soft forks so that if one of the new rules is contentious the break can happen cleanly. That said, if Core or any other client wishes to cut a release of the software with the parameters bundled into a single release, that is a significantly more palatable state of affairs, as you can still pipeline signaling and activation. However, the protocol itself adopting a tendency to activate unrelated proposals in bundles is a recipe for disaster.

Respectfully,
Keagan

[1] https://www.truthcoin.info/blog/protocol-upgrade-terminology
On Sat, Oct 16, 2021 at 12:57 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Interesting discussion. Correct me if I'm wrong: but putting too many features together in one shot just can't make things harder to debug in production if something very unexpected happens. It's a basic principle of software engineering.

Soft fork features can (and should) obviously be tested thoroughly on testnet, signet, custom signets, sidechains etc on a standalone basis and a bundled basis. But whether or not it is a basic principle of general software engineering kind of misses the point. Security critical software clearly isn't engineered in the same way as a new social media app. Bugs are easily reverted in a new social media app. A consensus change is extremely hard to revert and probably requires a hard fork, a level of central coordination we generally attempt to avoid and a speed of deployment that we also attempt to avoid. On top of that we aren't just dealing with security critical software. One of the most important objectives is to keep all the nodes on the network in consensus. Introducing a consensus change before we are comfortable there is community consensus for it is a massive effective bug in itself. The network can split in multiple ways e.g. part of the network disagrees on whether to activate the consensus change, part of the network disagrees on how to resist that consensus change, part of the network disagrees on how to activate that consensus change etc

In addition, a social media app can experiment in production whether Feature A works, whether Feature B works or whether Feature A and B work best together. In Bitcoin if we activate consensus Feature A, later decide we want consensus Feature B but find out that by previously activating Feature A we can't have Feature B (it is now unsafe to activate it) or its design now has to be suboptimal because we have to ensure it can safely work in the presence of Feature A we have made a mistake by activating Feature A in the first place. Decentralized security critical consensus changes are an emerging field in itself and really can't be treated like any other software project. This will become universally understood I'm sure over time.

-- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Interesting discussion. Correct me if I'm wrong: but putting too many features together in one shot just can't make things harder to debug in production if something very unexpected happens. It's a basic principle of software engineering.

Change. Deploy. Nothing bad happened? Change it a little more. Deployment.
Or: Change, change, change. Deploy. Did something bad happen? What change caused the problem?
On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote:
> > ... in this post I will argue against frequent soft forks with a single or
> minimal
> > set of features and instead argue for infrequent soft forks with batches
> > of features.
> I think this type of development has been discussed in the past and has been
> rejected.
> AJ: - improvements: changes might not make everyone better off, but we
> don't want changes to screw anyone over either -- pareto
> improvements in economics, "first, do no harm", etc. (if we get this
> right, there's no need to make compromises and bundle multiple
> flawed proposals so that everyone's an equal mix of happy and
> miserable)
I don't think your conclusion above matches my opinion, for what it's
worth.
If you've got two features, A and B, where the game theory is:
If A happens, I'm +100, You're -50
If B happens, I'm -50, You're +100
then even though A+B is +50, +50, then I do think the answer should
generally be "think harder and come up with better proposals" rather than
"implement A+B as a bundle that makes us both +50".
_But_ if the two features are more like:
If C happens, I'm +100, You're +/- 0
If D happens, I'm +/- 0, You're +100
then I don't have a problem with bundling them together as a single
simultaneous activation of both C and D.
Also, you can have situations where things are better together,
that is:
If E happens, we're both at +100
If F happens, we're both at +50
If E+F both happen, we're both at +9000
In general, I think combining proposals when the combination is better
than the individual proposals were is obviously good; and combining
related proposals into a single activation can be good if it is easier
to think about the ideas as a set.
It's only when you'd be rejecting the proposal on its own merits that
I think combining it with others is a bad idea in principle.
For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx
and CHECKSIGADD together because they do have synergies like that; we
didn't bundle ANYPREVOUT and graftroot despite the potential synergies
because those features needed substantially more study.
The nulldummy soft-fork (bip 147) was deployed concurrently with
the segwit soft-fork (bip 141, 143), but I don't think there was any
particular synergy or need for those things to be combined, it just
reduced the overhead of two sets of activation signalling to one.
Note that the implementation code for nulldummy had already been merged
and were applied as relay policy well before activation parameters were
defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming
an active soft fork.
Cheers,
aj
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220101/b88be538/attachment-0001.html>;

📅 Original date posted:2021-10-16 📝 Original message:> ...

2023-06-08T01:00:10+02:00

In reply to nevent1q…nq0y
_________________________

📅 Original date posted:2021-10-16
📝 Original message:> What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time?

The chain will halt for all old clients, because there is no 32-bit value greater than 0xffffffff.

> 1. Is not violated, since "not lower than" means "greater than or equal to"

No, because it has to be strictly "greater than" in the Bitcoin Core source code, it is rejected when it is "lower or equal to", see: https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094

> 2. Is not violated, since it would be a past actual real time.

If the current time is 0x0000000100000000, then the lowest 32 bits will point to some time around 1970, so for old clients two rules are violated at the same time.

> 3. Is not violated since 0xFFFFFFFF < 0x100000000.

This is hard to change, because 32-bit timestamps are included in block headers, so using any wider data type here will make it hardware-incompatible and will cause a hard-fork. That's why I think new timestamps should be placed in the coinbase transaction. But that still does not solve chain halting problem.

To test chain halting, all that is needed is starting regtest and producing one block with 0xffffffff timestamp, just after the Genesis Block. Then, median time is equal to 0xffffffff and adding any new blocks is no longer possible. The only soft-fork solution I can see require overwriting that block.

Example from https://bitcointalk.org/index.php?topic=5365359.0

submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
null
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp is too early (code -1)

I don't know any timestamp that can be used in any next block and accepted by old nodes.

On 2021-10-16 01:01:54 user ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning yanmaani,

> It's well-known. Nobody really cares, because it's so far off. Not
> possible to do by softfork, no.

I think it is possible by softfork if we try hard enough?

> 1. The block timestamp may not be lower than the median of the last 11
> blocks'
>
> 2. The block timestamp may not be greater than the current time plus two
> hours
>
> 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
> 06:28:16 +0000)

What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time?

In that case:

1. Is not violated, since "not lower than" means "greater than or equal to", and after a while the median becomes 0xFFFFFFFF and 0xFFFFFFFF == 0xFFFFFFFF
2. Is not violated, since it would be a past actual real time.
3. Is not violated since 0xFFFFFFFF < 0x100000000.

In that case, we could then add an additional rule, which is that a 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase transaction, with similar rules except translated to 64-bit/128-bit/256-bit.

Possibly a similar scheme could be used for `nLockTime`; we could put a 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if the legacy v`nLockTime` is at the maximum seconds-timelock possible.

Regards,
ZmnSCPxj

📅 Original date posted:2021-10-15 📝 Original message:Your ...

2023-06-08T01:00:08+02:00

In reply to nevent1q…ccu4
_________________________

📅 Original date posted:2021-10-15
📝 Original message:Your solution seems to solve the problem of chain halting, but there are more issues. For example: if you have some time modulo 2^32, then you no longer know if timestamp zero is related to 1970 or 2106 or some higher year. Your "k" value representing in fact the most significant 32 bits of 64-bit timestamp has to be stored in all cases where time is used. If there is no "k", then zero should be used for backward compatibility. Skipping "k" could cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was timestamped to 0xbadc0ded, then that transaction will be valid in 0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in 0x00000001badc0ded, the same for timelocked outputs.

So, I think your "k" value should be added to the coinbase transaction, then you can combine two 32-bit values, the lower bits from the block header and the higher bits from the coinbase transaction. Also, adding your "k" value transaction nLockTime field is needed (maybe in a similar way as transaction witness was added in Segwit), because in other case after reaching 0x0000000100000000 all off-chain transactions with timelocks around 0x00000000ffffffff will be additionally timelocked for the next N years. The same is needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the currently used value will solve that (and assuming zero if there is only some 32-bit value).

On 2021-10-15 23:48:59 user yanmaani at cock.li wrote:
> It's well-known. Nobody really cares, because it's so far off. Not
possible to do by softfork, no. It is possible to do by something that
becomes a hardfork in 80 years, though, which is probably good enough.

I proposed a solution, but nobody was really interested. Let's see if
anyone bites now.

---

Subject: Suggestion: Solve year 2106 problem by taking timestamps mod
2^32
To Bitcoin Protocol Discussion
Date 2020-09-19 12:36
Message Body
Currently, Bitcoin's timestamp rules are as follows:

1. The block timestamp may not be lower than the median of the last 11
blocks'
2. The block timestamp may not be greater than the current time plus two
hours
3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
06:28:16 +0000)

Thus, Bitcoin will "die" on or about 2106-02-07, when there is no
timestamp below 2^32 that exceeds the median of the last 11 blocks.

If the rules were changed to the following, this problem would be
solved:

1. The block timestamp plus k*2^32 may not be lower than the median of
the last 11 blocks'
2. The block timestamp plus k*2^32 may not be greater than the current
time plus two hours
3. k is an integer, whose value must be the same for the calculations of
Rule 1 and Rule 2

This would cause a hardfork in the year 2106, which is approximately
85.5 years from now, by which time 95% of nodes would hopefully have
updated.

Another proposed solution is 64-bit timestamps. They would break
compatibility with other software that has specific expectations of
header fields, like ASICs' firmware. They would also cause a hardfork
before the date of timestamp overflow. I thus believe them to be a less
appropriate solution.

What do you think of this idea? Is it worth a BIP?

On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote:
> It seems that Bitcoin Core will stop working in 2038 because of
> assertion checking if the current time is non-negative. Also, the
> whole chain will halt after reaching median time 0xffffffff in 2106.
> More information: https://bitcointalk.org/index.php?topic=5365359.0
>
> I wonder if that kind of issues are possible to fix in a soft-fork
> way.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-10-13 📝 Original message:It ...

2023-06-08T01:00:06+02:00

In reply to nevent1q…4qj7
_________________________

📅 Original date posted:2021-10-13
📝 Original message:It seems that Bitcoin Core will stop working in 2038 because of assertion checking if the current time is non-negative. Also, the whole chain will halt after reaching median time 0xffffffff in 2106. More information: https://bitcointalk.org/index.php?topic=5365359.0
I wonder if that kind of issues are possible to fix in a soft-fork way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211013/de85a966/attachment.html>;