Is it possible? And if so, why don't we use public key hashes instead of public keys? For example, let's assume we have first two private keys:

Code:

alicePrivKey=0000000000000000000000000000000000000000000000000000000000000001
bobPrivKey=0000000000000000000000000000000000000000000000000000000000000002

Then, each party can compute its public key:

Code:

alicePubKey=0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
bobPubKey=02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5

And then, each party can compute its address:

Code:

aliceAddress=bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
bobAddress=bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp

Sending to address is enough to get it recorded on-chain. If coins were never moved, then it is impossible to know the public key. But it may be possible to create a multisig that is based on such address. For example, we can start from getting hashes for each of them:

Code:

aliceHash=751e76e8199196d454941c45d1b3a323f1433bd6
bobHash=06afd46bcdfd22ef94ac122aa11f241244a37ecc

And then, we can create 1-of-2 multisig, when revealing only one public key is needed to move the coins:

Code:

OP_DUP OP_HASH160 OP_DUP 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUAL OP_SWAP 06afd46bcdfd22ef94ac122aa11f241244a37ecc OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG

As far as I know, it should work in theory, but I still cannot confirm it would work in practice. Both paths should be spendable. For Alice, it would be:

Code:

<sigAlice> <pubkeyAlice>
<sigAlice> <pubkeyAlice> <pubkeyAlice>
<sigAlice> <pubkeyAlice> <hashAlice>
<sigAlice> <pubkeyAlice> <hashAlice> <hashAlice>
<sigAlice> <pubkeyAlice> <hashAlice> <hashAlice> 751e76e8199196d454941c45d1b3a323f1433bd6
<sigAlice> <pubkeyAlice> <hashAlice> 1
<sigAlice> <pubkeyAlice> 1 <hashAlice>
<sigAlice> <pubkeyAlice> 1 <hashAlice> 06afd46bcdfd22ef94ac122aa11f241244a37ecc
<sigAlice> <pubkeyAlice> 1 0
<sigAlice> <pubkeyAlice> 1
<sigAlice> <pubkeyAlice>
1

And for Bob, it should left "0 1" instead of "1 0" on the stack, so after addition, OP_VERIFY will succeed by consuming OP_TRUE. I am still trying to confirm that on regtest, but I think it should be technically possible to use public key hashes to make a multisig, instead of using public keys.

I tried the latest official 22.0 version. Now I know that importing taproot keys by WIF is possible, but I am getting strange results, it seems the keys are completely different than I am trying to import.

Code:

importdescriptors "[{\"desc\":\"tr(cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87JcbXMTcA)#tnrke5yz\",\"timestamp\":\"now\",\"label\":\"taproot\"}]"
importdescriptors "[{\"desc\":\"tr(cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87K7XCyj5v)#xpd75frm\",\"timestamp\":\"now\",\"label\":\"taproot2\"}]"

What was imported:

Code:

bcrt1pmfr3p9j00pfxjh0zmgp99y8zftmd3s5pmedqhyptwy6lm87hf5ssm803es
bcrt1pet7ep3czdu9k4wvdlz2fp5p8x2yp7t6ttyqg2c6cmh0lgeuu9laspse7la

What I expected:

Code:

bcrt1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqc8gma6
bcrt1pccz8l9zpa47k6vz9gphftsrumpw80rjt3nhnefat4symjhrsnmjsgkm3r6

Why my public keys from taproot addresses are not the same as in my WIF's? Also I wonder why if I want to sign my transactions offline with Bitcoin Core I have to import my keys to regtest/testnet/signet instead of mainnet if my client does not have the chain?

For now, we have 64-bit numbers for representing amounts. We have satoshis as the smallest units and we have maximum coin supply of 21 million coins. That means we need at most 51 bits to represent any amount now. In the future, sooner or later, introducing fractional satoshis would be needed. The easiest way to expand it further when we use all 64 bits is just expanding it to 128-bit or even 256-bit number, but it seems unnecessary. We already have 256-bit targets expressed as 32-bit numbers when we deal with difficulty. The same method can be used to introduce fractional satoshis: one byte could be used to allow going up to 256 times smaller amounts than now, and the rest could be used to express the shifted value.

Some examples:

Code:

21 million coins: 000775f05a074000
one satoshi:      0000000000000001
one millisatoshi: 0a00000000000001
one microsatoshi: 1400000000000001
one nanosatoshi:  1e00000000000001
one picosatoshi:  2800000000000001
one femtosatoshi: 3200000000000001
one attosatoshi:  3c00000000000001

That also means that it will be impossible to express some amounts, but it is by design, just to avoid paying 0.000000001234567890123456789012345678901234567890 BTC in single output. I think that 56 bits should be sufficient to express any amount precisely enough, and the first 8 bits just allow to shift them to the right and express smaller amounts in this way.

I know about BIP 32, but I tried to do things in a simpler way and wonder if such design is secure enough.

First, we start with some master key, in this example we use output from executing SHA-256 on empty string, in real application it would be generated randomly in any secure way, for example as it is done by OpenSSL. Because if we use it directly, we would have some public key starting with "03" prefix, so we negate the result to get all public keys starting with "02", so we can make them all 256-bit. The same we can do for every public key if we ever get "03" prefix.

sha256empty: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
masterPrivateKey: 1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc57157e388ec
masterPublicKey: 02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd

Then, if we want to get some keys from this master public key, we simply need to add some known number to it. To generate such number, we combine this 256-bit public key with 256-bit nonce and execute SHA-256 on it.

firstHashedData:

a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd
0000000000000000000000000000000000000000000000000000000000000000

firstAddedValue: db26845476a175bd67c1e2b96812ea4aaa772f401fd23edabb98155e53d6b612
firstPrivateKey: f775c011dda559a8ccc5edf0cea331253d77ca426a7f4bc9d6d4dacfabba3efe
firstDerivedKey: 02 1dbe25ac1b430b911bda0f22d11c65a6e0fcc4861ac2a56ae8e8db27fd82ebd5

secondHashedData:

a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd
0000000000000000000000000000000000000000000000000000000000000001

secondAddedValue: 6dbcfbb893a11df2abbcf8997c10da5dcf8d14a19eca8510002188bce19d7ee4
secondPrivateKey: 8a0c3775faa501de10c103d0e2a12138628dafa3e97791ff1b5e4e2e398107d0
secondDerivedKey: 02 7367ad233c2e83f265a4751219e5ff3c4d3719e0d6f3e37147ecb011441e1749

To make it more convenient, instead of incrementing nonce, we could also place some hash of SHA-256 here, for example if we have unique usernames, we could take the hash of this username (or hash of any other meaningful data). Thoughts?

Now, all blocks are sent in uncompressed form. They can be compressed by each node on their own, there are many ways of shrinking that data that could always be made losslessly, for example nonce can always be placed as four bytes in previous block hash instead of zeroes (because there always will be zeroes, 32 zero bits are mandatory). Many things are repeated in the blockchain, so if we create some new nodes, they have to download everything and validate uncompressed data. As validation take some time anyway and sometimes storage or network bandwidth is limited, maybe it is a good idea to send old blocks in compressed form, for example by making such "compressed block dump" every 210,000 blocks. In some edge cases where halving is nearby, we can wait 2 weeks before we compress blocks from last halving, just to make sure we are safe from reorgs just before or just after halving.

Now we need two transactions: first to open a channel and second to close it. We can get rid of it if all transactions will be transmitted to the network. These transactions will have low sequence number (RBF enabled) and will have lock time in the future. Instead of opening the channel, Alice will send her transaction to Bob. She will be sure that no miner will include it before locktime. When Bob will see a transaction from Alice in mempool, he can send it to Charlie in the same way. Then, we will see a chain of such transactions in mempool: Alice->Bob->Charlie. All of these transactions will have RBF enabled, so Alice can create transaction sending her coins directly to Charlie (given these two transactions as a proof any miner can see it is not a double-spending attempt and accept such replacement). She has incentive to do that, because all such transactions have to contain at least minimal fee 1 satoshi/byte to be relayed over the network. One combined transaction always will be smaller than two separate transactions, so Alice can set a bit higher fee and still get some satoshi as a reward. Miners will also have incentive to accept that, because in this way they can include more transactions in the same block getting a bit higher satoshi per byte reward.

As a result, we can reduce everything into one transaction, sending all funds to all parties. I also thought about reducing it to zero transactions, but miners probably would still want to get some fee for accepting transaction replacements and that is why at least one transaction would be necessary. This idea also eliminates the need for being online 24/7 and creating watchtowers, as all channels' state will be publicly available.