i'd like to share my opinion on a controversial topic and see what are the thoughts of bitcoiners here.

the taproot soft fork was pushed too fast, unlikely past soft forks with over 95% of consensus.
now it will have unintended consequences both for bitcoin layer 1 and layer 2:

on layer 1, with the introduction of ordinal, now bitcoin's blockchain is getting bloated with useless jpegs, nfts, and it could possibly become worse: child porn, porn in general, violent images, death threats, images that aim to dox someone, etc. Politicians, legislators and other state parasites will try to use it as an excuse (regardless of whether it makes sense) to arrest people whom they don't like under the claim of "sharing, transmitting child porn and other illegal content". It does not matter if (1) you didn't put the image there, or if (2) the image can only be displayed special software that can read, parse and understand Inscriptions (or other silly protocol) so that what is there is just a bunch of bytes unless you have the proper software. None of that will mater if they want to starting arresting people to use bitcoin (of course this will not be the end of bitcoin, it will continue to exist, but certainly will be bad for many people).

on layer 2, there is this horrible proposal called TARO, which makes use of taproot and pretends to bring digital assets to the LN, such as stablecoins, arbitrary tokens, nfts, etc. That way, people would be able to use the LN infrastructure to relay metadata of those digital assets, allowing folks to issue their shitcoin on LN. The LN protocol is decentralized, permissionless and anyone can use it without making the LN node public available or without revealing that you are actually using it, or with whom. It does not matter though: for regulators, it does not matter what you are using it for, they will say you are "operating money transmitter services" without a license, etc. Bring stablecoins (aka, shitcoins, fiat coins) to LN goes against the purpose of Bitcoin. If TARO enables that (as promised), it will just be another excuse for regulators to chase bitcoiners, node operators, and anyone using LN. Again, this will not be the end of LN, which is decentralized and will continue to exist, but this will cause harm to many.

we would be better off undoing taproot via a fork with at least a 95% consensus threshold of full nodes and miners. This would probably take some years to implement a safe code to undo/block taproot; in the meantime, we would have to tolerate taproot in the blockchain.
Also, I think these kinda of softforks should not happen anymore. Only forks that fix bugs, fix vulnerabilities, enhance security, but not forks that "add cool features".

What bitcoin proposals do you regard as controversial or even harmful ? And why?
These proposals can be both at layer 1 or at above layers (ex: TARO on LN)

For example, I've seen people being strongly opposed to proposal such as covenants and drivechains. I'm don't have a stablished opinion on them, so I'd like to see others' opinions on the topics, be it positive or negative.

I'm starting to notice moderate tension on some bitcoin communities i participate in (twitter, telegram, youtube) regarding proposals to change bitcoin (those 2 topics, as well as other ones) and to extend it on above layers (ceticism regarding lightning network and liquid network, heavy critics to TARO protocol). After reading Blocksize War, it kinda felt that in 5-10 years we could have another "civil war"

I think we need a strong social layer of cautious bitcoiners that are able to resist code changes that promote hidden agendas and could possibly harm bitcoin in the long run. To do so, those with technical knowledge should openly debate the pros and cons of proposals to change/improve Bitcoin (be it at layer 1, be it at layer 2,3,...) so that lay people can be more informed to take decisions. The success of bitcoin ultimately depends not on the success of layer 1, but on the strength of layer 0, the social layer (bitcoiners, node operators, miners, developers, educators, end users, etc...)

> You do not have to be a lightning node operator before you can open a channel. You do not have to be a node operator also before you can use lightning network for making transaction

Yes, this is true, you can use LN without opening channels, by using someone's else channel. But if you are not running your own node you don't have control over the funds and you are relying on a thirdy party. It is the equivalent of letting funds on a exchange. The saying "not your keys not your coins" is for bitcoin layer 1, while for layer 2 it would be "not your [LN] node, not your coins"

Most bitcoiners would agree that it is desirable for Bitcoin's decentralization that we have users running their own Bitcoin full nodes and, now with advances of second layer solutions, to run their own Lightning Network nodes. Today a normal person can open LN channels and be a node operator, which is very good because the LN protocol is decentralized and we can reach more autonomy running our own nodes.

One of my concerns is that fees on the Bitcoin network could become very high and that it would be very costly for normal users to run their own LN nodes since to open channels it requires an on-chain transaction. Moreover, if the fees are too high then it would increase potential risk of malicious attackers in a disputed close because a "justice transaction" is an on-chain transaction, which can be costly for the honest party trying to legitimately reclaim the funds in a disputed close. This could make LN and other layer 2 solutions quite centralized in the future since normal users wouldn`t be able to have their nodes...

Is this really a plausible concern for the next years/decades? How could that problem be mitigated?

thanks for all the answers!

it really shed light into some deeper issues I hand't think about

Thinking more carefully, $1 for satoshi is a very high price even in the long term.
As a bullish bitcoiner, I guess we may reach $0.1 for satoshi considering the purchashing power of the dollar today. I say "considering the purchasing power of the dollar today" because all fiat currencies tend to severe devaluation in the long run, which means that $100 in 100 years could be worth less than $5 today.

Anyway, I don't think there would be a need for bitcoin to be more divisible in the next decades.
Moreover, it would be a complete mess to try to make bitcoin more divisible because the software would have to handle past transactions and future transactions differently, introducing a lot of complexity.

Thank you all for the answers. It clarified my doubes

I understand that one satoshi is very small and for one satoshi to reach $1 a single Bitcoin should be worth over $100 million, but what if that really happens in 30 years or more? If Bitcoin succeds in the long term, this is plausible.

The bitcoin in the transactions on Bitcoin's timechain (aka blockchain) is in satoshis. If you inspect a block, you will find out that all value transfers are measured in satoshis. Currently, there is no way to own a fraction of a Satoshi. It is not possible to own a fraction of satoshi on Bitcoin layer 1 right now because other nodes of the network will reject any transaction that do not comply with the protocol standards (which is to measure value in satoshis). So, if you try to do some fancy thing to own a fraction of a satoshi, it will be reject by the network participants. It seems to me that if one day we need to own a fraction of a satoshi, this could only be done through a hard fork... this is not something we have to worry for the next years, but could be a problem in some decades. This concerns me

Imagine the following scenario (that could possibly occur in decades):

Bitcoin becomes widely adopted, its marketcap surpass the dollar's, and it become so valuable that even a single satoshi is worth more than, for example, a couple of pens, a bottle of water, etc.

In that case, payments for small amounts wouldn't be possible even with second layer solutions such as LN, because even a single satoshi would be more valuable than the price of the product. There would be a need for Bitcoin to be more divisible, for it to be broken down into even smaller parts.

Would such need to use smaller denomination units (smaller than satoshi) require a hard fork? Can someone shed some light into it?

> It is possible. It is called "Silent Payments" and is work in progress: https://bitcointalk.org/index.php?topic=5400363

Thank you! That's very interesting!

> OP_MUL and OP_MOD are disabled opcodes - you can't use them in scripts because their evaluation by the interpreter will abort the script immediately and cause permanent fund loss.

Yes, I pointed that out in the post

> You are talking about Stealth addresses generated by C = (G*a)+B and C = (G*b) + A formulas, right? You don't need fancy scripts to spend to them - they are regular public keys which can be hashed into a Legacy, SegWit, or taproot address, or any other future address, and their respecive scripts can be used.

To be sincere, I didn't know about stealth addresses when I first came up with this scheme, only knew about them later. I don't know about those formulas you mentioned;
can you please suggest me some reading?

Also, as far as I know, the Legacy, SegWit and Taproot address formats do not provide the level of privacy suggested by the scheme. For example, if Alice publishes her Legacy/SegWit address on the internet to receive, i.e, donations, them everyone can see how much Alice has got by checking the public address on the timechain. On the other hand, in the scheme I suggested, the sender Bob does not use an address to send Bitcoin to, rather it generates a random nonce that nobody else knows, thus obfuscating the fact he sent the Bitcoin to Alice. Not only that, when Alice goes spend that Bitcoin, she does not reveal that it is she who is spending the Bitcoin. Please correct if I'm wrong, but from what I have studied it is not possible to achieve this level of privacy with legacy, segwit or taproot.

> Since adding OP_MUL and OP_MOD  OP codes anyway requires conducting a hardfork, it would be better to implement more sophisticated privacy-enhancing tools like ring signatures, confidential transactions, or anything else that hides senders and receivers and the amount transferred. But if it could be possible to hardfork bitcoin every time there is a "useful" update or interesting method to improve on-chain privacy, bitcoin would be no better than Ethereum, which is already almost taken over by large corporations and governments.

I agree with you. A hardfork is not an option. The immutability of the protocol is more desirable than rich features, even privacy features. However, if we can improve Bitcoin without causing hardforks, without introducing vulnerabilities, without compromising decentralization, then we should strive to do so.

> I see another problem with this scheme - the script size in bytes is too large. I'm counting two 64-byte pushes (n and k) along with some half-dozen opcodes - that's approximately 130 bytes of script size. This is multiple times larger than standard script types (P2[W]PKH is about 23 bytes, and P2[W]SH has an almost equal byte size). Inputs like these will fill up the block size limit very quickly, because you are basically reducing the number of transactions in a block by a factor of 6 if everyone goes on to use Stealth addresses which of course won't happen, so the reduction will be less but still significant - think a 2x or 3x reduction in transactions-per-block.

This is true, specially because in the draft I used RSA encryption, but there are nowadays encryption standards that allow shorter and more secure encryption and signatures schemes. My goals was to show a proof of concept; some real solution needs to be practical (i.e, fewer bytes, secure enough)

> Thanks for sharing. Maybe I'm missing something, but other than implementation challenges, I suspect this scheme is vulnerable to miner theft as once it goes to the mempool, miners can take it and replace the output with theirs. It is because the transaction is not signed, hence forgery is not prohibited.

That's true. Thanks for pointing that out. I didn't realize that... I thought the scheme was pretty useful because allowed one-time address to be generated by the sender on the fly, but now I see the scheme is useless since anybody monitoring the mempool can forge the script. I will see if I can come up with something to tackle that

Hello there,

I'd like to share a scheme to improve the privacy of on-chain Bitcoin
transactions, without requiring changes in source code (can be done using
scripts)

The scheme I will present is based on RSA cryptography, but I bet someone can
suggest a better variation of it using better encryption protocols.

SCHEME

1. Alice generates a RSA key pair (s, p, n), where s is the secrete key, (p, n)
is the public key, and a^(sp) = a mod n for any a<n.

2. Alice then picks a random large number 1<S<n and computes B=S^2 mod n. Alice
wants to receive Bitcoin, so she shares (p, n, B) to Bob.

3. Bob chooses a nonce k and compute k' = k^p mod n, k'' = B^k mod n.

4. Bob then sends bitcoin to Alice using the following Bitcoin script for
authorizing Alice to spend her coins.

k` OP_DROP k'' OP_EQUAL

5. Alice finds out Bob's tx on the timechain,
then uses k' and her secrete key s to calculate k = k'^s.

6. Alice computes S^k mod n using k obtained in previous step.

7. Alice spends her bitcoin using the following bitcoin script:

S^k OP_DUP OP_MUL n OP_MOD

Let's see why this works. When Alice wants to spend her Bitcoin, her and Bob`s
script will be concatenated:

S^k OP_DUP OP_MUL n k` OP_DROP OP_MOD k'' OP_EQUAL

Then, this will happen:

Stack             Script
                  S^k OP_DUP OP_MUL n OP_MOD k` OP_DROP k'' OP_EQUAL
S^k               OP_DUP OP_MUL n OP_MOD k` OP_DROP k'' OP_EQUAL
S^k, S^k          OP_MUL n OP_MOD k` OP_DROP k'' OP_EQUAL
S^2k              n OP_MOD k` OP_DROP k'' OP_EQUAL
S^2k, n           OP_MOD k` OP_DROP k'' OP_EQUAL
S^2k mod n        k` OP_DROP k'' OP_EQUAL
S^2k mod n, k'    OP_DROP k'' OP_EQUAL
S^2k mod n        k'' OP_EQUAL
S^2k mod n, k''   OP_EQUAL
TRUE

Note that S^2k = (S^2)^k = B^k = k'' mod n. That`s why the script work.

I did say it could be implemented without requiring change to the source code,
but that was before I realize the script will not work because of the following:

1. The operations OP_MOD, OP_MUL are disabled (they can no longer be used)
2. The arithmetic operations work only for 32-bit values

So, actually this scheme won`t work but let us discuss this later on because I
want to highlight some points here.

PRIVACY PROVIDED BY THE SCHEME

Currently, most people advertise an address derived from their public key, and
the bitcoins is send to the address. If, for example, Alice is a content
creator and wants to provide her audience with a public address for donations,
then all donations will go that address and will be easy to know and track the
bitcoin received by Alice.

Using the suggested scheme, each person that gets Alice's public key will not
send bitcoin to an address. Instead, the script used to unlock the Bitcoin
contains data that does not reveals those bitcoins are being sent to Alice.
Why? Because this script contains only k' and k'' and cannot be link to Alice
as long as the nonce k is kept secret (only the sender and the receiver know
the value of k used to get k' and k'').

Moreover, when Alice goes spend her bitcoins, it does not reveal that she is
spending it because she only reveals S^k, which cannot be linked to her public
key (p, n, B).

So, an outsider cannot associate a public key pair to the bitcoin that was sent
to this public key pair, neither can him associate the bitcoin to the public
key pair when the new owner decides to spend it.

DRAWBACKS

The major drawback of the scheme (which we will see a solution soon) is that in
order for Alice to know she got Bitcoin is to scan all transactions using this
scheme and check if her keys can unlock the funds. For that, she needs to use
her private key.

Nowadays, people using Legacy or SegWit address can monitor how much Bitcoin
they own just using their master public key, without needing to reveal their
private key. They can export the master public key to a not-so-trusted mobile
or desktop wallet to monitor their funds, while being sure that their private
key lies secure in a hardware wallet, for example.

This cannot be done with the scheme described above, but a small change to the
scheme makes it possible to track the funds using only the public key!

SCHEME IMPROVED

In order for Alice to monitor her funds without exposing her private key, we
propose the following scheme (very similar to the previous one).

1. Alice generates a RSA key pair (s1, p1, n), where s is the secrete key,
(p, n) is the public key, and a^(s1 p1) = a mod n for any a<n.

2. Alice then picks a random large number 1<S<n and computes B=S^2 mod n.

3. Alice picks another RSA key pair (s2, p2, n) but uses the same n as in step
1. In other words, a^(s2p2) = a mod n for any a<n. If Alice wants to receive
Bitcoin, she shares (p1, p1, n, B) to Bob.

4. Bob chooses a nonce k1 and compute k' = k1^p mod n, k'' = B^k1 mod n.

5, Bob chooses another nonce k2 and computes H=hash(k2) and I = k2^p2 mod n.

6. Bob then sends bitcoin to Alice using the following Bitcoin script for
authorizing Alice to spend her coins.

I H k` OP_DROP3 k'' OP_EQUAL

7. In order for Alice to figure out which unspent outputs Bob sent to her, she
scans the timechain and computes I^s2 = k2^(p2s2) = k2 mod n. If hash(k2) == H,
then the Bitcoin was sent to Alice. Otherwise, the Bitcoin was sent to
someone else.

8. Alice then uses k' and her secrete key s to calculate k1 = k'^s.

9. Alice computes S^k1 mod n using k1 obtained in previous step.

7. Alice spends her bitcoin using the following bitcoin script:

S^k1 OP_DUP OP_MUL n OP_MOD

Notice that (p2, s2) is used only as a way for Alice to identify which Bitcoins
belong to her without her needing to expose her private key s1. The only way to
spend Alice's bitcoins is knowing s1. The only way to know which Bitcoin
belongs to Alice`s key pair (p1, s1, 2) is eitheir knowing s1 or knowing s2.
Knowing only s2 it is possible to monitor Alice's funds.

IMPLEMENTATION

Using the improved scheme, or some variation of it (using something other than
RSA), it is possible to achieve high level of privacy on Bitcoin layer 1. As
said before, now it is not possible to implement these schemes because:

- The operations OP_MUL and OP_MOD are disabled
- Arithmetic operations in Bitcoin scripts only support 32-bit integers

Thus, the only way to implement the suggested scheme is through some BIP which
could introduce a new operation.

For example, Bob would use the following script to send BTC to Alice:

I H k' OP_DROP3 k'' OP_CHECK_STEALTH_ADDR

Alice would use the following script to unlock it:

S^k1 n

The OP_CHECK_STEALTH_ADDR would square S^k1 modulus n, then compare it to k''
and return TRUE if only if they are equal. In other words, this OP would take
a,b,c as input and return true if a^2 mod b = c.

CONCLUSION

This text proposes a scheme to provide on-chain privacy on Bitcoin layer 1. This
is just a draft that needs to be elaborated further. I'm aware that it is crucial that
any improvement does not compromise the security and decentralization of
bitcoin, so I hope my suggestion is welcomed and not seen negatively.