vjudeu at gazeta.pl [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-09-12 to 2023-05-11
💬 Posted a total of 57 messages
📚 Participated in the following categories: bitcoin-dev, Bitcoin Advent Calendar
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssga

Profile Code

nprofile1qqsg608haw5jzqmyp8clasr5e7x0mzf9h37trr346dvtrnxgjafwuvsgn3e2k

Author Public Key

npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssga

Show more details

Last Notes

2023-09-07 11:52:36

- reply

📅 Original date posted:2023-09-03
🗒️ Summary of this message: People may be more open to a smaller blocksize to address concerns about blockchain size and push more activity to the lightning network. Another approach called cut-through could remove inscriptions while keeping the payment intact.
📝 Original message:
> Given the current concerns with blockchain size increases due to inscriptions, and now that the lightning network is starting to gain more traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning?
People will not agree to shrink the maximum block size. However, if you want to kill inscriptions, there is another approach, that could be used to force them into second layers: it is called cut-through, and was described in this topic: https://bitcointalk.org/index.php?topic=281848.0
Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for example some inscriptions were created in "Alice -> Bob" transaction, then cut-through could remove those inscriptions, while leaving the payment unaffected, because the proper amount of coins will be received by Zack, as it should be.
On 2023-08-25 10:44:41 user GamedevAlice via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
As I understand it, protecting against this is exactly the reason why a blocksize limit exists. Perhaps it should never have been increased in the first place.
Given the current concerns with blockchain size increases due to inscriptions, and now that the lightning network is starting to gain more traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning?
On Tue, Aug 22, 2023, 8:00 AM , <bitcoin-dev-request at lists.linuxfoundation.org> wrote:
Send bitcoin-dev mailing list submissions to
bitcoin-dev at lists.linuxfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
bitcoin-dev-request at lists.linuxfoundation.org
You can reach the person managing the list at
bitcoin-dev-owner at lists.linuxfoundation.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."
Today's Topics:
1. Re: Concern about "Inscriptions" (symphonicbtc)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Aug 2023 22:34:03 +0000
From: symphonicbtc <symphonicbtc at proton.me>
To: John Tromp <john.tromp at gmail.com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Message-ID:
<UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@proton.me>
Content-Type: text/plain; charset=utf-8
It is important to also note that proof of secret key schemes are highly data inefficient and likely would have a higher cost for users than simply allowing arbitrary data to continue. In ECDSA, purposely re-using k values allows you to encode data in both k and the entire secret key, as both become computable. Or, one could bruteforce a k value to encode data in a sig, as is done in some compromised hardware key exfiltration attacks. Additionally, one can bruteforce keys in order to encode data in the public key.
It is very difficult and expensive to attempt to limit the storage of arbitrary data in a system where the security comes from secret keys being arbitrary data.
Symphonic
------- Original Message -------
On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If we ban "arbitrary data", however you want to define it, then actors will
> > simply respond by encoding their data within sets of public keys. Public
> > key data is indistinguishable from random data, and, unless we are willing
> > to pad the blockchain with proof of knowledge of secret keys, there will be
> > no way to tell a priori whether a given public key is really a public key
> > or whether it is encoding an inscription or some other data.
>
>
> Note that in the Mimblewimble protocol, range proofs already prove
> knowledge of blinding factor in Pedersen commitments, and thus no
> additional padding is needed there to prevent the encoding of spam
> into cryptographic material. This makes pure MW blockchains the most
> inscription/spam resistant [1].
>
> [1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------
Subject: Digest Footer
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------
End of bitcoin-dev Digest, Vol 99, Issue 43
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230903/26efb381/attachment.html>

2023-09-07 11:52:36

- reply

📅 Original date posted:2023-09-06
🗒️ Summary of this message: Cut-through transactions will not affect inscriptions, as the original transactions still exist in the blockchain and can be accessed by full archival nodes.
📝 Original message:
> that does not change the fact that Alice -> Bob -> Zack was mined in the blockchain, and those transactions exist
If you use it in that way, then cut-through is pointless. The whole point of using it is scaling. If you have only "Alice -> Zack" transaction, that is included in some block, then cut-through is really useful. In other cases, if you include all transactions anyway, and create only a proof for some nodes, then it doesn't scale, because you have to always process those transactions in the middle, while there is no need to do so. It is needed only during batching, to prevent double-spending, but if it is deeply confirmed, then who needs something that doesn't scale?
Also, going in that direction is a natural consequence of enabling full-RBF: transactions will be replaced, which means mempool-level-batching (ideally non-interactive, done automatically by nodes) will be next, sooner or later.
On 2023-09-05 19:49:51 user Peter Todd <pete at petertodd.org> wrote:
On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote: > > Given the current concerns with blockchain size increases due to inscriptions, and now that the lightning network is starting to gain more traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning? > > People will not agree to shrink the maximum block size. However, if you want to kill inscriptions, there is another approach, that could be used to force them into second layers: it is called cut-through, and was described in this topic: https://bitcointalk.org/index.php?topic=281848.0 > > Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for example some inscriptions were created in "Alice -> Bob" transaction, then cut-through could remove those inscriptions, while leaving the payment unaffected, because the proper amount of coins will be received by Zack, as it should be. You are incorrect: cut-through transactions will not meaningfully affect inscriptions. While it is true that with fancy cryptography we can prove the Alice -> ... -> Zack chain, that does not change the fact that Alice -> Bob -> Zack was mined in the blockchain, and those transactions exist. Anyone running a full archival node will still have those transactions, and can provide them (and all their inscription data) to anyone who needs it. This is not unlike how in Bitcoin right now many people run pruned nodes that do not have any archival inscription data. Them running those nodes does not prevent others from running full archival nodes that do make that data available. -- https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230906/8b4c08ec/attachment-0001.html>

2023-07-28 15:08:07

- reply

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

2023-07-27 00:26:35

- reply

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

2023-06-14 14:16:40

- reply

📅 Original date posted:2023-06-12
🗒️ Summary of this message: A developer experienced in contributing to Bitcoin-related projects expressed frustration over their post not being published on the Bitcoin-dev mailing list, speculating that strict moderation rules may be the cause. They noted that starting a new topic requires more effort and justification than replying to an existing one, and that rejection of a new topic is not necessarily due to the content, but rather the topic itself being deemed irrelevant or spam.
📝 Original message:
> Nevertheless, I next day I see other e-mails getting released to bitcoin-dev, while mine - was not.
If you created a new topic, then that is the reason. I noticed an interesting thing: if the title of your post is just a reply to some existing topic, then there are less strict rules, than if you create a new one. It is hard to start new topics properly, it is not a forum, a lot of effort is needed to create some new discussion, and pass through all moderation filters. However, if you reply to some existing post, then it is all about quotes and replies, there are less requirements. In the past, I tried writing two very similar replies, just with a different title, and guess what: the one with "re" was published, but the one with the new title was rejected. The reason is that people filter messages by title, and some of them read only some topics, so if you bring a new one, then they can get angry, if they are not interested in it. However, if you start from existing topic, and you gradually move the discussion into something else, then the title will be finally changed by some moderator into "Topic Y (was: topic X)", and that approach is much easier than starting from "Topic Y" explicitly.
The main reason for such moderation is this: if you reply for some topic, then there are rules for the quality of your reply, and nothing else. But if you start a new topic, then there are more sieves: not only your content has to meet some criteria, but also bringing that new particular topic has to be justified. So, rejecting replies is about "your content is spam", but rejecting new topic is about "talking about this is spam, no matter of the content".
On 2023-06-03 01:48:45 user Dr Maxim Orlovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Dear community,
I am writing this list to bitcoin-dev mail list, but to prevent potential censorship I am sending CC to lightning-dev mail list, in order to leave the current moderator(s) without an option not to publish the letter and not to leave the topic “under the cover” (sorry Lightning friends for spamming your list with this off-topic).
A day before yesterday I sent a post to bitcoin-dev referencing the publication of the new Bitcoin scalability and privacy protocol, which had already received a broad reaction across the bitcoin community with literally no critical/negative responses after ~25k of reads [1]. I am not the first-time writer to the mail list and had developed things like RGB smart contracts [2], rust lightning implementation named LNP [3], multiple bitcoin libraries and software [4], [5], during three years was a main contributor to rust-bitcoin [6] etc, etc. The post was clearly not spam and received support from known community members like Giacomo Zucco [7]. Bryan Bishop knows me since 2019 when I was presenting Storm protocol on the stage on Scaling Bitcoin in Tel Aviv - and he was writing a transcript of it [8]. Thus, I am not a random unknown guy or a known spammer - and the post can be easily checked for not containing any scam promotion.
Nevertheless, I next day I see other e-mails getting released to bitcoin-dev, while mine - was not. It is not a problem, but since we already had an incident in the past where Bryan reported the failure of his software, me and my colleagues from LNP/BP Standards Association started asking questions about whether this post ever got to Bryan.
What happened next was very unexpected. I am giving the core of the conversation over Twitter after in Annex A - with the purpose to showcase the problem I’d like to address in this e-mail. From the discussion, it is clear that bitcoin-dev mail list lacks clear explicit moderation (or peer-review) policies, which must be applied on a non-selective basis. Also, Bryan Bishop, as the current moderator, had abused his powers in achieving his agenda based on personal likes or dislikes. The conversation went nowhere, and the post got published only after a requirement from Peter Todd [9].
In this regard, I’d like to propose the following:
The bitcoin-dev mail list must have a clear moderation (or pre-publication peer-review policy). It can be proposed and discussed in this mail list and, upon agreement, must become public and obligatory.
Bryan Bishop, who was acting for a long time as moderator, must be appreciated for many years of unpaid work, and replaced with the new moderator who should be selected from a list of potential candidates (again in this mail list) using the criteria “least votes against”.
The role of the moderator(s) must be purely executive of the policies, without any personal preferences.
A dedicated mail list should be created (“bitcoin-dev-unmoderated”) which will publish all submissions without moderation. It may contain spam and only people interested in the auditing bitcoin-dev main mal list non-censorship will be reading it. However, if they will notice that some non-spam e-mails were censored, they can announce that publicly. In this case, the failing moderator(s) should be removed and replaced.
The incentive to work as a moderator should be reputation-based.
With that, I rest my case.
Kind regards,
Maxim Orlovsky
[1]: https://twitter.com/lnp_bp/status/1664329393131364353?s=61&t=9A8uvggqKVKV3sT4HPlQyg
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html
[3]: https://github.com/LNP-WG
[4]: https://github.com/BP-WG
[5]: https://github.com/mycitadel
[6]: https://github.com/rust-bitcoin/rust-bitcoin/graphs/contributors?from=2018-12-31&to=2022-04-12&type=c
[7]: https://twitter.com/giacomozucco/status/1664515543154544645?s=61&t=9A8uvggqKVKV3sT4HPlQyg and https://twitter.com/giacomozucco/status/1664731504923095041?s=61&t=9A8uvggqKVKV3sT4HPlQyg
[8]: https://scalingbitcoin.org/transcript/telaviv2019/wip-storm-layer-2-3-storage-and-messaging
[9]: https://twitter.com/peterktodd/status/1664742651835367424?s=61&t=9A8uvggqKVKV3sT4HPlQyg
Annex A:
@kanzure just like to check that our submission to bitcoin-dev hasn’t got to spam <https://twitter.com/lnp_bp/status/1664649328349069320?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
A few mods are reviewing it <https://twitter.com/kanzure/status/1664680893548572677?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Oh, so a peer review is required to get to bitcoin-dev mail list? Never read about that requirement anywhere <https://twitter.com/lnp_bp/status/1664695061462777858?s=61&t=9A8uvggqKVKV3sT4HPlQyg>. Seems like bitcoin-dev mail list requirements are now specific to the author :) <https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Not the greatest email to pull this over. I'll double check but pretty sure the antagonization is boring me. <https://twitter.com/kanzure/status/1664705038315409420?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Not sure I understand what you are saying. Can you please clarify? <https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
You are boring me and these antics don't make me want to go click approve on your email. <https://twitter.com/kanzure/status/1664705509147004946?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Are you the person to approve emails for it? <https://twitter.com/phyrooo/status/1664732932068589568?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Yes <https://twitter.com/kanzure/status/1664733107096899585?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
It appears that people boring @kanzure is going through a dedicated review procedure on bitcoin-dev mail list. Good moderation! Very clear policy! <https://twitter.com/dr_orlovsky/status/1664706165790461959?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
What are you even doing. How does this behavior suppose to get people to help you? <https://twitter.com/kanzure/status/1664706931083329536?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
I am not expecting you to help me - and never asked. I expect you to openly declare moderation (or peer review) policy and follow it. <https://twitter.com/dr_orlovsky/status/1664719295123685381?s=61&t=9A8uvggqKVKV3sT4HPlQyg> Since “if you get me bored I will not click an accept button” is not a moderation policy which I expect from bitcoin-dev mail list. Probably not just me. <https://twitter.com/dr_orlovsky/status/1664719786633310209?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Yeah I mean I don't think these tweets are likely to get me to enthusiastically resolve your problem... I dunno man. What's even going on here. <https://twitter.com/kanzure/status/1664735139065208833?s=61&t=9A8uvggqKVKV3sT4HPlQyg>
Bitcoin mail list clearly lacks explicit moderation policy. The same mistake like with rust-bitcoin 1+ yrs ago. I am fine with peer review. Moderation. But only explicit - not just “the way I (dis)like this guy” <https://twitter.com/dr_orlovsky/status/1664736404931321859?s=61&t=9A8uvggqKVKV3sT4HPlQyg>

2023-06-09 13:05:34

- reply

📅 Original date posted:2022-03-12
📝 Original message:
> We should remove the dust limit from Bitcoin.
Any node operator can do that. Just put "dustrelayfee=0.00000000" in your bitcoin.conf.
And there is more: you can also conditionally allow free transactions:
mintxfee=0.00000001
minrelaytxfee=0.00000000
blockmintxfee=0.00000000
Then, when using getblocktemplate you will get transactions with the highest fees first anyway, and you include cheap or free transactions in the end, if there will be enough room for them.
So, all of those settings are in the hands of node operators, there is no need to change the source code, all you need is to convince nodes to change their settings.
On 2021-08-08 20:53:28 user Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
We should remove the dust limit from Bitcoin. Five reasons:
1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart contracts
3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent dividend check in the mail)
4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.
5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers
The main reasons I'm aware of not allow dust creation is that:
1) dust is spam
2) dust fingerprinting attacks
1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by well behaved wallets to not redeem outputs that cost more in fees than they are worth.
cheers,
jeremy

2023-06-07 23:21:38

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Transactions paying "fee > sum" can be split into multiple transactions with smaller fees, but this can congest the mempool. Multiple transactions can be prepared upfront and released at once, and HD wallets can generate all addresses in-between.
📝 Original message:> confused. the rule was "cannot pay a fee > sum of outputs with consideration of cpfp in the mempool"
> your example is of someone paying a fee "< sum" which wouldn't be blocked
Every transaction paying "fee > sum" can be replaced by N transactions paying "fee <= sum", where the sum of all fees will be the same. That means, someone will still do the same thing, but it will be just expanded into N transactions, so you will reach the same outcome, but splitted into more transactions. That means, mempool will be even more congested, because for example instead of 1kB transaction with huge fee, you will see 100 such transactions with smaller fees, that will add to the same amount, but will just consume more space.
> show me how someone could move 1 btc and pay 2 btc as fees...
In the previous example, I explained how someone could move 1k sats and pay almost 1 BTC as fees. But again, assuming that you have 3 BTC, and you move 1 BTC with 2 BTC fee, that will be rejected by your rules if and only if that will be done in a single transaction. But hey, the same owner can prepare N transactions upfront, and release them all at the same time, Segwit makes it possible without worrying about malleability.
So, instead of:
3 BTC -> 1 BTC
You can see this:
3 BTC -> 2 BTC -> 1 BTC
If that second transaction will not pass CPFP, more outputs could be used:
+--------------------+--------------------+--------------------+
| 3.0 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC |
| 0.5 BTC | 0.5 BTC 0.5 BTC | 0.5 BTC |
| 0.5 BTC | 0.5 BTC +--------------------+
| +--------------------+
| 0.5 BTC | 0.5 BTC -> 0.5 BTC |
| 0.5 BTC | 0.5 BTC |
+--------------------+--------------------+
As you can see, there are four transactions, each paying 0.5 BTC fee, so the total fee is 2 BTC. However, even if you count it as CPFP, you will get 1.5 BTC in fees for the third transaction in the chain. Note that more outputs could be used, or they could be wired a bit differently, and then if you will look at the last transaction, the sum of all fees from 10 or 15 transactions in that chain, could still pass your limits, but the whole tree will exceed that. If you have 1.5 BTC limit for that 3 BTC, then you could have 20 separate chains of transactions, each paying 0.1 BTC in fees, and it will still sum up to 2 BTC.
> the only way around it is to maintain balances and use change addresses. which would force nft and timestamp users to maintain these balances and would be a deterrent
Not really, because you can prepare all of those transactions upfront, as the part of your protocol, and release all of them at once. You don't have to maintain all UTXOs in between, you can create the whole transaction tree first, sign it, and broadcast everything at once. More than that: if you have HD wallet, you only need to store a single key, and generate all addresses in-between on-the-fly, as needed. Or even use some algorithm to deterministically recreate the whole transaction tree.
On 2023-05-10 19:42:49 user Erik Aronesty <erik at q32.com> wrote:
confused. the rule was "cannot pay a fee > sum of outputs with consideration of cpfp in the mempool"
your example is of someone paying a fee "< sum" which wouldn't be blocked
note: again, i'm not a fan of this, i like the discussion of "bitcoin as money only" and using fee as a lever to do that
show me how someone could move 1 btc and pay 2 btc as fees... i think we can block it at the network or even the consensus layer, and leave anything but "non-monetary use cases" intact. the only way around it is to maintain balances and use change addresses. which would force nft and timestamp users to maintain these balances and would be a deterrent
im am much more in favor of doing something like op_ctv which allows many users to pool fees and essentially "share" a single utxo.
.
On Wed, May 10, 2023 at 12:19 PM <vjudeu at gazeta.pl> wrote:
> possible to change tx "max fee" to output amounts?
Is it possible? Yes. Should we do that? My first thought was "maybe", but after thinking more about it, I would say "no", here is why:
Starting point: 1 BTC on some output.
Current situation: A single transaction moving 0.99999000 BTC as fees, and creating 1000 satoshis as some output (I know, allowed dust values are lower and depend on address type, but let's say it is 1k sats to make things simpler).
And then, there is a room for other solutions, for example your rule, mentioned in other posts, like this one: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.html
> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
Possible situation after introducing your proposal, step-by-step:
1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC as fees. Assuming your rules are on consensus level, the first transaction creates 0.5 BTC output and 0.5 BTC fee.
2) That person still wants to move 0.5 remaining BTC, and still is willing to pay 0.49999000 BTC as fees. Guess what will happen: you will see another transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
...
N) Your proposal replaced one transaction, consuming maybe one kilobyte, with a lot of transactions, doing exactly the same, but where fees are distributed between many transactions.
Before thinking about improving that system, consider one simple thing: is it possible to avoid "max fee rule", no matter in what way it will be defined? Because as shown above, the answer seems to be "yes", because you can always replace a single transaction moving 1 BTC as fees with multiple transactions, each paying one satoshi per virtual byte, and then instead of consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC, so 100 MvB per 1 BTC mentioned in the example above.
On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
possible to change tx "max fee" to output amounts?
seems like the only use case that would support such a tx is spam/dos type stuff that satoshi warned about
its not a fix for everything, but it seems could help a bit with certain attacks

2023-06-07 23:21:38

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: The proposal to change the transaction "max fee" to output amounts may not be effective in preventing spam attacks and could lead to more transactions and higher fees.
📝 Original message:> possible to change tx "max fee" to output amounts?
Is it possible? Yes. Should we do that? My first thought was "maybe", but after thinking more about it, I would say "no", here is why:
Starting point: 1 BTC on some output.
Current situation: A single transaction moving 0.99999000 BTC as fees, and creating 1000 satoshis as some output (I know, allowed dust values are lower and depend on address type, but let's say it is 1k sats to make things simpler).
And then, there is a room for other solutions, for example your rule, mentioned in other posts, like this one: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.html
> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
Possible situation after introducing your proposal, step-by-step:
1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC as fees. Assuming your rules are on consensus level, the first transaction creates 0.5 BTC output and 0.5 BTC fee.
2) That person still wants to move 0.5 remaining BTC, and still is willing to pay 0.49999000 BTC as fees. Guess what will happen: you will see another transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
...
N) Your proposal replaced one transaction, consuming maybe one kilobyte, with a lot of transactions, doing exactly the same, but where fees are distributed between many transactions.
Before thinking about improving that system, consider one simple thing: is it possible to avoid "max fee rule", no matter in what way it will be defined? Because as shown above, the answer seems to be "yes", because you can always replace a single transaction moving 1 BTC as fees with multiple transactions, each paying one satoshi per virtual byte, and then instead of consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC, so 100 MvB per 1 BTC mentioned in the example above.
On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
possible to change tx "max fee" to output amounts?
seems like the only use case that would support such a tx is spam/dos type stuff that satoshi warned about
its not a fix for everything, but it seems could help a bit with certain attacks

2023-06-07 23:20:15

- reply

📅 Original date posted:2023-03-05
🗒️ Summary of this message: The behavior of a blockchain when the coinbase drops below the fees is unknown, but federations like RSK or additional layers like LN can provide insight. Testnet3 can also be used to test extreme cases. Even if coins are worthless, minimal fees can still be used to send data. A chain can still function with zero coins, and mining blocks with zero coinbase amount can prevent reorgs and encourage miners to spend their rewards.
📝 Original message:> I don't know of any data of what happens at the point where the coinbase drops to below the fees on any chain. I don't think there has been one where that has happened. Perhaps there is a chain out there where it is fee's only? Perhaps that can provide insight.
I think federations like RSK or additional layers like LN can be a good example of what happens if there are no additional coins. In RSK, all coins are backed by BTC, so all you have is what users deposited, or what was Merge Mined, there are no more coins than that. In LN, there are nodes, and channels are formed only with existing coins, by default there is no mining, so all fees collected by nodes are based only on LN transaction fees (there are ways to reward small miners with LN coins, for example by enabling free LN transactions for those miners, or create channels directly by using outputs of the coinbase transaction, but it is not widely used).
Also note that when it comes to other chains, we still have testnet3, where there were more halvings than on the mainnet, because of blockstorms. So, if that network will not be resetted, then I guess we will see, how that network will behave, when there will be no other coins. For now, you can see some users complaining that it is hard to get enough test coins, and with each halving you can see, how that network is getting closer and closer to the case you want to observe. So, if we want to check, how potential solutions can solve that problem, using testnet3 will give better results than signet, simply because of more halvings. Also, as testnet3 has blockstorms, it is possible to also test extreme cases with huge reorgs, and see if taking fees from other blocks will still be profitable after introducing proposed changes.
Another important thing to note is that even if coins are worthless, then still, if there are some minimal fees (like one satoshi per virtual byte), then on-chain amounts simply represents, how many data can be sent by each user. It means that users can simply send zero satoshis (if there is a need to create any additional UTXOs), and place as many coins as they can in their change addresses, and then the whole game is about having any coins, to have the right to broadcast any transaction to the network. Because then, an interesting thing to note is that if there is no coins, then the chain is not going to be halted. It is still possible to create a coinbase transaction with zero coins, and it is still used in all block-based calculations, so mining such blocks can prevent other miners from reorging older blocks, and taking those fees. And then, if you look at the last miners that had some blocks with fees, then you notice that reaching 100 confirmations can encourage them to mine blocks with zero coinbase amount, just to spend their rewards.
On 2023-03-04 18:32:01 user Andrew Melnychuk Oseen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>From my limited knowledge in the space, and I've taken opinions of people I respect that are far more knowledgeable than me.
I don't know of any data of what happens at the point where the coinbase drops to below the fees on any chain. I don't think there has been one where that has happened. Perhaps there is a chain out there where it is fee's only? Perhaps that can provide insight.
Opinion: I think as bitcoin's capabilities grow, demand for it will as well. There are a lot of efforts to increase the amount of transactions that can fit into a block. I think the combination of limited block space and a reduced amount of bitcoin's entering the market is the right combination for the system to self sustain. I'm looking forward to seeing the result!
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, March 1st, 2023 at 12:18 PM, Giuseppe B via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Hello everyone,
I'm relatively new here so what I'm proposing could have already been discussed, or may be flawed or inapplicable. I apologize for that.
I was picturing a situation where block rewards are almost zero, and the base layer is mainly used as a settlement layer for relatively few large transactions, since the majority of smaller ones goes through LN.
In such a case it may very well be that even if transaction amounts are very consistent, transaction fees end up being very small since there is enough space for everyone in a block. Users wouldn't mind paying higher fees as they know that that would increase the network security, however nobody wants to be the only one doing that. Miners would of course like being paid more. So everyone involved would prefer higher fees but they just stay low because that's the only rational individual choice.
Therefore I was imagining the introduction of a new protocol rule, min_fees, that would work like this:
- the miner that gets to mine a block appends a min_fee field to the block, specifying the minimum fees that need to be contained in the following block in order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the chain getting stuck.
min_fees could either represent the total fees of the following block, or the minimal fee for each single transaction, as a percentage of the value transacted. Both seem to have some merits and some potential drawbacks. Of course min_fees=0 would correspond to the current situation.
It looks to me that this could have the potential to bring the equilibrium closer to a socially optimal one (as opposed to individually optimal), and to benefit the network security in the long term. Of course it's just a rough sketch and it would deserve a much deeper analysis. I was just interested in knowing if you think that the principle has some merit or if it's not even worth discussing it for some reason that I'm not considering.
Cheers,
Giuseppe.

2023-06-07 23:19:35

- reply

📅 Original date posted:2023-02-18
🗒️ Summary of this message: To fight spam, a solution is needed to prune large NOPs in the chain. One possible solution is to store the first and last chunk of data in a hash function like SHA-256 and keep the internal state before entering the last chunk. This could allow for pruning of unused parts without invalidating signatures. However, banning specific script fragments may not be effective as spammers can use alternative methods.
📝 Original message:> By standardness rules (where you can have up to 80-byte pushes), a little over 1%. By consensus (520-byte pushes) less than 0.2%.
Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the number of dropping opcodes could be halved.
> I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript.
That means people can still reject an official alternative (for example commitments), so a different approach is needed to fight that spam. Assuming that transactions will be sent directly to the miners, they will be included, that way or another. So, the solution should assume that we will have large NOPs in the chain. And then, if we want to deal with them, some kind of pruning is needed. Switching from witness to non-witness node is not an option, because it would require additional witness validation, and because rules for OP_RETURN can be also lifted.
So, how to prune the Script? In a typical hash function, like SHA-256, data are splitted into smaller chunks, and then processed linearly. I think it is possible to store the first and the last chunk, and keep the internal state of SHA-256, before entering the last chunk. In this way, it should be possible to prune those OP_NOPs. Because that solution will also cover raw scripts (people can switch to them if witness will be more restricted than now).
Also, it gives us a hint, that if any Script upgrade will be considered in the future, we can think about doing it in a way, where unused parts can be pruned, without invalidating signatures.
On 2023-02-18 00:39:16 user Andrew Poelstra <apoelstra at wpsoftware.net> wrote:
> On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> If you ban any of these specific script fragments then spammers will
> just use `IF <anything> ENDIF` and provide the `FALSE` as a zero push.
> And banning *this* would ban legitimate use cases.
>
I realize this is confusingly worded. I mean, they'd provide the `FALSE`
as a separate witness element rather than being part of the witnessScript.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster

2023-06-07 23:19:34

- reply

📅 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

2023-06-07 23:12:50

- reply

📅 Original date posted:2022-08-19
📝 Original message:> If we actually wanted to solve the potential problem of not-enough-fees to upkeep mining security, there are less temporary ways to solve that. For example, if fees end up not being able to support sufficient mining, we could add emission based on a constant fraction of fees in the block. For example, every block could emit new bitcoin amounting to 10% of the fees collected in that block. This would tie coinbase rewards to the real world (since the fee market is tied to the real economy) and ensure higher block revenue indefinitely - ie not just for another 50 years.
Miners can game this system by moving their own coins in 100% fees transactions, just to produce more coins. You have one million BTC? No problem, just move them as fees, and you just created 100k BTC out of thin air, just because you are a wealthy miner. And even if that amount will be stolen, when some other miner will reorg your block, then still, miners will keep creating coins by moving them as fees, and the strongest miner will get the whole pot. And guess what: 100 blocks later you can reuse newly created 100k BTC to make another 10k BTC, so it will exponentially explode as (amountOfCoins*(1+0.1))^n function. And guess what: (1.1)^8 is 2.14358881. That means, after eight moves, you can double your coins, if you are a wealthy miner. And you can start with smaller amounts, to play it safe, but eventually, this system will degrade into "coin doubler after 800 blocks" or something similar.
On 2022-08-18 18:45:43 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
While constant tail emission does in fact converge to 0 inflation over time (which bitcoin's halvings do as well mind you), tail emission does *not* solve the potential problem of mining rewards, it only delays it. A tail emission of 200,000 btc/year (~1% of the current supply) would be equivalent to halvings every ~50 years rather than every 4 years. Were we to implement this kind of thing right after the last non-" destructive" halving, it would buy us 46 years of extra time. Nothing more, nothing less.
While its mildly interesting to know that tail emission converges to a stable point, while no inflation implies monetary deflation at the rate of loss, this feels very likely to be an insignificant problem. I think 1% loss rate per year is an absurdly high estimate these days, and the loss rate is likely to decrease as methods of storing bitcoin mature. Imagine bitcoin was worth $1 trillion (not so hard, since it was not too long ago), then try imagining people losing $10 billion of bitcoin every year. Highly unlikely IMO. A rate of loss of 0.01%/year might be more realistic for a near-future mature bitcoin. That's not going to be enough to make a significant difference even over 100s of years.
If we actually wanted to solve the potential problem of not-enough-fees to upkeep mining security, there are less temporary ways to solve that. For example, if fees end up not being able to support sufficient mining, we could add emission based on a constant fraction of fees in the block. For example, every block could emit new bitcoin amounting to 10% of the fees collected in that block. This would tie coinbase rewards to the real world (since the fee market is tied to the real economy) and ensure higher block revenue indefinitely - ie not just for another 50 years.
But its also worth saying that blockchain security (which mining revenue correlates with) does *not* need to increase indefinitely. There is some amount of security (and therefore some amount of mining revenue) that is sufficient, beyond which additional security is simply unnecessary, unwarranted, and wasteful (you wouldn't buy a $1000 safe to store $1000 of valuables). Do we, as the bitcoin community, have some good idea how much security we need? Do we have some idea how costly a 51% attack must be where we can be comfortable it will never happen? I'm curious to hear what people think about that. Because without having some kind of estimates of what "enough security" is, there's absolutely no way of evaluating whether or not its likely that bitcoin fees alone will be able to sustain enough security.
On Wed, Aug 17, 2022 at 9:31 AM Jaroslaw via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
On one scale you puts the Trust to the large stakeholders (why we avoid plenty of small stakeholders, btw),
and on the other side I put game theory and well defined Prisoner's Dilemma.
Again: large stakeholders WILL NOT incentivised to mine, they will have the hundreds excuses why not to switch-on Antminers back.
That's how it simply works. Bitcoin would fail miserably if Satoshi was based his concept mainly on existence of idealists.
If we will observe lack of hashrate recovery four years after some halving and still unprepared like today
- means the trust in large stakeholders was a very costly mistake.
Superiority of Proof of Work against Proof of Stake has been discussed enough either
The overall conclusion with what I fully agree is: swapping PoW to PoS - would be a degradation.
You can stop talking about degradation to proof of stake, but just: degradation.
Degradation of Bitcoin, due to human greed.
Now you mine and you have an INSTANT gratification.
Then you will mine and it will cost you real money, but simple switch - and you have a DELAYED, maybe some day in the future, maybe only a tiny - punishment.
And The Punishment Won't Be Tiny.
"If the pain after hitting the hand with a hammer would appear after a month - people would notoriously walk with swollen fingers"
100% (^2)
Regards
Jaroslaw
W dniu 2022-08-17 13:10:38 użytkownik Erik Aronesty <erik at q32.com> napisał:
> you can stop talking about the "security of the system" as meaningful
> this has been discussed enough
> if fees are not sufficient, clearance times increase and large stakeholders are incentivised to mine
> in the best case, fees are sufficient
> in the worst case, it degrades to proof of stake
> i'm sure you can see how that's fine either way
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:12:38

- reply

📅 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

2023-06-07 23:12:37

- reply

📅 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

2023-06-07 23:12:22

- reply

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

2023-06-07 23:12:11

- reply

📅 Original date posted:2022-07-27
📝 Original message:> It's pointless for individual nodes to make changes like this on their own.
It's pointless only if you assume that mining is centralized. And it's pointless if you also assume that there is no batching. By using different sighashes, batching is definitely possible. In case of one-input-one-output transactions, they should use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then it is possible to grab a lot of such transactions, and combine them all into a single transaction, saving some bytes, so fees for each user can be lower than one satoshi per virtual byte, when it is counted in non-batched version. In general, it should be possible to use SIGHASH_ANYONECANPAY by default, and use SIGHASH_PREVOUT_SOMETHING to make signatures from next transactions resistant to changes like adding more inputs and outputs.
> The only time those settings are useful is special situations like miners who want to push txs to their own memlools.
So they could be more useful, if it would be possible to mine a block with lower than required difficulty (a share), and be rewarded for that in P2P way. So, if some miner collected 7 BTC as a reward (6.25 BTC plus 0.75 BTC in fees), then if that miner created 100 times easier block than needed, it should be rewarded with 0.07 BTC in a P2P way. And if block rewards are based on fees, then it makes perfect sense to collect for example 0.07 BTC in transaction fees, and mine it, leaving the rest for other miners, then they will have an incentive to build on top of that.
On 2022-07-27 14:18:21 user Peter Todd <pete at petertodd.org> wrote:
>
On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> So I'd suggest removing the fixed dust limit entirely and relying purely on the mempool size limit to determine what is or is not dust.
>
>Just use those settings in your node:
>
>minrelaytxfee=0.00000000
>blockmintxfee=0.00000000
>dustrelayfee=0.00000000
>
>No changes in source code are needed, nodes can change their limits without asking anyone. And if some node is a miner, then it can be enforced. But if not, then still, free transactions are useful for communication (if more of them will be accepted, then we will switch to negative fee transactions with proper sighashes, then it will be very unlikely that miners will voluntarily add coins, so it will remain useful for communication).
It's pointless for individual nodes to make changes like this on their own. Without like-minded peers this achieves nothing. What is relevant is network wide defaults.
The only time those settings are useful is special situations like miners who want to push txs to their own memlools. For the _vast_ majority of users changing defaults achieves absolutely nothing.

2023-06-07 23:12:10

- reply

📅 Original date posted:2022-07-27
📝 Original message:> So I'd suggest removing the fixed dust limit entirely and relying purely on the mempool size limit to determine what is or is not dust.
Just use those settings in your node:
minrelaytxfee=0.00000000
blockmintxfee=0.00000000
dustrelayfee=0.00000000
No changes in source code are needed, nodes can change their limits without asking anyone. And if some node is a miner, then it can be enforced. But if not, then still, free transactions are useful for communication (if more of them will be accepted, then we will switch to negative fee transactions with proper sighashes, then it will be very unlikely that miners will voluntarily add coins, so it will remain useful for communication).
On 2022-07-26 14:45:35 user Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev wrote:
> I know this might be a sort of repetition for a previous question, but I do
> want to know from enthusiasts in this group that while Bitcoin was trading
> at much lower price in its early days, 1 sat/vB was a good dust protection
> measure. But now, I think it's a bit high for merely a dust protection
> measure, and should be lowered slightly. Even if not, it should be lowered
> to half when prices go double than today and keeps oscillating at that
> point. As it's not a consensus rule, I think it can be done easily, just
> needing support from full node operators. I support LN but I think
> transaction affordability should remain constant in the future. If I'm okay
> to wait in a queue, I should have the option for same affordability for
> minimum fees in the future as it is today. (Like we still have posts today
> while email still exists).
If we're expecting fee revenue to be significant in the future - with constant
backlogs of low-fee txs - lowering the dust limit now is a good way to ensure
the entire ecosystem is ready to deal with those conditions. We're fairly close
to blocks being full, so you can't argue that the dust limit provides value by
reducing block usage. All it achieves is artificially lowering mempool usage,
putting the Bitcoin system in a no-backlog state that's quite unlike how we're
expecting Bitcoin to operate in the future. And indeed, the state Bitcoin can
operate in at any moment if there is a demand spike.
So I'd suggest removing the fixed dust limit entirely and relying purely on the
mempool size limit to determine what is or is not dust.
--
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

2023-06-07 23:11:52

- reply

📅 Original date posted:2022-07-15
📝 Original message:> Unsure how this solves or relates to the smoothing of block rewards. Let me know if I misunderstood.
This example shows clearly that even if tail supply supporters will win, then no matter how they will introduce new coins to the system, we can still resist that attack by burning those coins, or by locking them in some endless loop, to make it compatible with their malicious soft-fork (because I don't think the community will agree on some hard-fork, when none is needed).
And when it comes to smoothing rewards, then if you decide, that for example any miner can take only 0.01 BTC, and the rest should be timelocked to the future blocks, then it will make block rewards more smooth. So, when it comes to making fees more smooth, it is only a matter of choosing the right amount, that miners can agree to introduce (because reducing 6.25 BTC plus fees into 0.01 BTC now, and getting a promise that the block reward will never go below 0.01 BTC, is not something they are likely to support, so different amounts should be chosen).
On 2022-07-14 18:34:24 user Manuel Costa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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".
My understanding of this is that it would basically remove 0.01 BTC rewards from the next 210k blocks, and then do nothing.
After 210k blocks have passed, you're just rolling it forward, taking from the anyone can spend output and locking it in a new one for 210k blocks from now.
You're basically just using the next 210k block's reward to create a stash of forever locked coins in a loop.
Unsure how this solves or relates to the smoothing of block rewards. Let me know if I misunderstood.
Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> escreveu no dia quinta, 14/07/2022 à(s) 13:18:
This is not an argument in line with bitcoin values, on that scenario only rich people will be able to mine and participate to the consensus process.
Like George Soros today, he use its financial reserves to monopolize ONG in order to manipulate nation states. I would not define this a "tax", moreover a cost to maintain control over the network.
Those rich holders could crate a cartel and without market dynamics all game theory stop to work and the bitcoin network value drop.
We should think about how to maximise the network value instead of trying to preserve it with corruptible practices outside of market dynamics principles.
On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, <bitcoin-dev at lists.linuxfoundation.org> wrote:
Fees and miner rewards are not needed at all for security at all since long term holders can simply invest in mining to secure the value of their stake.
Isn't it enough that the protocol has a mechanism to secure value?
Sure fees *might* be enough.
But in the event that they are not, large holders can burn a bit to make sure the hashrate stays high.
I know, I know it's a tax on the rich and it's not fair because smaller holders are less likely to do it, but it's a miniscule tax even in the worst case
On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:11:48

- reply

📅 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

2023-06-07 23:11:40

- reply

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

2023-06-07 23:11:31

- reply

📅 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

2023-06-07 23:11:28

- reply

📅 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

2023-06-07 23:11:16

- reply

📅 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

2023-06-07 23:11:05

- reply

📅 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

2023-06-07 23:10:56

- reply

📅 Original date posted:2022-07-07
📝 Original message:> The primary mechanism we have to change how much security we have is to change the block size, which changes how much fees miners can collect each block. This isn't a linear thing. Its probably a parabola with a peak, where at that peak, making the block either smaller and larger would both reduce total fees paid. This is because when blocksize is higher, more transactions (and thus more fees) can be collected, but at the same time average fees will be lower. The pull of those two forces should define that parabola.
I think it would be better to allow transaction joining, and lock some coins to the future block numbers in case of peaks, to make fees more smoothly, like it is in RSK. So, if there is 0.01 BTC fee for some transaction, it does not matter if that is paid by some single user, or by a million users, one satoshi each, that comes on-chain as a single transaction to serve all of them.
> Transaction fees kind of have an association with market value.
They will be more important in the future, because when all coins will be mined, then miners will earn nothing, if there will be no on-chain transactions. On the other hand, people will switch to other networks, if on-chain fees will be too high. So, I think the market should adjust fees, and finding the right balance between on-chain and off-chain should be left to the users, just by providing them options like transaction joining. I think such features will be created anyway, if not supported directly, then they will come as no-forks, and if that won't succeed, then I expect some centralized websites will start doing that anyway.
On 2022-07-07 02:46:29 user Billy Tetrud <billy.tetrud at gmail.com> wrote:
@Corey
> Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists.
I basically agree with this. The pedantic part of my mind does want to point out that the link between block subsidy and bitcoin's price does actually give somewhat of a feedback loop, in that the higher the price, the more valuable bitcoin is as a whole (at least as viewed by the active market), and therefore the more investment in security is appropriate. However, in the long run when the subsidy reduces to insignificance, we basically lose this link. And even with this link, it's not very direct. Fees retain only a little bit of this behavior, because presumably a more valuable bitcoin is more valuable to spend, but the link to security is very tenuous there.
> 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 that uses a framework for thinking about how much security bitcoin might need. The concept is that we should figure out what bitcoin's bottlenecks are, and figure out the minimum requirements we want to place on running a node based on how many (public) nodes we think we need and what percentage of machines out there are likely to run a node. The goals I chose to explore in that paper are totally up for debate, and I think its an important debate to have. But they are basically a first stab at setting up what we would need to determine optimum security. I would very much appreciate your review of that part of the paper, Corey.
> Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project.
My thoughts on this are that we will need to periodically make some software change to adjust a *target amount of investment in security*, because the components of bitcoin's blockchain security are not all predictable. Many unpredictable things factor into bitcoin's security (eg miner behavior, pools, how many people generally run public nodes on their own, what features require running public nodes, value of bitcoin, etc.
The primary mechanism we have to change how much security we have is to change the block size, which changes how much fees miners can collect each block. This isn't a linear thing. Its probably a parabola with a peak, where at that peak, making the block either smaller and larger would both reduce total fees paid. This is because when blocksize is higher, more transactions (and thus more fees) can be collected, but at the same time average fees will be lower. The pull of those two forces should define that parabola.
So my suggestion here would be that we should target a certain amount of security and have programmatic adjustments to the block size in order to stay near enough to the parabolic maximum so that we pay miners enough to give us sufficient blockchain security. Conversely, it should also attempt to minimize how much "extra" security we pay for. It would be wasteful to pay 3 times as much for 3 times the security we actually need. Such a thing is a very real form of devaluation that basically represents a tax on bitcoin and users of bitcoin. And its very possible for the position of this parabola to change over time. We could never say with certainty whether we're on one side of the parabola's maximum or the other. This would make it rather complex to track well.
Additionally, there's no clear trustless way to determine the market value of bitcoin at any given time, which makes it difficult to maintain this target over time. As the market value of bitcoin changes, that target could become quite inaccurate. This implies that we would need to do periodic adjustments to the target, either through periodic forks or through some other mechanism for changing the target.
If there were a good trustless way to determine the market value of bitcoin, we would have to "manually" change this target potentially much less often. Transaction fees kind of have an association with market value. Perhaps some kind of analysis can be done on that to make a reasonable prediction of what market value is based on fees. Or maybe blocks can commit to a market price similarly to how they commit to a timestamp (which is also only verifiable to an approximation and can only be verified close to when it was mined but not eg years later).
On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders.
So, Paul Sztorc was right again, there are three options: Enormous Block Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I think using Merged Mining is the best option. More about that: https://www.truthcoin.info/blog/security-budget-ii-mm/
> Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient.
Yes, that's also possible, RSK uses that. And making some kind of soft-fork for that is also possible, but I don't know if miners will agree to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE".
On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store >of value (and not as a currency), I don't think it's worth questioning it at this point.
>
>Just my 2 sats.
>
>Giuseppe.
A finite supply alone is not enough to give something value, as it must also be useful in some way. In the case of Bitcoin, various forms of cryptographic security must all work - and work together - to make Bitcoin useful. If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders.
There will always be competitive pressures with respect to efficiency, and both being over-secured and under-secured would be economically inefficient for a crypto currency, and thereby laving room for a more optimally-secured competitor to gain ground. Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. There is also zero agreement on how much security would constitute such an optimum. Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project.
Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Anthony Towns presented a form of this concept in greater detail at a Scaling Bitcoin conference some years ago. While this solution, if employed, would only work for some finite amount of time, it is possible that could give additional decades before the accumulated security budget was exhausted.
Corey
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:10:55

- reply

📅 Original date posted:2022-07-06
📝 Original message:> If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders.
So, Paul Sztorc was right again, there are three options: Enormous Block Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I think using Merged Mining is the best option. More about that: https://www.truthcoin.info/blog/security-budget-ii-mm/
> Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient.
Yes, that's also possible, RSK uses that. And making some kind of soft-fork for that is also possible, but I don't know if miners will agree to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE".
On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store >of value (and not as a currency), I don't think it's worth questioning it at this point.
>
>Just my 2 sats.
>
>Giuseppe.
A finite supply alone is not enough to give something value, as it must also be useful in some way. In the case of Bitcoin, various forms of cryptographic security must all work - and work together - to make Bitcoin useful. If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders.
There will always be competitive pressures with respect to efficiency, and both being over-secured and under-secured would be economically inefficient for a crypto currency, and thereby laving room for a more optimally-secured competitor to gain ground. Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. There is also zero agreement on how much security would constitute such an optimum. Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project.
Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Anthony Towns presented a form of this concept in greater detail at a Scaling Bitcoin conference some years ago. While this solution, if employed, would only work for some finite amount of time, it is possible that could give additional decades before the accumulated security budget was exhausted.
Corey

2023-06-07 23:10:52

- reply

📅 Original date posted:2022-07-03
📝 Original message:> Have you seen the inherited ID proposal from John Law on this list?
I didn't see that before posting, I'm still trying to get more familiar with that (and with proposals, where every single field in each transaction is controlled for inclusion or exclusion).
> Honestly, I've yet to fully load in exactly how the applications of it work, but I'd be interested to hear your thoughts.
The main use case is to control transaction flow. If you have everything signed with SIGHASH_ALL, then it is obvious that you can just use txid, and everything works. But on the other hand, if you use other sighashes, for example SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then you should be able to make a new transaction spending your signed output, no matter which inputs and outputs will be added to the previous one. And that's why SIGHASH_PREVOUT_SOMETHING is needed, to control, which parts of the previous transaction are signed, and which are not. And to do that, it is needed to take the previous transaction, referenced by txid, and to modify it, based on provided SIGHASH_PREVOUT_SOMETHING sighashes.
To push things one step further, I think different sighashes should be proposed by default, that would make users more familiar with the whole concept of sighashes. Because now, the default behavior is to sign everything with SIGHASH_ALL. I think it should be changed, the Core client should propose different sighashes, based on created transaction, just to allow transaction joining. To start with, it could be just a simple checkbox "allow transaction joining", that would enable it, to see if it will be simple enough for most users.
SIGHASH_ANYONECANPAY - used for every input (because it allows fee bumping without changing signatures)
SIGHASH_SINGLE - used only when there is any corresponding output, and only when it has higher or equal amount than the corresponding input
SIGHASH_ALL - used when there is no corresponding output, or when the corresponding output is smaller, to prevent detaching it
In general, I think the transaction should be displayed like it is visible in many block explorers, and after clicking each input, users should see, what is signed, and what is not, so they should control sighashes in a similar user interface, as they use to choose coins. Inputs and outputs should be grayed or highlighted, based on sighashes selected by user, to allow understanding them better.
On 2022-05-07 13:55:48 user Jeremy Rubin <jeremy.l.rubin at gmail.com> wrote:
Have you seen the inherited ID proposal from John Law on this list?
It's a pretty thorough treatment of this type of proposal, curious if you think it overlaps what you had in mind?
Honestly, I've yet to fully load in exactly how the applications of it work, but I'd be interested to hear your thoughts.
On Sat, May 7, 2022, 4:55 AM vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
For now, we have txid:vout as a previous transaction output. This means that to have a stable TXID, we are forced to use SIGHASH_ALL somewhere, just to prevent any transaction modifications that can happen during adding some inputs and outputs. But it seems that new sighashes could be far more powerful than we expected: it is technically possible to not only remove previous transaction output by using SIGHASH_ANYPREVOUT. We can do more and do it better, we could decide, how to calculate this txid at all!
So, something like SIGHASH_PREVOUT_NONE would be similar to SIGHASH_NONE (applied to the previous transaction, taken from txid). To have SIGHASH_ANYPREVOUT, we need to remove absolutely everything, I don't know any such sighashes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will commit at least to some fields, for example to the locktime. But, if we introduce SIGHASH_PREVOUT_XYZ flags for all existing sighashes, we would have this:
SIGHASH_PREVOUT_NONE
SIGHASH_PREVOUT_SINGLE
SIGHASH_PREVOUT_ALL
SIGHASH_PREVOUT_ANYONECANPAY
Then, the procedure is as follows: we use txid:vout to find our previous transaction. Then, we apply those sighashes to this previous transaction, to form a new txid, that will be checked during every OP_CHECKSIG-based opcode. In this way, our txid:vout is used just to do transaction lookup, after that, sighashes can be applied to the previous transaction, so our txid could remain stable, even if someone will add some inputs and outputs.
By default, we could use SIGHASH_PREVOUT_ALL, that would mean our txid:vout remains unchanged. Then, SIGHASH_PREVOUT_SINGLE would obviously mean, that we want to commit only to this particular previous transaction output. That would allow adding any new outputs to the previous transaction, without affecting our replaced txid, but also without blindly accepting any txid, because some data of the previous transaction would be still hashed.
Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean that no outputs of the previous transaction are checked. But still, the inputs will be! That would mean: "I don't care about in-between addresses, but I care that it was initiated from these inputs". In this case, it is possible to choose some input without those flags, and then apply SIGHASH_PREVOUT_NONE many times, to make sure that everything started from that input, but everything in-between can be anything.
All of those three SIGHASH_PREVOUT_XYZ flags could be combined with SIGHASH_PREVOUT_ANYONECANPAY. That would mean all inputs of the previous transaction are discarded, except from the input number matching "vout". Or we could just use SIGHASH_PREVOUT_ANY instead and discard all inputs from that previous transaction, that could also be combined with other sighashes.
So, to sum up, by applying sighashes to the previous transaction, instead of allowing for any transaction, we could still have some control of our txid, and I think it could be better than just saying "give me any txid, I will accept that". I think in most cases we don't want to allow any txid: we want to only "control the flow", just to make sure that our signatures will sign what we want and will not be invalidated by changing some transaction inputs and outputs, unrelated to the currently-checked signature.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:10:15

- reply

📅 Original date posted:2022-06-04
📝 Original message:Some people think that sidechains are good. But to put them into some working solution, people think that some kind of soft-fork is needed. However, it seems that it can be done in a no-fork way, here is how to make it permissionless, and introduce them without any forks.
First, we should make a new chain that has zero coins. When the coin supply is zero, it can be guaranteed that this chain is not generating any coins out of thin air. Then, all that is needed, is to introduce coins to this chain, just by signing a transaction from other chains, for example Bitcoin. In this way, people can make signatures in a signet way, just to sign their transaction output of any type, without moving real coins on the original chain.
Then, all that is needed, is to make a way to withdraw the coins. It could be done by publishing the transaction from the original chain. It can be copy-pasted to our chain, and can be used to destroy coins that were produced earlier. In this way, our Merge-Mined chain has zero supply, and can only temporary store some coins from other chains.
Creating and destroying coins from other chains is enough to make a test network. To make it independent, one more thing is needed, to get a mainnet solution: moving coins inside that chain. When it comes to that, the only limitation is the locking script. Normally, it is locked to some public key, then by forming a signature, it is possible to move coins somewhere else. In the Lightning Network, it is solved by forming 2-of-2 multisig, then coins can be moved by changing closing transactions.
But there is another option: transaction joining. So, if we have a chain of transactions: A->B->C->...->Z, then if transaction joining is possible, it can be transformed into A->Z transaction. After adding that missing piece, sidechains can be enabled.
However, I mentioned before that this solution would require no forks. It could, if we consider using Homomorphic Encryption. Then, it is possible to add new features, without touching consensus. For example, by using Homomorphic Encryption, it is possible to execute 2-of-2 multisig on some P2PK output. That means, more things are possible, because if we can encrypt things, then operate on encrypted data, and later decrypt it (and broadcast to the network), then it can open a lot of new possible upgrades, that will be totally permissionless and unstoppable.
So, to sum up: by adding transaction joining in a homomorphic-encryption-way, it may be possible to introduce sidechains in a no-fork way, no matter if people wants that or not. Also, it is possible to add the hash of our chain to the signature inside a Bitcoin transaction, then all data from the "zero supply chain" can be committed to the Bitcoin blockchain, that would prevent overwriting history. Also, Merged Mining could be used to reward sidechain miners, so they will be rewarded inside the sidechain.

2023-06-07 23:09:28

- reply

📅 Original date posted:2022-05-07
📝 Original message:For now, we have txid:vout as a previous transaction output. This means that to have a stable TXID, we are forced to use SIGHASH_ALL somewhere, just to prevent any transaction modifications that can happen during adding some inputs and outputs. But it seems that new sighashes could be far more powerful than we expected: it is technically possible to not only remove previous transaction output by using SIGHASH_ANYPREVOUT. We can do more and do it better, we could decide, how to calculate this txid at all!
So, something like SIGHASH_PREVOUT_NONE would be similar to SIGHASH_NONE (applied to the previous transaction, taken from txid). To have SIGHASH_ANYPREVOUT, we need to remove absolutely everything, I don't know any such sighashes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will commit at least to some fields, for example to the locktime. But, if we introduce SIGHASH_PREVOUT_XYZ flags for all existing sighashes, we would have this:
SIGHASH_PREVOUT_NONE
SIGHASH_PREVOUT_SINGLE
SIGHASH_PREVOUT_ALL
SIGHASH_PREVOUT_ANYONECANPAY
Then, the procedure is as follows: we use txid:vout to find our previous transaction. Then, we apply those sighashes to this previous transaction, to form a new txid, that will be checked during every OP_CHECKSIG-based opcode. In this way, our txid:vout is used just to do transaction lookup, after that, sighashes can be applied to the previous transaction, so our txid could remain stable, even if someone will add some inputs and outputs.
By default, we could use SIGHASH_PREVOUT_ALL, that would mean our txid:vout remains unchanged. Then, SIGHASH_PREVOUT_SINGLE would obviously mean, that we want to commit only to this particular previous transaction output. That would allow adding any new outputs to the previous transaction, without affecting our replaced txid, but also without blindly accepting any txid, because some data of the previous transaction would be still hashed.
Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean that no outputs of the previous transaction are checked. But still, the inputs will be! That would mean: "I don't care about in-between addresses, but I care that it was initiated from these inputs". In this case, it is possible to choose some input without those flags, and then apply SIGHASH_PREVOUT_NONE many times, to make sure that everything started from that input, but everything in-between can be anything.
All of those three SIGHASH_PREVOUT_XYZ flags could be combined with SIGHASH_PREVOUT_ANYONECANPAY. That would mean all inputs of the previous transaction are discarded, except from the input number matching "vout". Or we could just use SIGHASH_PREVOUT_ANY instead and discard all inputs from that previous transaction, that could also be combined with other sighashes.
So, to sum up, by applying sighashes to the previous transaction, instead of allowing for any transaction, we could still have some control of our txid, and I think it could be better than just saying "give me any txid, I will accept that". I think in most cases we don't want to allow any txid: we want to only "control the flow", just to make sure that our signatures will sign what we want and will not be invalidated by changing some transaction inputs and outputs, unrelated to the currently-checked signature.

2023-06-07 23:09:19

- reply

📅 Original date posted:2022-05-11
📝 Original message:> Looks like `OP_CAT` is not getting enabled until after we are reasonably sure that recursive covenants are not really unsafe.
Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT. Then, we could have OP_SPLIT <n> <pos1> <pos2> ... <posN> that would split a string N times (so there will be N+1 pieces). Or we could have just OP_SPLIT <pos> to split one string into two. Or maybe OP_2SPLIT and OP_3SPLIT, just to split into two or three pieces (as we have OP_2DUP and OP_3DUP). I think OP_SUBSTR or OP_SPLIT is better than OP_CAT, because then things always get smaller and we can be always sure that we will have one byte as the smallest unit in our Script.
On 2022-05-08 04:20:19 user ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning shesek,
> On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > * Even ***with*** `OP_CAT`, the following will enable non-recursive covenants without enabling recursive covenants:
> > * `OP_CTV`, ...
> > * With `OP_CAT`, the following would enable recursive covenants:
> > * `OP_CHECKSIGFROMSTACK`, ...
>
> Why does CTV+CAT not enable recursive covenants while CSFS+CAT does?
>
> CTV+CAT lets you similarly assert against the outputs and verify that they match some dynamically constructed script.
>
> Is it because CTV does not let you have a verified copy of the input's prevout scriptPubKey on the stack [0], while with OP_CSFS you can because the signature hash covers it?
>
> But you don't actually need this for recursion. Instead of having the user supply the script in the witness stack and verifying it against the input to obtain the quine, the script can simply contain a copy of itself as an initial push (minus this push). You can then reconstruct the full script quine using OP_CAT, as a PUSH(<script>) followed by the literal <script>.
<OP_PUSH_length-of-script> OP_SWAP OP_DUP OP_CAT OP_CAT <rest of script...>
Ha, yes, looks like you are correct here.
`OP_CAT` makes *all* covenant opcodes recursive, because you can always quine using `OP_CAT`.
By itself it does not make recursive covenants, but with probably any opcode it would.
Looks like `OP_CAT` is not getting enabled until after we are reasonably sure that recursive covenants are not really unsafe.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:09:16

- reply

📅 Original date posted:2022-05-11
📝 Original message:> This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 + 0.00073 = 0.00147) which is more than output amount 0.001 tBTC
It was created without the second input, see: https://bitcointalk.org/index.php?topic=5390103.msg59616324#msg59616324
I didn't touch that later, the signatures are the same. Some user named coinlatte just completed it: https://bitcointalk.org/index.php?topic=5390103.msg60029953#msg60029953
On 2022-05-11 17:25:41 user alicexbt <alicexbt at protonmail.com> wrote:
Hi vjudeu,
It can be changed by using different sighashes, for example, it is possible to create a "negative fee transaction", where all transaction costs are paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount in outputs than inputs is enough to do that, see testnet3 transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.
This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 + 0.00073 = 0.00147) which is more than output amount 0.001 tBTC
/dev/fd0
Sent with ProtonMail secure email.
------- Original Message -------
On Saturday, May 7th, 2022 at 9:22 AM, vjudeu via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a new OP_CAT2 that does the same would be a softfork.
We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means "anyone can move those coins", so adding some restrictions is all we need to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless it will be totally different, but then it should not be named as OP_CAT2, but rather as OP_SOMETHING_ELSE, it depends how different it will be from OP_CAT.
OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT ...
So we can use OP_SUBSTR instead. Maybe even OP_SPLIT will be enough, if data expansion is the only problem, then we can focus on getting it smaller. Or better, we could use OP_FIND that would return true/false answer if element A is a part of element B, when we do byte-to-byte comparison. In general, we can use many different string-based functions to do the same things, we can choose something that will not exponentially explode as OP_CAT.
It was considered unfair that the sender is paying for the security of the receiver.
It can be changed by using different sighashes, for example, it is possible to create a "negative fee transaction", where all transaction costs are paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount in outputs than inputs is enough to do that, see testnet3 transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.
On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
Good morning Jorge,
OP_CAT was removed. If I remember correctly, some speculated that perhaps it was removed because it could allow covenants.I don't remember any technical concern about the OP besides enabling covenants.Before it was a common opinion that covenants shouldn't be enabled in bitcoin because, despite having good use case, there are some nasty attacks that are enabled with them too. These days it seems the opinion of the benefits being worth the dangers is quite generalized. Which is quite understandable given that more use cases have been thought since then.
I think the more accurate reason for why it was removed is because the following SCRIPT of N size would lead to 2^N memory usage:
OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT ...
In particular it was removed at about the same time as OP_MUL, which has similar behavior (consider that multiplying two 32-bit numbers results in a 64-bit number, similar to OP_CATting a vector to itself).
OP_CAT was removed long before covenants were even expressed as a possibility.
Covenants were first expressed as a possibility, I believe, during discussions around P2SH.
Basically, at the time, the problem was this:
* Some receivers wanted to use k-of-n multisignature for improved security.
* The only way to implement this, pre-P2SH, was by putting in the scriptPubKey all the public keys.
* The sender is the one paying for the size of the scriptPubKey.
* It was considered unfair that the sender is paying for the security of the receiver.
Thus, OP_EVAL and the P2SH concept was conceived.
Instead of the scriptPubKey containing the k-of-n multisignature, you create a separate script containing the public keys, then hash it, and the scriptPubKey would contain the hash of the script.
By symmetry with the P2PKH template:
OP_DUP OP_HASH160 <hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIG
The P2SH template would be:
OP_DUP OP_HASH160 <hash160(redeemScript)> OP_EQUALVERIFY OP_EVAL
OP_EVAL would take the stack top vector and treat it as a Bitcoin SCRIPT.
It was then pointed out that OP_EVAL could be used to create recursive SCRIPTs by quining using OP_CAT.
OP_CAT was already disabled by then, but people were talking about re-enabling it somehow by restricting the output size of OP_CAT to limit the O(2^N) behavior.
Thus, since then, OP_CAT has been associated with recursive covenants (and people are now reluctant to re-enable it even with a limit on its output size, because recursive covenants).
In particular, OP_CAT in combination with OP_CHECKSIGFROMSTACK and OP_CHECKSIG, you could get a deferred OP_EVAL and then use OP_CAT too to quine.
Because of those concerns, the modern P2SH is now "just a template" with an implicit OP_EVAL of the redeemScript, but without any OP_EVAL being actually enabled.
(OP_EVAL cannot replace an OP_NOP in a softfork, but it is helpful to remember that P2SH was pretty much what codified the difference between softfork and hardfork, and the community at the time was small enough (or so it seemed) that a hardfork might not have been disruptive.)
Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a new OP_CAT2 that does the same would be a softfork.
If you are willing to work in Taproot the same OP-code can be enabled in a softfork by using a new Tapscript version.
If you worry about quantum-computing-break, a new SegWit version (which is more limited than Tapscript versions, unfortunately) can also be used, creating a new P2WSHv2 (or whatever version) that enables these opcodes.
As far a I know, this is the covenants proposal that has been implemented for the longest time, if that's to be used as a selection criteria.And as always, this is not incompatible with deploying other convenant proposals later.
No, it was OP_EVAL, not OP_CAT.
In particular if OP_EVAL was allowed in the redeemScript then it would enable covenants as well.
It was just pointed out that OP_CAT enables recursive covenenats in combination with OP_EVAL-in-redeemScript.
In particular, in combination with OP_CAT, OP_EVAL not only allows recursive covenants, but also recursion within a SCRIPT i.e. unbounded SCRIPT execution.
Thus, OP_EVAL is simply not going to fly, at all.
Personally I find the simplicity proposal the best one among all the covenant proposals by far, including this one.But I understand that despite the name, the proposal is harder to review and test than other proposals, for it wouldn't simply add covenants, but a complete new scripting language that is better in many senses.Speedy covenants, on the other hand, is much simpler and has been implemented for longer, so in principle, it should be easier to deploy in a speedy manner.
What are the main arguments against speedy covenants (aka op_cat2) and against deploying simplicity in bitcoin respectively?
Sorry if this was discussed before.
OP_CAT, by itself, does not implement any covenants --- instead, it creates recursive covenants when combined with almost all covenant opcodes.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:09:14

- reply

📅 Original date posted:2022-05-07
📝 Original message:> Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a new OP_CAT2 that does the same would be a softfork.
We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means "anyone can move those coins", so adding some restrictions is all we need to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless it will be totally different, but then it should not be named as OP_CAT2, but rather as OP_SOMETHING_ELSE, it depends how different it will be from OP_CAT.
> OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT ...
So we can use OP_SUBSTR instead. Maybe even OP_SPLIT will be enough, if data expansion is the only problem, then we can focus on getting it smaller. Or better, we could use OP_FIND that would return true/false answer if element A is a part of element B, when we do byte-to-byte comparison. In general, we can use many different string-based functions to do the same things, we can choose something that will not exponentially explode as OP_CAT.
> It was considered unfair that the sender is paying for the security of the receiver.
It can be changed by using different sighashes, for example, it is possible to create a "negative fee transaction", where all transaction costs are paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount in outputs than inputs is enough to do that, see testnet3 transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.
On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Jorge,
> OP_CAT was removed. If I remember correctly, some speculated that perhaps it was removed because it could allow covenants.I don't remember any technical concern about the OP besides enabling covenants.Before it was a common opinion that covenants shouldn't be enabled in bitcoin because, despite having good use case, there are some nasty attacks that are enabled with them too. These days it seems the opinion of the benefits being worth the dangers is quite generalized. Which is quite understandable given that more use cases have been thought since then.
I think the more accurate reason for why it was removed is because the following SCRIPT of N size would lead to 2^N memory usage:
OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT ...
In particular it was removed at about the same time as `OP_MUL`, which has similar behavior (consider that multiplying two 32-bit numbers results in a 64-bit number, similar to `OP_CAT`ting a vector to itself).
`OP_CAT` was removed long before covenants were even expressed as a possibility.
Covenants were first expressed as a possibility, I believe, during discussions around P2SH.
Basically, at the time, the problem was this:
* Some receivers wanted to use k-of-n multisignature for improved security.
* The only way to implement this, pre-P2SH, was by putting in the `scriptPubKey` all the public keys.
* The sender is the one paying for the size of the `scriptPubKey`.
* It was considered unfair that the sender is paying for the security of the receiver.
Thus, `OP_EVAL` and the P2SH concept was conceived.
Instead of the `scriptPubKey` containing the k-of-n multisignature, you create a separate script containing the public keys, then hash it, and the `scriptPubKey` would contain the hash of the script.
By symmetry with the P2PKH template:
OP_DUP OP_HASH160 <hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIG
The P2SH template would be:
OP_DUP OP_HASH160 <hash160(redeemScript)> OP_EQUALVERIFY OP_EVAL
`OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT.
It was then pointed out that `OP_EVAL` could be used to create recursive SCRIPTs by quining using `OP_CAT`.
`OP_CAT` was already disabled by then, but people were talking about re-enabling it somehow by restricting the output size of `OP_CAT` to limit the O(2^N) behavior.
Thus, since then, `OP_CAT` has been associated with ***recursive*** covenants (and people are now reluctant to re-enable it even with a limit on its output size, because recursive covenants).
In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too to quine.
Because of those concerns, the modern P2SH is now "just a template" with an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL` being actually enabled.
(`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to remember that P2SH was pretty much what codified the difference between softfork and hardfork, and the community at the time was small enough (or so it seemed) that a hardfork might not have been disruptive.)
> Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a new OP_CAT2 that does the same would be a softfork.
If you are willing to work in Taproot the same OP-code can be enabled in a softfork by using a new Tapscript version.
If you worry about quantum-computing-break, a new SegWit version (which is more limited than Tapscript versions, unfortunately) can also be used, creating a new P2WSHv2 (or whatever version) that enables these opcodes.
> As far a I know, this is the covenants proposal that has been implemented for the longest time, if that's to be used as a selection criteria.And as always, this is not incompatible with deploying other convenant proposals later.
No, it was `OP_EVAL`, not `OP_CAT`.
In particular if `OP_EVAL` was allowed in the `redeemScript` then it would enable covenants as well.
It was just pointed out that `OP_CAT` enables recursive covenenats in combination with `OP_EVAL`-in-`redeemScript`.
In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows recursive covenants, but also recursion *within* a SCRIPT i.e. unbounded SCRIPT execution.
Thus, `OP_EVAL` is simply not going to fly, at all.
> Personally I find the simplicity proposal the best one among all the covenant proposals by far, including this one.But I understand that despite the name, the proposal is harder to review and test than other proposals, for it wouldn't simply add covenants, but a complete new scripting language that is better in many senses.Speedy covenants, on the other hand, is much simpler and has been implemented for longer, so in principle, it should be easier to deploy in a speedy manner.
>
> What are the main arguments against speedy covenants (aka op_cat2) and against deploying simplicity in bitcoin respectively?
> Sorry if this was discussed before.
`OP_CAT`, by itself, does not implement any covenants --- instead, it creates recursive covenants when combined with almost all covenant opcodes.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:09:08

- reply

📅 Original date posted:2022-05-03
📝 Original message:It seems that the current consensus with Taproot is enough to implement CoinPool. There are no needed changes if we want to form a basic version of that protocol, so it probably should be done now (or at least started, even in some signet or testnet3). Later, if some features like SIGHASH_ANYPREVOUT (or the same with ANYSCRIPT) would be added, then it could be improved, just in the same way, as Lightning Network is moving from P2WSH to P2TR.
To start with, we assume there are six participants that are going to form a CoinPool. They start their journey by moving all of their coins to a 6-of-6 multisig channel. Nothing is signed, first we focus on making transactions, then we will sign them backwards to make it trustless.
+------------------------------------------------+
| Alice 3.51 -> ABCDEF (6-of-6 multisig) 19.94 |
| Bob 0.90 |
| Charlie 6.81 |
| Daniel 7.29 |
| Elaine 0.84 |
| Frank 0.60 |
+------------------------------------------------+
That first transaction is simple, we could sign it later with SIGHASH_ALL. But it seems we can handle it better: what about SIGHASH_ANYONECANPAY? Then, all outputs (so just one) will be signed, but anyone could attach another inputs if needed. Also, the first person could use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, but it is optional, and I assume we don't need any "group leader" or "coordinator", so anyone will just use SIGHASH_ANYONECANPAY, they will only switch destination and amount, to form a channel in a P2P way. Channel forming could work in a similar way as mempools in Bitcoin: all messages will fly, until there will be some agreement, and some group will collect all needed signatures. But for now, nothing is signed, so let's go to the next transaction.
To close that channel, a group should still exist, and just detach some participant. Closing the whole group is not an option, we want to encourage CoinPool formation, so we don't want to continuously open and close the whole channel. Let's assume that Alice wants to leave. That means, we should get a group of five participants and Alice, nothing more is needed:
+-----------------------------------------------------------------+
| ABCDEF (6-of-6 multisig) 19.94 -> BCDEF (5-of-5 multisig) 16.43 |
| Alice 3.50 |
+-----------------------------------------------------------------+
When we talk about sighashes, that case is quite interesting. The group of five participants could use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, and just bind that to the first output. But Alice cannot use the same sighash, because then her funds could be stolen by miners. She can use SIGHASH_ANYONECANPAY, then all outputs will be protected by her signature. However, combining two different sighashes is not going to work well with Schnorr signatures. For that reason, we need two of them. So, the TapScript branch for that ABCDEF multisig could be: "<pubkeyBCDEF> OP_CHECKSIGVERIFY <pubkeyAlice> OP_CHECKSIG".
Also, this case is even more interesting: Alice could also use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY in that ABCDEF multisig and spend by key, but then she needs some on-chain output. It could be anything, even some output she received from dust attack. Then, she could use SIGHASH_ANYONECANPAY on that dust output, just to protect her coins. The total transaction size will be roughly the same, but then she could hide the whole group under a single Schnorr signature.
The missing part here is of course SIGHASH_ANYPREVOUT, then less transactions are needed. But even without that, the basic protocol can be deployed here and now, the only overhead will be transaction storage, because we need to sign every possible transaction for closing the channel. Also, it will be larger in case where all participants are going to close the channel, then each detachment will be processed in a separate transaction.
When it comes to handling costs, the cost of leaving the channel is paid by the detached person. That means, even if going through the least compressed path is possible, it would be costly for all participants trying to do that, so it should discourage them and encourage to play by the rules, and move all coins through N-of-N multisig.
Also, when we talk about covenants, it is in fact some kind of covenant. By having different sighashes for different signatures, we can easily restrict outputs to any scripts we want (and every participant can just collect other signatures, and later decide, where to send its own coins, so it is possible to pay someone directly, instead of first moving coins to some personal address, so there is one less transaction; tldr: another payment can be done during closing the channel).
So, my conclusion is that changing sighashes is far easier and more powerful than my previous idea of "paying to signatures", so I will probably focus on that instead.

2023-06-07 23:09:07

- reply

📅 Original date posted:2022-05-03
📝 Original message:Typical P2PK looks like that: "<signature> <pubkey> OP_CHECKSIG". In a typical scenario, we have "<signature>" in out input and "<pubkey> OP_CHECKSIG" in our output. I wonder if it is possible to use covenants right here and right now, with no consensus changes, just by requiring a specific signature. To start with, I am trying to play with P2PK and legacy signatures, but it may turn out, that doing such things with Schnorr signatures will be more flexible and will allow more use cases.
The simplest "pay to signature" script I can think of is: "<signature> OP_SWAP OP_CHECKSIG". Then, any user can provide just a "<pubkey>" in some input, as a part of a public key recovery. The problem with such scheme is that it is insecure. Another problem is that we should handle it carefully, because signatures are removed from outputs. However, we could replace it with some signature hash, then it will be untouched, for example: "OP_TOALTSTACK OP_DUP OP_HASH160 <signatureHash> OP_EQUALVERIFY OP_FROMALTSTACK OP_CHECKSIG".
And then, signatures are more flexible than public keys, because we can use many different sighashes to decide, what kind of transaction is allowed and what should be rejected. Then, if we could use the right signature with correct sighashes, it could be possible to disable key recovery and require some specific public key, then that scheme could be safely used again. I still have no idea, how to complete that puzzle, but it seems to be possible to use that trick, to restrict destination address. Maybe I should wrap such things in some kind of multisig or somehow combine it with OP_CHECKSIGADD, any ideas?

2023-06-07 23:08:55

- reply

📅 Original date posted:2022-05-01
📝 Original message:It seems that Taproot allows us to protect each individual public key with a password. It could work in this way: we have some normal, Taproot-based public key, that is generated in a secure and random way, as it is today in Bitcoin Core wallet. Then, we can create another public key, just by taking password from the user, executing SHA-256 on that, and using it as a private key, so the second key will be just a brainwallet. Then, we can combine them in a Schnorr signature, forming 2-of-2 multisig, where the first key is totally random, and the second key is just a brainwallet that takes a password chosen by the user. By default, each key can be protected with the same password, used for the whole wallet, but it could be possible to choose different passwords for different addresses, if needed. Descriptors should handle that nicely, in the same way as they can be used to handle any other 2-of-2 multisig.

2023-06-07 23:06:49

- reply

📅 Original date posted:2022-04-05
📝 Original message:When I see more and more proposals like this, where things are commited to Taproot outputs, then I think we should start designing "miner-based commitments". If someone is going to make a Bitcoin transaction and add a commitment for zero cost, just by tweaking some Taproot public key, then it is a benefit for the network, because then it is possible to get more things with no additional bytes. Instead of doing "transaction-only", people can do "transaction+commitment" for the same cost, that use case is positive.
But if someone is going to make a Bitcoin transaction only to commit things, where in other case that person would make no transaction at all, then I think we should have some mechanism for "miner-based commitments" that would allow making commitments in a standardized way. We always have one coinbase transaction for each block, it is consensus rule. So, by tweaking single public key in the coinbase transaction, it is possible to fit all commitments in one tweaked key, and even make it logarithmic by forming a tree of commitments.
I think we cannot control user-based commitments, but maybe we should standardize miner-based commitments, for example to have a sorted merkle tree of commitments. Then, it would be possible to check if some commitment is a part of that tree or not (if it is always sorted, then it is present at some specified position or not, so by forming SPV-proof we can quickly prove, if some commitment is or is not a part of some miner Taproot commitment).
On 2022-04-05 15:06:03 user Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
Hi y'all,
I'm excited to publicly publish a new protocol I've been working on over the past few months: Taro. Taro is a Taproot Asset Representation Overlay which allows the issuance of normal and also collectible assets on the main Bitcoin chain. Taro uses the Taproot script tree to commit extra asset structured meta data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a sparse merkle tree, enabling things like easily verifiable asset supply proofs and also efficient proofs of non existence (eg: you prove to me you're no longer committing to the 1-of-1 holographic beefzard card during our swap). Taro asset transfers are then embedded in a virtual/overlay transaction graph which uses a chain of asset witnesses to provably track the transfer of assets across taproot outputs. Taro also has a scripting system, which allows for programmatic unlocking/transfer of assets. In the first version, the scripting system is actually a recursive instance of the Bitcoin Script Taproot VM, meaning anything that can be expressed in the latest version of Script can be expressed in the Taro scripting system. Future versions of the scripting system can introduce new functionality on the Taro layer, like covenants or other updates.
The Taro design also supports integration with the Lightning Network (BOLTs) as the scripting system can be used to emulate the existing HTLC structure, which allows for multi-hop transfers of Taro assets. Rather than modify the internal network, the protocol proposes to instead only recognize "assets at the edges", which means that only the sender+receiver actually need to know about and validate the assets. This deployment route means that we don't need to build up an entirely new network and liquidity for each asset. Instead, all asset transfers will utilize the Bitcoin backbone of the Lightning Network, which means that the internal routers just see Bitcoin transfers as normal, and don't even know about assets at the edges. As a result, increased demand for transfers of these assets as the edges (say like a USD stablecoin), which in will turn generate increased demand of LN capacity, result in more transfers, and also more routing revenue for the Bitcoin backbone nodes.
The set of BIPs are a multi-part suite, with the following breakdown:
* The main Taro protocol: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
* The MS-SMT structure: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
* The Taro VM: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
* The Taro address format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
* The Taro Universe concept: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
* The Taro flat file proof format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
Rather than post them all in line (as the text wouldn't fit in the allowed size limit), all the BIPs can be found above.
-- Laolu

2023-06-07 23:06:30

- reply

📅 Original date posted:2022-03-19
📝 Original message:> There are two use-cases for OP_RETURN: committing to data, and publishing data. Your proposal can only do the former, not the latter, and there are use-cases for both.
Only the former is needed. Pushing data on-chain is expensive and that kind of data is useful only to the transaction maker. Also, the latter can be pushed on a separate chain (or even a separate layer that is not a chain at all).
Also note that since Taproot we have the latter: we can spend by TapScript and reveal some public key and tapbranches. It is possible to push more than 80 bytes in this way, so why direct OP_RETURN is needed, except for backward-compatibility? (for example in Segwit commitments)
There is only one problem with spending by TapScript, when it comes to publishing data: only the first item is the public key. If we could use public keys instead of tapbranch hashes, we could literally replace "OP_RETURN <commitment>" with "<tweakedPublicKey> <tweakedTapBranchKey1> <tweakedTapBranchKey2> <tweakedTapBranchKey3> ... <tweakedTapBranchKeyN>". Then, we could use unspendable public keys to push data, so OP_RETURN would be obsolete.
By the way, committing to data has a lot of use cases, for example the whole idea of NameCoin could be implemented on such OP_RETURN's. Instead of creating some special transaction upfront, people could place some hidden commitment and reveal that later. Then, there would be no need to produce any new coins out of thin air, because everything would be merge-mined by default, providing Bitcoin-level Proof of Work protection all the time, 24/7/365. Then, people could store that revealed commitments on their own chain, just to keep track of who owns which name. And then, that network could easily turn on and off all Bitcoin features as they please. Lightning Network on NameCoin? No problem, even the same satoshis could be used to pay for domains!
On 2022-03-16 19:21:37 user Peter Todd <pete at petertodd.org> wrote:
> On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev 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.
There are two use-cases for OP_RETURN: committing to data, and publishing data.
Your proposal can only do the former, not the latter, and there are use-cases
for both.
--
https://petertodd.org 'peter'[:-1]@petertodd.org

2023-06-07 23:06:25

- reply

📅 Original date posted:2022-03-12
📝 Original message:> We should remove the dust limit from Bitcoin.
Any node operator can do that. Just put "dustrelayfee=0.00000000" in your bitcoin.conf.
And there is more: you can also conditionally allow free transactions:
mintxfee=0.00000001
minrelaytxfee=0.00000000
blockmintxfee=0.00000000
Then, when using getblocktemplate you will get transactions with the highest fees first anyway, and you include cheap or free transactions in the end, if there will be enough room for them.
So, all of those settings are in the hands of node operators, there is no need to change the source code, all you need is to convince nodes to change their settings.
On 2021-08-08 20:53:28 user Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
We should remove the dust limit from Bitcoin. Five reasons:
1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart contracts
3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent dividend check in the mail)
4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.
5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers
The main reasons I'm aware of not allow dust creation is that:
1) dust is spam
2) dust fingerprinting attacks
1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by well behaved wallets to not redeem outputs that cost more in fees than they are worth.
cheers,
jeremy

2023-06-07 23:06:12

- reply

📅 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

2023-06-07 23:06:11

- reply

📅 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

2023-06-07 23:06:09

- reply

📅 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

2023-06-07 23:05:26

- reply

📅 Original date posted:2022-03-05
📝 Original message:> There's no point to pegging coins that are worthless into a system of also worthless coins, unless you want to test the mechanism of testing pegging.
But testing pegging is what is needed if we ever want to introduce sidechains. On the other hand, even if we don't want sidechains, then the question still remains: why we need more than 21 million coins for testing, if we don't need more than 21 million coins for real transactions?
> If anything I think we should permanently shutter testnet now that signet is available.
Then, in that case, the "mainchain" can be our official signet and other signets can be pegged into that. Also, testnet3 is permissionless, so how signet can replace that? Because if you want to test mining and you cannot mine any blocks in signet, then it is another problem.
On 2022-03-05 17:19:40 user Jeremy Rubin <jeremy.l.rubin at gmail.com> wrote:
There's no point to pegging coins that are worthless into a system of also worthless coins, unless you want to test the mechanism of testing pegging.
As is, it's hard enough to get people set up on a signet, if they have to run two nodes and then scramble to find testnet coins and then peg them were just raising the barriers to entry for starting to use a signet for testing.
If anything I think we should permanently shutter testnet now that signet is available.
On Sat, Mar 5, 2022, 3:53 PM vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
In testnet3, anyone can become a miner, it is possible to even mine a block on some CPU, because the difficulty can drop to one. In signet, we create some challenge, for example 1-of-2 multisig, that can restrict who can mine, so that chain can be "unreliably reliable". Then, my question is: why signets are introducing new coins out of thin air, instead of forming two-way peg-in between testnet3 and signet?
The lack of coins is not a bug, it is a feature. We have more halvings in testnet3 than in mainnet or signets, but it can be good, we can use this to see, what can happen with a chain after many halvings. Also, in testnet3 there is no need to have any coins if we are mining. Miners can create, move and destroy zero satoshis. They can also extend the precision of the coins, so a single coin in testnet3 can be represented as a thousand of coins in some signet sidechain.
Recently, there are some discussions regarding sidechains. Before they will become a real thing, running on mainnet, they should be tested. Nowadays, a popular way of testing new features is creating a new signet with new rules. But the question still remains: why we need new coins, created out of thin air? And even when some signet wants to do that, then why it is not pegged into testnet3? Then it would have as much chainwork protection as testnet3!
It seems that testnet3 is good enough to represent the main chain during sidechain testing. It is permissionless and open, anyone can start mining sidechain blocks, anyone with a CPU can be lucky and find a block with the minimal difficulty. Also, because of blockstorms and regular chain reorgs, some extreme scenarios, like stealing all coins from some sidechain, can be tested in a public way, because that "unfriendly and unstable" environment can be used to test stronger attacks than in a typical chain.
Putting that proposal into practice can be simple and require just creating one Taproot address per signet in testnet3. Then, it is possible to create one testnet transaction (every three months) that would move coins to and from testnet3, so the same coins could travel between many signets. New signets can be pegged in with 1:1 ratio, existing signets can be transformed into signet sidechains (the signet miners rule that chains, so they can enforce any transition rules they need).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:05:26

- reply

📅 Original date posted:2022-03-04
📝 Original message:In testnet3, anyone can become a miner, it is possible to even mine a block on some CPU, because the difficulty can drop to one. In signet, we create some challenge, for example 1-of-2 multisig, that can restrict who can mine, so that chain can be "unreliably reliable". Then, my question is: why signets are introducing new coins out of thin air, instead of forming two-way peg-in between testnet3 and signet?
The lack of coins is not a bug, it is a feature. We have more halvings in testnet3 than in mainnet or signets, but it can be good, we can use this to see, what can happen with a chain after many halvings. Also, in testnet3 there is no need to have any coins if we are mining. Miners can create, move and destroy zero satoshis. They can also extend the precision of the coins, so a single coin in testnet3 can be represented as a thousand of coins in some signet sidechain.
Recently, there are some discussions regarding sidechains. Before they will become a real thing, running on mainnet, they should be tested. Nowadays, a popular way of testing new features is creating a new signet with new rules. But the question still remains: why we need new coins, created out of thin air? And even when some signet wants to do that, then why it is not pegged into testnet3? Then it would have as much chainwork protection as testnet3!
It seems that testnet3 is good enough to represent the main chain during sidechain testing. It is permissionless and open, anyone can start mining sidechain blocks, anyone with a CPU can be lucky and find a block with the minimal difficulty. Also, because of blockstorms and regular chain reorgs, some extreme scenarios, like stealing all coins from some sidechain, can be tested in a public way, because that "unfriendly and unstable" environment can be used to test stronger attacks than in a typical chain.
Putting that proposal into practice can be simple and require just creating one Taproot address per signet in testnet3. Then, it is possible to create one testnet transaction (every three months) that would move coins to and from testnet3, so the same coins could travel between many signets. New signets can be pegged in with 1:1 ratio, existing signets can be transformed into signet sidechains (the signet miners rule that chains, so they can enforce any transition rules they need).

2023-06-07 23:05:04

- reply

📅 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

2023-06-07 23:04:52

- reply

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

2023-06-07 23:04:51

- reply

📅 Original date posted:2022-02-24
📝 Original message: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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/e4160455/attachment.html>

2023-06-07 23:04:50

- reply

📅 Original date posted:2022-02-24
📝 Original message:> what happens if/when it comes to pass that we increase payment precision by going sub-satoshi on chain?
When we talk about future improvements, there could be even bigger problem with ordinal numbers: what if/when we introduce some Monero-like system and hide coin amounts? (for example by using zero satoshi, because we have to use something that will be backward-compatible). Zero is quite interesting amount, because it means "skip amount checking for old clients". That can be used in many ways to introduce many protocols (and also to add fractional satoshis on-chain, because 0.4 satoshis could be represented as zero), so if that amounts will be simply ignored, then I wonder how it would be possible to connect some future protocol based on that with ordinal numbers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/7038c088/attachment.html>

2023-06-07 23:04:47

- reply

📅 Original date posted:2022-02-24
📝 Original message:> The system sounds expensive eventually to cope with approximately 2,100,000,000,000,000 ordinals.
What about zero satoshis? There are transactions, where zero satoshis are created or moved. Typical users cannot do that, but miners can, we currently have such transactions in the blockchain, for example 9f0b871e28fa19e2308e2fa74243bf2dcf23b160754df847d5f1e41aabe499d1 (check the last two inputs).
On 2022-02-24 01:53:36 user damian--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Well done, your bip looks well presented for discussion. You say to
number each satoshi created? For a 50 BTC block reward that is
5,000,000,000 ordinal numbers, and when some BTC is transferred to
another UTXO how do you determine which ordinal numbers, say if I create
a transaction to pay-to another UTXO. The system sounds expensive
eventually to cope with approximately 2,100,000,000,000,000 ordinals. If
I understand ordinals 0 to 5,000,000,000 as assigned to the first
Bitcoin created from mining block-reward. Say if I send some Bitcoin to
another UTXO then first-in-first-out algorithm splits those up to assign
1 to 100,000,000 to the 1 BTC that I sent, and 100,000,001 to
5,000,000,000 are assigned to the change plus if any fee?-DA.
On 2022-02-23 11:43, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order
> in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input
> satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:03:42

- reply

📅 Original date posted:2022-02-28
📝 Original message:> 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.
On 2022-02-28 08:13:03 user ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Paul,
> On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
>
> > ...
> >
> > > Such a technique would need to meet two requirements (or, so it seems to me):
> > > #1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened).
> > > #2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain.
> > >
> > > Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research.
> >
> > Yes, using channel factories.
>
> I think you may be wrong about this.
> Channel factories do not meet requirement #2, as they cannot grow to onboard new users (ie, new pubkeys).
> The factory-open requires that people pay to (for example), a 5-of-5 multisig. So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not after.
I am not wrong about this.
You can cut-through the closure of one channel factory with the opening of another channel factory with the same 5 fixed pubkeys *plus* an additional 100 new fixed pubkeys.
With `SIGHASH_ANYPREVOUT` (which we need to Decker-Russell-Osuntokun-based channel factories) you do not even need to make new signatures for the existing channels, you just reuse the existing channel signatures and whether or not the *single*, one-input-one-output, close+reopen transaction is confirmed or not, the existing channels remain usable (the signatures can be used on both pre-reopen and post-reopen).
That is why I said changing the membership set requires onchain action.
But the onchain action is *only* a 1-input-1-output transaction, and with Taproot the signature needed is just 64 bytes witness (1 weight unit per byte), I had several paragraphs describing that, did you not read them?
Note as well that with sidechains, onboarding also requires action on the mainchain, in the form of a sideblock merge-mined on the mainchain.
>
> > We assume that onboarding new members is much rarer than existing members actually paying each other
>
> Imagine that Bitcoin could only onboard 5 new users per millennium, but once onboarded they had payment nirvana (could transact hundreds of trillions of times per second, privately, smart contracts, whatever).
> Sadly, the payment nirvana would not matter. The low onboarding rate would kill the project.
Fortunately even without channel factories the onboarding rate of LN is much much higher than that.
I mean, like, LN *is* live and *is* working, today, and (at least where I have looked, but I could be provincial) has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock.
> The difference between the two rates [onboarding and payment], is not relevant. EACH rate must meet the design goal.
> It is akin to saying: " Our car shifts from park to drive in one-millionth of a second, but it can only shift into reverse once per year; but that is OK because 'we assume that going in reverse is much rarer than driving forward' ".
Your numbers absolutely suck and have no basis in reality, WTF.
Even without batched channel openings and a typical tranaction of 2 inputs, 1 LN channel, and a change output, you can onboard ~1250 channels per mainchain block (admittedly, without any other activity).
Let us assume every user needs 5 channels on average and that is still 250 users per 10 minutes.
I expect channel factories to increase that by about 10x to 100x more, and then you are going to hit the issue of getting people to *use* Bitcoin rather than many users wanting to get in but being unable to due to block size limits.
>
> > 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.
>
> That's true, but I think you have neglected to actually take out your calculator and run the numbers.
>
> Hypothetically, 10 largeblock-sidechains would be 320 bytes per block (00.032%, essentially nothing).
> Those 10, could onboard 33% of the planet in a single month [footnote], even if each sc-onboard required an average of 800 sc-bytes.
>
> Certainly not a perfect idea, as the SC onboarding rate is the same as the payment rate. But once they are onboarded, those users can immediately join the LN *from* their sidechain. (All of the SC LNs would be interoperable.)
>
> Such a strategy would take enormous pressure *off* of layer1 (relative to the "LN only" strategy). The layer1 blocksize could even **shrink** from 4 MB (wu) to 400 kb, or lower. That would cancel out the 320 bytes of overhead, many hundreds of times over.
>
> Paul
>
> [footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*1000*1000)/800) / 8.2 billion = .32926
Yes, and 33% of the planet want to use Bitcoin in the next month.
The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin, and any security you sacrifice in order to get a higher number than that is security you are sacrificing needlessly for extra capacity you are unable to utilize.
As I pointed out in the other thread:
* LN:
* Funds can be stolen IF:
* There is a 51% miner, AND
* The 51% miner is a member of a channel/channel factory you are in.
* Drivechains:
* Funds can be stolen IF:
* There is a 51% miner.
Now of course there is always the possibility that the 51% miner is in *every* channel factory globally.
But there is also the possibility that the 51% miner exists, but is *not* on every channel factory.
Indeed, for any arbitrary channel or factory, I expect that the probability of the 51% miner being a member is less than 100%, thus the combined probability is lower than Drivechains.
So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month.
I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS that came up only due to hitting the minimum feerate, so no --- people are not joining Bitcoin at a rate faster than Bitcoin + LN can handle it, even with a pretty good reason to move payments online.
Worse, once 100% of the world is onboarded, the extra onboarding capacity is useless since the onboarding rate can only match the birth rate (including birth of legal persons such as corporations), which we expect is much lower than 33% increase per ***month***.
You are buying too much capacity at a real degradation in security, and I am not convinced the extra capacity is worth the loss of security.
Separating the onboarding rate from the payment rate is a *good thing*, because we can then design their structures differently.
Make onboarding slow but secure (so that their money is very secure), but make payment rate faster and less secure (because in-flight payments are likely to be much smaller than the total owned funds).
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:01:46

- reply

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

2023-06-07 23:01:25

- reply

📅 Original date posted:2021-12-23
📝 Original message:> Associating signing with proof of stake and thereby concluding that signing is something to avoid sounds like superstitious thinking.
If you introduce signing into mining, then you will have cases, where someone is powerful enough to produce blocks, but cannot, because signing is needed. Then, your consensus is no longer "the heaviest chain", but "the heaviest signed chain". That means, your computing power is no longer enough by itself (as today), because to make a block, you also need some kind of "permission to mine", because first you sign things (like in signet) and then you mine them. That kind of being "reliably unreliable" may be ok for testing, but not for the main network.
> A signing scheme with proof of work would clearly not be proof of stake.
It is not that far from Proof of Stake as you may think. In Proof of Stake, you sign your whale balance with thousands of BTC, and then you can mine a new block, just by putting your coins at stake. In Proof of Work with signing, you also make a signature, and even if there is no amount in satoshis for your signing key, it is still somehow checked, who can sign a block and how many signatures are needed. So, is your private key that allows you to extend the chain is really worth zero satoshis, because there is no balance connected with your address/public key? Not really, it is worth a lot of coins, because it can be used to control the chain.
> The benefit of that over merge mining would be no extra on chain foot print.
Your signatures would be that "extra on chain foot print". In signet, by default you have 1-of-2 multisig, so you have one signature for every block. In the main chain, there is no need for any foot print, because you can reveal taproot public key and hide other things in tapscript, so your foot print is present only when people will not cooperate.
On 2021-12-20 18:18:58 user Billy Tetrud <billy.tetrud at gmail.com> wrote:
> you can assign some minimal difficulty,
I was assuming that would be part of the plan.
> Signing sounds more like Proof of Stake
Associating signing with proof of stake and thereby concluding that signing is something to avoid sounds like superstitious thinking. A signing scheme with proof of work would clearly not be proof of stake. I would suggest not dismissing a design out of hand like that. The benefit of that over merge mining would be no extra on chain foot print. What do you think the downsides might be?
> if you use just hashes, then they could be random.
You're right. Nodes would of course need to validate the Bitcoin block headers being included, so i concede hashing them doesn't gain you anything.
On Thu, Dec 16, 2021, 22:37 <vjudeu at gazeta.pl> wrote:
> I was thinking that this would be a separate blockchain with separate headers that progress linearly like a normal blockchain.
Exactly, that's what I called "superblocks", where you have a separate chain, just to keep block headers instead of transactions.
> A block creator would collect together as many blocks that haven't been collected yet into the next superblock (and maybe receive a reward proportional to how many / how much weight they include).
You cannot "catch them all". If you do, you can end up with a lot of block headers, where each of them has difficulty equal to one. You need some limit, you can limit amount of blocks, you can assign some minimal difficulty, it does not matter that much, but some limit is needed, also because mining on top of the latest superblock should be more profitable than replacing someone else's reward in the previous superblock by your own reward and getting a bigger share in the previous superblock.
> This could be done using merge mining, or it could be done using a signing scheme (eg where the block creator signs to say "I created this superblock" and have mechanisms to punish those who sign multiple superblocks at the same height.
I would pick merge mining, because it is more compatible with existing mining scheme. Signing sounds more like Proof of Stake and I am trying to avoid that solution. Also, there is no need to sign anything, because you are solo mining where you have your own coinbase transaction or you are mining in a pool, where you have some shared address, and then you cannot produce any incompatible superblock, because the protocol can tell you, which address you should use (and if it is N-of-N taproot multisig and you have some closing transaction, then you can safely mine it).
> Really, you could even just use hashes of the block headers.
Replacing transactions with block headers will do the same trick. Each transaction is first hashed with double SHA-256, in exactly the same way as block headers are. If you replace transactions with block headers, you would get a superblock header, then varint saying how many block headers are there, and then you can place all block headers. During superblock merkle tree construction, you will hash all block headers (so you will get block hashes as leaves), and then you will combine block hashes in the same way as transaction hashes are combined.
>From the Script point of view, you can always use "OP_SIZE 80 OP_EQUALVERIFY OP_HASH256 <hash> OP_EQUAL". Then, you can just change the size, just to show which object is hashed. Value 80 will work for block headers, small values below 520 will work for small transactions, value 64 will work for any merkle tree proof, no matter if it is for superblock or normal block. Also, by using block headers instead of hashes, you can prove that at least a proper amount of work was done to produce it, because if you use just hashes, then they could be random.
On 2021-12-16 17:57:23 user Billy Tetrud <billy.tetrud at gmail.com> wrote:
@Jeremy
> for top-level pool participants there is never any central custody.
I definitely see that. That was actually what I meant when I said the goals aren't the same as benefits. While your idea definitely satisfies all your goals in a modular way, the fact that it relies on pools means that unless the pools can also satisfy the goals, the total system also doesn't satisfy the goals (even tho the piece of that system you designed does).
> Thus it doesn't "hurt" anyone except for the miners who are taking the not fully locked in funds risk
True, it only potentially hurts whoever the channel partner is accepting the unspendable coins. And no one can really stop anyone from taking that risk if they really want to. But in that case, its not exactly a fully functional channel, since recourse mechanisms couldn't be performed. Wouldn't that open such a channel up to a pretty bad theft possibility?
@Bob
> Increased payout regularity does not lower the viable size of mining pools, because smaller mining pools using this mechanism still have higher variance.
Yes, smaller mining pools will always have higher variance. However, lower variance has diminishing benefits. Below a certain amount of variance, less variance isn't very valuable. So increased payout regularity does indeed lower the viable size of mining pools because a given low-enough level of variance can be achieved with less pool hashpower.
> The on-chain footprint is *higher* due to the increased payout regularity.
That's a reasonable point. However, I think there is a difference here between the regularity of rewards vs payouts. Rewards for each miner can be more regular without necessarily increasing the number of on-chain payouts. In fact, theoretically, an individual miner could let their rewards accumulate in a pool over many rewards and only redeem when they need the coins for something. The incentive is there for each miner to be judicious on how much onchain space they take up.
@vjudeu
> how many block headers should be stored per one "superblock"?
I was thinking that this would be a separate blockchain with separate headers that progress linearly like a normal blockchain. A block creator would collect together as many blocks that haven't been collected yet into the next superblock (and maybe receive a reward proportional to how many / how much weight they include). This could be done using merge mining, or it could be done using a signing scheme (eg where the block creator signs to say "I created this superblock" and have mechanisms to punish those who sign multiple superblocks at the same height. For merge mining, I could even imagine the data necessary to validate that it has been merge mined could be put into a taproot script branch (creating an invalid script, but a valid hash of the superblock).
> we can collect all headers with the same previous block hash, and distribute block reward between all coinbase transactions in those headers
Exactly.
> we would just have block headers instead of transactions
Yeah, I think that would be the way to go. Really, you could even just use hashes of the block headers. But the size doesn't matter much because it would be both a small blockchain and an ephemeral one (which can be fully discarded after all parties have been paid out, or at least their payout has been committed to on the bitcoin blockchain).
On Thu, Dec 16, 2021 at 1:35 AM <vjudeu at gazeta.pl> wrote:
> The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
I thought about something like that, but there is one problem: how many block headers should be stored per one "superblock"? Currently, we have single block header, where the whole coinbase transaction is taken by some mining pool or solo miner. But instead, each miner could submit its own block header. Then, we can collect all headers with the same previous block hash, and distribute block reward between all coinbase transactions in those headers. One "superblock" then would be created in a similar way as existing blocks, we would just have block headers instead of transactions. If most transactions inside those blocks will be the same, then each block could be expressed just as a set of transaction hashes, only coinbase transactions or custom, non-broadcasted transactions included by miners will be revealed, everything else will be known.
> One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
All coinbase rewards are unspendable for 100 blocks, it is enforced by consensus. It does not matter if there are outputs owned directly by miners, or if there is one huge N-of-N taproot multisig for the whole pool, where every miner signed the closing transaction. The only option to take coins faster I can see is swapping the coins by some LN transaction. But then, the other party can check if some deposit to the LN channel is a part of the coinbase transaction or not, and then decide if it is acceptable to do the swap.
On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Looks like an interesting proposal, but it doesn't seem to quite match the goals you mentioned. As you do mention, this mining pool coordination doesn't get rid of the need for mining pools in the first place. So it doesn't satisfy item 1 on your goal list afaict.
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pools, and
2. Lower on chain footprint through combining pay outs from multiple pools.
Am I missing some?
These are interesting benefits, but it would be nice if your post was clearer on that, since the goals list is not the same as the list of potential benefits of this kind of design.
As far as enabling solo mining, what if this concept were used off chain? Have a public network of solo miners who publish "weak blocks" to that network, and the next 100 (or 1000 etc) nice miners pay you out as long as you're also being nice by following the protocol? All the nice optimizations you mentioned about eg combined taproot payouts would apply i think. The only goals this wouldn't satisfy are 3 and 5 since an extra network is needed, but to be fair, your proposal requires pools which all need their own extra network anyways.
The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
You are hand waving. Attempting to redefine terms to justify your argument is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashrate.
Various suggestions below introduce dangerous new games that might be played by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You are trying to justify CTV by making it be all things to all people. "When
all you have is a hammer, every problem looks like a nail". Instead I humbly
suggest that you pick ONE problem for which CTV is demonstrably the right and
best solution, instead of snowing us with a ton of half-baked things that
*could* be done, and often don't even require CTV, and some (like this one)
fundamentally don't work. I do like some of your ideas, but if you had to pick
just one "use case", which would it be?
Jeremy [jlrubin at mit.edu] wrote:
> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/
> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may
> not be your favorite kind, which is fixated on specific properties of computing
> contributions before finding a block. Pooling is just a general technique for
> aggregating resources to accomplish something. If you have another name like
> pooling that is in common use for this type of activity I would be more than
> happy to adopt it.
>
> This sort of pool can hedge not only against fee rates but also against
> increases in hashrate since your historical rate 'carries' into the future as a
> function of the window. Further, windows and reward functions can be defined in
> a myriad of ways that could, e.g., pay less to blocks found in more rapid
> succession, contributing to the smoothing functionality.
>
> With respect to sub-block pooling, as described in the article, this sort of
> design also helps with micro-pools being able to split resources
> non-custodially in every block as a part of the higher order DCFMP. The point
> is not, as noted, to enable solo mining an S9, but to decrease the size of the
> minimum viable pool. It's also possible to add, without much validation or
> data, some 'uncle block' type mechanism in an incentive compatible way (e.g.,
> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 bytes
> payout key) such that there's an incentive to include the heaviest ones you've
> seen, not just your own, that are worth further study and consideration
> (particularly because it's non-consensus, only for opt-in participation in the
> pool).
>
> With respect to space usage, it seems you wholly reject the viability of a
> payment pool mechanism to cut-through chain space. Is this a critique that
> holds for all Payment Pools, or just in the context of mining? Is there a
> particular reason why you think it infeasible that "strongly online"
> counterparties would be able to coordinate more efficiently? Is it preferable
> for miners, the nexus of decentralization for Bitcoin, to prefer to use
> custodial services for pooling (which may require KYC/AM) over bearing a cost
> of some extra potential chainload?
>
> Lastly, with respect to complexity, the proposal is actually incredibly simple
> when you take it in a broader context. Non Interactive Channels and Payment
> Pools are useful by themselves, so are the operations to merge them and swap
> balance across them. Therefore most of the complexity in this proposal is
> relying on tools we'll likely see in everyday use in any case, DCFMP or no.
>
> Jeremy
> !DSPAM:61b8f2f5321461582627336!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
_______________________________________________
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/20211223/2b2e0e8c/attachment-0001.html>

2023-06-07 23:01:24

- reply

📅 Original date posted:2021-12-17
📝 Original message:> I was thinking that this would be a separate blockchain with separate headers that progress linearly like a normal blockchain.
Exactly, that's what I called "superblocks", where you have a separate chain, just to keep block headers instead of transactions.
> A block creator would collect together as many blocks that haven't been collected yet into the next superblock (and maybe receive a reward proportional to how many / how much weight they include).
You cannot "catch them all". If you do, you can end up with a lot of block headers, where each of them has difficulty equal to one. You need some limit, you can limit amount of blocks, you can assign some minimal difficulty, it does not matter that much, but some limit is needed, also because mining on top of the latest superblock should be more profitable than replacing someone else's reward in the previous superblock by your own reward and getting a bigger share in the previous superblock.
> This could be done using merge mining, or it could be done using a signing scheme (eg where the block creator signs to say "I created this superblock" and have mechanisms to punish those who sign multiple superblocks at the same height.
I would pick merge mining, because it is more compatible with existing mining scheme. Signing sounds more like Proof of Stake and I am trying to avoid that solution. Also, there is no need to sign anything, because you are solo mining where you have your own coinbase transaction or you are mining in a pool, where you have some shared address, and then you cannot produce any incompatible superblock, because the protocol can tell you, which address you should use (and if it is N-of-N taproot multisig and you have some closing transaction, then you can safely mine it).
> Really, you could even just use hashes of the block headers.
Replacing transactions with block headers will do the same trick. Each transaction is first hashed with double SHA-256, in exactly the same way as block headers are. If you replace transactions with block headers, you would get a superblock header, then varint saying how many block headers are there, and then you can place all block headers. During superblock merkle tree construction, you will hash all block headers (so you will get block hashes as leaves), and then you will combine block hashes in the same way as transaction hashes are combined.
>From the Script point of view, you can always use "OP_SIZE 80 OP_EQUALVERIFY OP_HASH256 <hash> OP_EQUAL". Then, you can just change the size, just to show which object is hashed. Value 80 will work for block headers, small values below 520 will work for small transactions, value 64 will work for any merkle tree proof, no matter if it is for superblock or normal block. Also, by using block headers instead of hashes, you can prove that at least a proper amount of work was done to produce it, because if you use just hashes, then they could be random.
On 2021-12-16 17:57:23 user Billy Tetrud <billy.tetrud at gmail.com> wrote:
@Jeremy
> for top-level pool participants there is never any central custody.
I definitely see that. That was actually what I meant when I said the goals aren't the same as benefits. While your idea definitely satisfies all your goals in a modular way, the fact that it relies on pools means that unless the pools can also satisfy the goals, the total system also doesn't satisfy the goals (even tho the piece of that system you designed does).
> Thus it doesn't "hurt" anyone except for the miners who are taking the not fully locked in funds risk
True, it only potentially hurts whoever the channel partner is accepting the unspendable coins. And no one can really stop anyone from taking that risk if they really want to. But in that case, its not exactly a fully functional channel, since recourse mechanisms couldn't be performed. Wouldn't that open such a channel up to a pretty bad theft possibility?
@Bob
> Increased payout regularity does not lower the viable size of mining pools, because smaller mining pools using this mechanism still have higher variance.
Yes, smaller mining pools will always have higher variance. However, lower variance has diminishing benefits. Below a certain amount of variance, less variance isn't very valuable. So increased payout regularity does indeed lower the viable size of mining pools because a given low-enough level of variance can be achieved with less pool hashpower.
> The on-chain footprint is *higher* due to the increased payout regularity.
That's a reasonable point. However, I think there is a difference here between the regularity of rewards vs payouts. Rewards for each miner can be more regular without necessarily increasing the number of on-chain payouts. In fact, theoretically, an individual miner could let their rewards accumulate in a pool over many rewards and only redeem when they need the coins for something. The incentive is there for each miner to be judicious on how much onchain space they take up.
@vjudeu
> how many block headers should be stored per one "superblock"?
I was thinking that this would be a separate blockchain with separate headers that progress linearly like a normal blockchain. A block creator would collect together as many blocks that haven't been collected yet into the next superblock (and maybe receive a reward proportional to how many / how much weight they include). This could be done using merge mining, or it could be done using a signing scheme (eg where the block creator signs to say "I created this superblock" and have mechanisms to punish those who sign multiple superblocks at the same height. For merge mining, I could even imagine the data necessary to validate that it has been merge mined could be put into a taproot script branch (creating an invalid script, but a valid hash of the superblock).
> we can collect all headers with the same previous block hash, and distribute block reward between all coinbase transactions in those headers
Exactly.
> we would just have block headers instead of transactions
Yeah, I think that would be the way to go. Really, you could even just use hashes of the block headers. But the size doesn't matter much because it would be both a small blockchain and an ephemeral one (which can be fully discarded after all parties have been paid out, or at least their payout has been committed to on the bitcoin blockchain).
On Thu, Dec 16, 2021 at 1:35 AM <vjudeu at gazeta.pl> wrote:
> The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
I thought about something like that, but there is one problem: how many block headers should be stored per one "superblock"? Currently, we have single block header, where the whole coinbase transaction is taken by some mining pool or solo miner. But instead, each miner could submit its own block header. Then, we can collect all headers with the same previous block hash, and distribute block reward between all coinbase transactions in those headers. One "superblock" then would be created in a similar way as existing blocks, we would just have block headers instead of transactions. If most transactions inside those blocks will be the same, then each block could be expressed just as a set of transaction hashes, only coinbase transactions or custom, non-broadcasted transactions included by miners will be revealed, everything else will be known.
> One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
All coinbase rewards are unspendable for 100 blocks, it is enforced by consensus. It does not matter if there are outputs owned directly by miners, or if there is one huge N-of-N taproot multisig for the whole pool, where every miner signed the closing transaction. The only option to take coins faster I can see is swapping the coins by some LN transaction. But then, the other party can check if some deposit to the LN channel is a part of the coinbase transaction or not, and then decide if it is acceptable to do the swap.
On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Looks like an interesting proposal, but it doesn't seem to quite match the goals you mentioned. As you do mention, this mining pool coordination doesn't get rid of the need for mining pools in the first place. So it doesn't satisfy item 1 on your goal list afaict.
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pools, and
2. Lower on chain footprint through combining pay outs from multiple pools.
Am I missing some?
These are interesting benefits, but it would be nice if your post was clearer on that, since the goals list is not the same as the list of potential benefits of this kind of design.
As far as enabling solo mining, what if this concept were used off chain? Have a public network of solo miners who publish "weak blocks" to that network, and the next 100 (or 1000 etc) nice miners pay you out as long as you're also being nice by following the protocol? All the nice optimizations you mentioned about eg combined taproot payouts would apply i think. The only goals this wouldn't satisfy are 3 and 5 since an extra network is needed, but to be fair, your proposal requires pools which all need their own extra network anyways.
The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
You are hand waving. Attempting to redefine terms to justify your argument is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashrate.
Various suggestions below introduce dangerous new games that might be played by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You are trying to justify CTV by making it be all things to all people. "When
all you have is a hammer, every problem looks like a nail". Instead I humbly
suggest that you pick ONE problem for which CTV is demonstrably the right and
best solution, instead of snowing us with a ton of half-baked things that
*could* be done, and often don't even require CTV, and some (like this one)
fundamentally don't work. I do like some of your ideas, but if you had to pick
just one "use case", which would it be?
Jeremy [jlrubin at mit.edu] wrote:
> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/
> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may
> not be your favorite kind, which is fixated on specific properties of computing
> contributions before finding a block. Pooling is just a general technique for
> aggregating resources to accomplish something. If you have another name like
> pooling that is in common use for this type of activity I would be more than
> happy to adopt it.
>
> This sort of pool can hedge not only against fee rates but also against
> increases in hashrate since your historical rate 'carries' into the future as a
> function of the window. Further, windows and reward functions can be defined in
> a myriad of ways that could, e.g., pay less to blocks found in more rapid
> succession, contributing to the smoothing functionality.
>
> With respect to sub-block pooling, as described in the article, this sort of
> design also helps with micro-pools being able to split resources
> non-custodially in every block as a part of the higher order DCFMP. The point
> is not, as noted, to enable solo mining an S9, but to decrease the size of the
> minimum viable pool. It's also possible to add, without much validation or
> data, some 'uncle block' type mechanism in an incentive compatible way (e.g.,
> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 bytes
> payout key) such that there's an incentive to include the heaviest ones you've
> seen, not just your own, that are worth further study and consideration
> (particularly because it's non-consensus, only for opt-in participation in the
> pool).
>
> With respect to space usage, it seems you wholly reject the viability of a
> payment pool mechanism to cut-through chain space. Is this a critique that
> holds for all Payment Pools, or just in the context of mining? Is there a
> particular reason why you think it infeasible that "strongly online"
> counterparties would be able to coordinate more efficiently? Is it preferable
> for miners, the nexus of decentralization for Bitcoin, to prefer to use
> custodial services for pooling (which may require KYC/AM) over bearing a cost
> of some extra potential chainload?
>
> Lastly, with respect to complexity, the proposal is actually incredibly simple
> when you take it in a broader context. Non Interactive Channels and Payment
> Pools are useful by themselves, so are the operations to merge them and swap
> balance across them. Therefore most of the complexity in this proposal is
> relying on tools we'll likely see in everyday use in any case, DCFMP or no.
>
> Jeremy
> !DSPAM:61b8f2f5321461582627336!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
_______________________________________________
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/20211217/84b4855e/attachment-0001.html>

2023-06-07 23:01:22

- reply

📅 Original date posted:2021-12-16
📝 Original message:> The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
I thought about something like that, but there is one problem: how many block headers should be stored per one "superblock"? Currently, we have single block header, where the whole coinbase transaction is taken by some mining pool or solo miner. But instead, each miner could submit its own block header. Then, we can collect all headers with the same previous block hash, and distribute block reward between all coinbase transactions in those headers. One "superblock" then would be created in a similar way as existing blocks, we would just have block headers instead of transactions. If most transactions inside those blocks will be the same, then each block could be expressed just as a set of transaction hashes, only coinbase transactions or custom, non-broadcasted transactions included by miners will be revealed, everything else will be known.
> One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
All coinbase rewards are unspendable for 100 blocks, it is enforced by consensus. It does not matter if there are outputs owned directly by miners, or if there is one huge N-of-N taproot multisig for the whole pool, where every miner signed the closing transaction. The only option to take coins faster I can see is swapping the coins by some LN transaction. But then, the other party can check if some deposit to the LN channel is a part of the coinbase transaction or not, and then decide if it is acceptable to do the swap.
On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Looks like an interesting proposal, but it doesn't seem to quite match the goals you mentioned. As you do mention, this mining pool coordination doesn't get rid of the need for mining pools in the first place. So it doesn't satisfy item 1 on your goal list afaict.
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pools, and
2. Lower on chain footprint through combining pay outs from multiple pools.
Am I missing some?
These are interesting benefits, but it would be nice if your post was clearer on that, since the goals list is not the same as the list of potential benefits of this kind of design.
As far as enabling solo mining, what if this concept were used off chain? Have a public network of solo miners who publish "weak blocks" to that network, and the next 100 (or 1000 etc) nice miners pay you out as long as you're also being nice by following the protocol? All the nice optimizations you mentioned about eg combined taproot payouts would apply i think. The only goals this wouldn't satisfy are 3 and 5 since an extra network is needed, but to be fair, your proposal requires pools which all need their own extra network anyways.
The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
You are hand waving. Attempting to redefine terms to justify your argument is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashrate.
Various suggestions below introduce dangerous new games that might be played by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You are trying to justify CTV by making it be all things to all people. "When
all you have is a hammer, every problem looks like a nail". Instead I humbly
suggest that you pick ONE problem for which CTV is demonstrably the right and
best solution, instead of snowing us with a ton of half-baked things that
*could* be done, and often don't even require CTV, and some (like this one)
fundamentally don't work. I do like some of your ideas, but if you had to pick
just one "use case", which would it be?
Jeremy [jlrubin at mit.edu] wrote:
> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/
> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may
> not be your favorite kind, which is fixated on specific properties of computing
> contributions before finding a block. Pooling is just a general technique for
> aggregating resources to accomplish something. If you have another name like
> pooling that is in common use for this type of activity I would be more than
> happy to adopt it.
>
> This sort of pool can hedge not only against fee rates but also against
> increases in hashrate since your historical rate 'carries' into the future as a
> function of the window. Further, windows and reward functions can be defined in
> a myriad of ways that could, e.g., pay less to blocks found in more rapid
> succession, contributing to the smoothing functionality.
>
> With respect to sub-block pooling, as described in the article, this sort of
> design also helps with micro-pools being able to split resources
> non-custodially in every block as a part of the higher order DCFMP. The point
> is not, as noted, to enable solo mining an S9, but to decrease the size of the
> minimum viable pool. It's also possible to add, without much validation or
> data, some 'uncle block' type mechanism in an incentive compatible way (e.g.,
> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 bytes
> payout key) such that there's an incentive to include the heaviest ones you've
> seen, not just your own, that are worth further study and consideration
> (particularly because it's non-consensus, only for opt-in participation in the
> pool).
>
> With respect to space usage, it seems you wholly reject the viability of a
> payment pool mechanism to cut-through chain space. Is this a critique that
> holds for all Payment Pools, or just in the context of mining? Is there a
> particular reason why you think it infeasible that "strongly online"
> counterparties would be able to coordinate more efficiently? Is it preferable
> for miners, the nexus of decentralization for Bitcoin, to prefer to use
> custodial services for pooling (which may require KYC/AM) over bearing a cost
> of some extra potential chainload?
>
> Lastly, with respect to complexity, the proposal is actually incredibly simple
> when you take it in a broader context. Non Interactive Channels and Payment
> Pools are useful by themselves, so are the operations to merge them and swap
> balance across them. Therefore most of the complexity in this proposal is
> relying on tools we'll likely see in everyday use in any case, DCFMP or no.
>
> Jeremy
> !DSPAM:61b8f2f5321461582627336!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
_______________________________________________
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/20211216/672b3d09/attachment-0001.html>

2023-06-07 23:01:17

- reply

📅 Original date posted:2021-12-13
📝 Original message:> Can you maybe try stating the goals of your payout function, and then demonstrate how what you're proposing meets that?
The goals are quite simple: if you are a solo miner, you are trying to mine a block that meets the network difficulty. If you are using some kind of pool, then you are trying to mine N times easier blocks and receive N times lower reward for doing that. If many miners work on similar transactions, then each miner can validate each transaction once and assign transaction fee to transaction id, in this way the coinbase reward can be quickly checked, because you have to check only those transactions, which were unknown to you and for example included only by this miner and not broadcasted. Assuming that most of the transactions will be the same and included by most of the miners, that verification would be quick and can be simplified only to checking "what is different from what I am mining".
Also, to determine the proper amount of shares received, you can assign a difficulty for each miner. So, if you are connected to eight mining nodes, you can assign a difficulty to each of them, just to limit how much work for each share they can produce to have it accepted and included for payments. It is needed to avoid spamming by producing a lot of shares at difficulty one by bigger miners, they should find it more profitable to create bigger shares, because by accumulating them, it is cheaper to receive one bigger payment than a lot of smaller payments.
On 2021-12-13 14:59:58 user Jeremy <jlrubin at mit.edu> wrote:
Hey there!
Thanks for your response!
One of the reasons to pick a longer window of, say, a couple difficulty periods would be that you can make participation in the pool hedge you against hashrate changes.
You're absolutely spot on to think about the impact of pooling w.r.t. variance when fees > subsidy. That's not really in the analysis I had in the (old) post, but when the block revenues swing, dcfmp over longer periods can really smooth out the revenues for miners in a great way. This can also help with the "mind the gap" problem when there isn't a backlog of transactions, since producing an empty block still has some value (in order to incentivize mining transaction at all and not cheating, we need to reward txn inclusion as I think you're trying to point out.
Sadly, I've read the rest of your email a couple times and I don't really get what you're proposing at all. It jumps right into "things you could compute". Can you maybe try stating the goals of your payout function, and then demonstrate how what you're proposing meets that? E.g., we want to pay more to miners that do x?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211213/ac9d832f/attachment.html>

2023-06-07 23:01:16

- reply

📅 Original date posted:2021-12-12
📝 Original message:> how to select an analyze the choice of window
Currently, we need 100 blocks to spend the coinbase transaction and I think that should be our "window".
> and payout functions
Something like "miner-based difficulty" should do the trick. So, each miner is trying to produce its own block, with its own transactions, and its own coinbase reward (based on those transactions, if we want to think ahead and do it right from the start, we should be ready for situation where the basic block reward is zero and the whole coinbase is based only on transaction fees). So, each miner can mine a block with its own coinbase amount (based on transaction fees). Then, that miner should multiply the target by the number of satoshis collected in the coinbase transaction to get "target per satoshi". Then, by dividing this target by its block hash, it would produce the number of satoshis that miner should receive.
Some example:
difficulty: 170ba21f
target: 0000000000000000000ba21f0000000000000000000000000000000000000000
coinbase: 6.27930034 BTC (627930034 satoshis = 0x256d73b2 satoshis)
targetPerSatoshi: 0000000000000000000ba21f0000000000000000000000000000000000000000*0x256d73b2
targetPerSatoshi: 000000000001b367c41da68e0000000000000000000000000000000000000000
sampleShare: 0000000000000000b613738816247a7f4d357cae555996519cf5b543e9b3554b
minerReward: targetPerSatoshi/sampleShare=0x2642e (156718 satoshis = 0.00156718 BTC for this share)
Because we assume that the basic reward will be zero, we assume that all miners will include their own set of transactions. That means, to check if the miner really should receive that reward, checking all transactions is required. Assuming that most of the miners will have similar transactions in their mempools, for each share there is a need to only check transactions that were unknown by that miner. For all other previously validated transactions, miners can store a table like: "<txid> <fee>" and then quickly validate if the amount specified in the coinbase transaction is correct.
To avoid "share spam", we can use something like "miner-based difficulty" mentioned above. Everyone knows the network difficulty, but not all miners are directly connected. So, for each connection with each miner in our decentralized pool, we can define a difficulty for each connection. In this way, each node can specify the absolute minimum difficulty, where paying any reward is above the dust limit, and where including that miner makes sense. Then, each miner can produce shares and adjust miner-based difficulty, just to produce for example one share per 10 minutes (or per 30 seconds if we have enough resources to fully validate each share from each miner we are connected with in that time).
If we want to include really small miners (like CPU miners), then we need a way to allow sub-satoshi payments. That means, each small miner should mine to a single N-of-N taproot-based multisig, where the whole pot is then splitted between N miners in LN. That means, for example one output of 1000 satoshis can be shared between one million small CPU miners. Then, our target from example above is denominated in millisatoshis.
targetPerSatoshi: 000000000001b367c41da68e0000000000000000000000000000000000000000*0x3e8 (1000 in decimal)
targetPerMillisatoshi: 0000000006a4cd5613d29ab00000000000000000000000000000000000000000
On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Howdy, welcome to day 15!
Today's post covers a form of a mining pool that can be operated as sort of a map-reduce over blocks without any "infrastructure".
https://rubin.io/bitcoin/2021/12/12/advent-15/
There's still some really open-ended questions (perhaps for y'all to consider) around how to select an analyze the choice of window and payout functions, but something like this could alleviate a lot of the centralization pressures typically faced by pools.
Notably, compared to previous attempts, combining the payment pool payout with this concept means that there is practically very little on-chain overhead from this approach as the chain-load
for including payouts in every block is deferred for future cooperation among miners. Although that can be considered cooperation itself, if you think of it like a pipeline, the cooperation happens out of band from mining and block production so it really is coordination free to mine.
Cheers,
Jeremy
--
@JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211213/a6680906/attachment.html>

2023-06-07 23:00:12

- reply

📅 Original date posted:2021-10-17
📝 Original message:> Then starting at Unix Epoch 0x80000000, post-softfork nodes just increment the timestamp by 1 on each new block.
It is possible to go even faster. The fastest rate is something like that, if you assume the time in the Genesis Block is zero:
0 1 2 2 3 3 3 3 4 4 4 4 4 4 5 5 5 5 5 5 6 ...
Then you can increment timestamps once per 6 blocks, that means x3600 increase, but then the difficulty is always multiplied by four, so you have to increase time once per difficulty change to keep it on real level, then it will wave between being multiplied by 4 and by 0.25.
On 2021-10-17 01:23:24 user ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning vjudeu,
> > 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
Then starting at Unix Epoch 0x80000000, post-softfork nodes just increment the timestamp by 1 on each new block.
This just kicks the can since that then imposes a limit on the maximum number of blocks, but at least the unit is now ~10 minutes instead of 1 second, a massive x600 increase in the amount of time we are forced to hardfork.
On the other hand, this does imply that the difficulty calculation will become astronomically and ludicrously high, since pre-softfork nodes will think that blocks are arriving at the rate of 1 per second, so ...
Regards,
ZmnSCPxj

2023-06-07 23:00:10

- reply

📅 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

2023-06-07 23:00:08

- reply

📅 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

2023-06-07 23:00:06

- reply

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

2023-06-07 22:59:59

- reply

📅 Original date posted:2021-10-15
📝 Original message:On 2021-10-15 03:05:36 user Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Same stuff works with testnet, though I'm not sure if any testnet faucets
will accept bech32m addresses directly.
There are faucets that accept such addresses, for example https://bitcoinfaucet.uo1.net/, but you have to use bech32 checksum instead of bech32m, for example sending to tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aqus27cytz works fine, but sending to tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aquslzggwq does not work. The same with pages like mempool.space, you have to use bech32 instead of bech32m, then you can send to taproot from some old faucets or browse taproot addresses from some old block explorers.

2023-06-07 22:59:10

- reply

📅 Original date posted:2021-09-12
📝 Original message:You can do that kind of change in your own Bitcoin-compatible client, but you cannot be sure that other people will run that version and that it will shut down when you want. Many miners use their own custom software for mining blocks, the same for mining pools. There are many clients that are compatible with consensus, but different than Bitcoin Core.
Also you should notice that Bitcoin community make changes by using soft-forks, not hard-forks. Backward compatibility is preserved as often as possible and there is no reason to change that. Any change can be deployed in a soft-fork way, even "evil soft-forks" are possible, as described in https://petertodd.org/2016/forced-soft-forks. I think that kind of soft-fork is still better than hard-fork.
On 2021-09-12 21:16:00 user James Lu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
If MTP-11 is greater than 5 years after the release date of the current software version, the full node should shut down automatically.
This would allow writing code that gives the community ~5 years to upgrade to a version that executes a new hard fork while keeping everyone in consensus, provided the change is non-controversial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210912/4805d7b0/attachment.html>

2023-06-07 22:58:48

- reply

📅 Original date posted:2021-09-12
📝 Original message:> - 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
Anyone can do 1 block reorg, because nonce is not signed, so anyone can replace that with better value. For example, if you have block 00000086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with 0x0007f4cc nonce, you can replace that with 0x00110241 nonce and get 000000096a1c4239d994547185c80308a552cba85d5bd28a51e9dc583ae5eadb block, where everything is identical, except the nonce.
Sometimes that reorg could be deeper if you would be lucky enough to get a block with more work than N following blocks combined.
On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> The reorg-interval X very much depends on the user's needs. One could
> argue that there should be, for example, three reorgs per day, each 48
> blocks apart.
Oh, wow, I think the last suggestion was every 100 blocks (every
~16h40m). Once every ~8h sounds very convenient.
> Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day.
And also for there to reliably be reorgs when they're not awake, which
might be a useful thing to be able to handle, too :)
> Developers don't
> need to wait for, for example, a week until they can test their reorgs
> next. However, too frequent reorgs could hinder other SigNet users.
Being able to run `bitcoind -signet -signetacceptreorg=0` and never
seeing any reorgs should presumably make this not a problem?
For people who do see reorgs, having an average of 2 or 3 additional
blocks every 48 blocks is perhaps a 6% increase in storage/traffic.
> # Scenario 1: Race between two chains
>
> For this scenario, at least two nodes and miner scripts need to be
> running. An always-miner A continuously produces blocks and rejects
> blocks with the to-be-reorged version bit flag set. And a race-miner R
> that only mines D blocks at the start of each interval and then waits X
> blocks. A and R both have the same hash rate. Assuming both are well
> connected to the network, it's random which miner will first mine and
> propagate a block. In the end, the A miner chain will always win the race.
I think this description is missing that all the blocks R mines have
the to-be-reorged flag set.
> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?
Super interested in input on this -- perhaps we should get optech to
send a survey out to their members, or so?
My feeling is:
- 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
- 2-3 block reorgs: good for testing the "your tx didn't get enough
confirms to be credited to your account" case, even though it barely
ever happens on mainnet
- 4-6 block reorgs: likely to violate business assumptions, but
completely technically plausible, especially if there's an attack
against the network
- 7-100 block reorgs: for this to happen on mainnet, it would probably
mean there was a bug and pools/miners agree the chain has to
be immediately reverted -- eg, someone discovers and exploits an
inflation bug, minting themselves free bitcoins and breaking the 21M
limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
bug that splits the chain, and the less compatible chain is reverted
(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
or something similar. Obviously the bug would have to have been
discovered pretty quickly after it was exploited for the reorg to be
under a day's worth of blocks.
- 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
getting >50% of miners organised took more than a few hours. This will
start breaking protocol assumptions, like pool payouts, lightning's
relative locktimes, or liquid's peg-in confirmation requirements, and
result in hundres of MBs of changes to the utxo set
Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
special fire-drill event, perhaps once a month/quarter/year or so,
in some pre-announced window?
I think sticking to 1-6 block reorgs initially is a fine way to start
though.
> After enough testing, the default SigNet can start to do periodical
> reorgs, too.
FWIW, the only thing that concerns me about doing this on the default
signet is making sure that nodes that set -signetacceptreorg=0 don't
end up partitioning the p2p network due to either rejecting a higher
work chain or rejecting txs due to double-spends across the two chains.
A quick draft of code for -signetacceptreorg=0 is available at
https://github.com/ajtowns/bitcoin/commits/202108-signetreorg
Cheers,
aj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev