I think BIP-119 is the most popular covenant-proposal, but I'm not sure about its efficiency comparably to the rest.

I don't know which one is the safest and most efficient, but I've noticed people to propose enabling OP_CAT lately, which can incidentally allow covenants to be implemented: https://bitcoinops.org/en/newsletters/2022/05/18/#when-would-enabling-op-cat-allow-recursive-covenants. In Liquid, they've enabled OP_CHECKSIGFROMSTACK, which is said to be more efficient than OP_CTV: https://blog.blockstream.com/tapscript-new-opcodes-reduced-limits-and-covenants/.

Your insights would be appreciated.

Covenants (when proposed).

Really bad decision to use TrustWallet. The red flag is in the name.

Sorry for your loss.

$67,130

There is nobody raising the fees apart from the natural law of demand and supply. A mining pool can decide to not mine any transaction paying less than 10 sat/vb as a policy of theirs, but these transactions will eventually be mined by other mining pools that don't like throwing their income to their competitors.

The problem is simple: You need to ensure those securing the chain will always have the incentive to do so, and the only ways to practically accomplish it is either by relying on transaction fees, or by subsidies. Bitcoin is capped at 21 million, therefore it has to rely on transaction fees. This means that being congested should be embraced, not criticized.

Έτσι όπως πάει καλύτερα να πάρεις ένα φθηνό Thinkpad από Ebay παρά RPi. Βέβαια αν θες οικονομία ρεύματος δε το συζητάμε, Raspberry.

One year after, let's see what has changed.

• The Ark overview has now changed to the following link: https://arkdev.info/.
• In June 4th (last week), Ark Labs launches to develop the very first Ark client: https://www.theblock.co/amp/post/298343/ark-labs-launch-bitcoin-layer-2-payments-network.
• Ark v2 has been introduced: https://brqgoo.medium.com/introducing-ark-v2-2e7ab378e87b. I recommend you to read the previous introduction (v1) in here: https://brqgoo.medium.com/introducing-ark-6f87ae45e272.
• Roadmap has been published: https://arkdev.info/docs/roadmap
• A less technical explanation of Ark has been recorded in a BitDev conference: https://bitcointv.com/w/iSg88hQLVGKicujZQvvYc6.

If and when implemented via a softfork, covenants will enable non-interactive use of Ark, meaning users do not need to be online constantly to send and receive satoshis. However, Ark can also be implemented without covenants (cl-Ark), although it will require interactivity as an disadvantage, so we better support the upcoming softfork.

This is precisely my point. If we are billions, then we can't all fit by making on-chain transactions on a daily basis. This is true for 4 MB blocks as much as it is for 40, or for 400 MB. It is only a matter of time before these sizes become considered insufficient as well, and we need to go even higher than that.

And this is the good scenario. For if the adoption (or demand for on-chain transactions) does not follow the block's capacity increase, then the network will not be sufficiently self-sustainable.

I agree, but you know what they say. The best argument for 4 MB block size is that we already have 4 MB block size. I would rather have something close to 20 MB, so that the network could be less hostile to people who just want to make on-chain payments, but political issues will arise. It'd give Bitcoin some "breathing space" until the softforks, though, I agree it wouldn't harm (apart from politically).

"Should" is a complex and problematic verb. One person's actions impact another. If you think about it, your transaction occupies the space another person could use. It might sound exaggerated, but your freedom to make on-chain transactions directly influences another person's freedom to do the same. Just because something is considered a "human right" or "privilege" doesn't mean it comes without a cost. Dictate who should bear that cost, and you've essentially created a government.

Second layer solutions aim to minimize your influence on others' freedom as much as possible. That is the goal, in my view.

Storing arbitrary data is not attractive in general, be it in 256-bit chunks or otherwise. It's expensive and inefficient. People who permanently want to store their garbage will find the way to do it.

Being programmable is the beauty behind Bitcoin. Without Script, sidechains and Layer 2 solutions would not be possible, and the system wouldn't be able to scale. And not only that. Nearly every change would require a hardfork. Being programmable provides the flexibility to support the creation of solutions that have yet to be conceived.

Or, read this: https://bitcointalk.org/index.php?topic=195.msg1611#msg1611.

Apparently, some "Bitcoiners" will praise for anyone who will pump their bags. Be it Trump for donations, Elon Musk for Tesla, or Larry Fink for an ETF.

Might be controversial nowadays, but criminals receiving Bitcoin payments is absolutely normal and expected, because Bitcoin is for everyone, including criminals. So, the short answer is yes. We do want Bitcoin to have the image of being used by criminals, if that's what it takes for it to be accessible to everyone.

Frankly, I don't care. If I see something wrong, I'll speak up. End of story.

The average transactions per second is not equivalent to the capacity. Capacity is the maximum transactions it can handle per second, and it's more than 65,000, just google "visa transaction capacity".

And you're both missing the point. Visa can increase its capacity if there is a need for more than 65,000 transactions per second because it is a single, centralized system. Decentralized systems do not function this way. This is intended to be a "peer-to-peer cash system", remember? Clients must verify everything.

Beyond that, let's not repeat the same arguments about the burden of running a node. I'm focusing on the economic aspect of small block sizes. If you want to compete with Visa, you need gigabytes of block size. If you recognize the sustainability issues that arise from "scaling" to gigabytes of block size, you need to stop comparing it with Visa and find another way to scale the system.

Wrong. You can create transactions that have arbitrary data. It's nowadays called "spam".

So, is 80 MB the ideal size? Or should it double with every halving? I can't keep up with the changing goalposts!

---

Try taking a shot every time we've made this conversation and you've made your Friday night.

I'm using numbers close to what Satoshi envisioned: https://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html.

1.4 billion transactions per day is pretty reasonable guess for the global reserve currency. Visa processes around 65,000 transactions per second. That's more than 5.6 billion per day, and that's Visa alone.

I want from Bitcoin to be able to scale to those numbers through the development of L2 solutions. You want it to not be able to even achieve a small fraction of what Visa achieves. Who wants the best for Bitcoin?

Edit: Sorry, I forgot I was talking to the person who thinks LN isn't Bitcoin.

Correct. If 1000 median transactions currently pay 1 BTC in fees, then each pays 100,000 sats. The miner would be equally satisfied if 10000 median transactions each paid 10,000 sats, or if 100M transactions each paid 1 sat.

The problem is that you can't be certain there will be 100 million transactions in each block. If you're wrong, you cannot be held accountable. If there aren't 100 million transactions every 10 minutes, then you're off and your system is not sustainable over the long term.

If the block size is 4 MB, then there is fee market competition, because there are more than 4 MB in total data broadcasted every 10 minutes on average. If you rise the block size to 1 GB, then you kill this competition, and now transactions can pay as little as 1 sat each. (Assuming the mempool's size is less than the block size limit)

Killing the competition is the equivalent of killing the miner's income from collecting transaction fees, which is directly related with the hashrate.

The abundance in information processing and generation should underline how important it is for you to own what machines cannot produce arbitrarily and seemingly "out of thin air".

Buy Bitcoin.

The fact that you think the small block size is solely a matter of technical obstacles proves my point. It isn't just a matter of bandwidth, latency and throughput. It's an economic problem. Bitcoin relies on transaction fees, not on subsidies. Therefore, there has to be fee market competition, or else you're risking with the long-term security.

If you rise the block size by a factor of x, then you should expect that the on-chain volume will rise accordingly, otherwise you're off.

Which proposal did you read?

I know. I have work to do and I'm addicted to making songs two days now.

Rise of AI, summed up in one sentence.

In almost every way. 

I present you... Oh-Wall Observer.

Wall Observer, hear our call,
Tracking charts, through rise and fall,
Bulls and bears, we stand tall,
In this realm, we're giving our all.

Need help with the lyrics. 

“Facts are stubborn things, but statistics are pliable.” -- Mark Twain

Scalability will emerge from sufficient transaction compression. This could mean to have multiple bidirectional channels within just one UTXO. To achieve this, we need to introduce a kind of script program called covenant. It requires a softfork, and softforks usually take a lot of time to activate and get sufficient support. These are the kind of L2 which cannot be implemented currently, i.e. Ark.