I have Bitcoin full node with all blocks and I am trying to forward ports, so that other people can connect with my node. I tried following https://bitcoin.org/en/full-node#port-forwarding but there are still no incoming connections. Is it possible to do with this router? What else should I check? Some images of my settings:

https://i.ibb.co/sVKyvpg/01-online-clients.png
https://i.ibb.co/09HQkwq/02-alg.png
https://i.ibb.co/B4CTm0T/03-virtual-servers.png
https://i.ibb.co/B47GYF9/04-port-triggering.png
https://i.ibb.co/G0Lpv5q/05-dmz.png
https://i.ibb.co/QNNrr2k/06-upnp.png

Is it possible to go back in time in a chain? For example, starting from 2009 is it possible to produce blocks with earlier and earlier timestamps and for example reach 2005? Or is there any strict requirement that block timestamps have to go forward? Because if there are three sources of time: local time, time from other nodes and time from block headers, if the first two will be faked, is it possible to also fake block timestamps and set any date, if the whole chain will be long enough?

I recently read topic https://bitcointalk.org/index.php?topic=382374.0 and I wonder how exactly that prenet genesis transaction looked like. After some digging I came up with this:

Code:

decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0504695dbf0effffffff01102700000000000044ab4104d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef10a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131ac00000000
{
  "txid": "25c61a7089aa96318088bcccfbc12064a18166105c20c237836704611254d2da",
  "hash": "25c61a7089aa96318088bcccfbc12064a18166105c20c237836704611254d2da",
  "version": 1,
  "size": 133,
  "vsize": 133,
  "weight": 532,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "04695dbf0e",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00010000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_CODESEPARATOR 04d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef10a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131 OP_CHECKSIG",
        "hex": "ab4104d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef10a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131ac",
        "type": "nonstandard"
      }
    }
  ]
}

Of course I know that transaction version was not present here (in the same way as in the block hash there was no version) and I can calculate sha256 of any data, but still, that transaction should hash into 769a5e93fac273fd825da42d39ead975b5d712b2d50953f35a4fdebdec8083e3. I tried using different values for OP_CODESEPARATOR and OP_CHECKSIG than 0xab and 0xac, but still no match. I tried different endianness in 32-bit and 256-bit values, but still no luck.

The only success so far was hashing the prenet genesis block:

Code:

prenetGenesis=0000000000000000000000000000000000000000000000000000000000000000e38380ecbdde4f5af35309d5b212d7b575d9ea392da45d82fd73c2fa935e9a76a00bc84814000000bb290200
prenetGenesisHash=7ae24cfad8adbe66ab2224a4f7269694fa2fa9aa157b1e44c608bd386fb6160b
prenetGenesisDoubleHash=46a6fa0cbc6e41aaebb6916c55013a0ad66b11e91d1d977ed627135db1060000
prenetGenesisFinalHash=000006b15d1327d67e971d1de9116bd60a3a01556c91b6ebaa416ebc0cfaa646

Is that lost in the past or is it possible to reconstruct that transaction as it was in prenet?

Code:

decodescript 6e879169a76e75a988ac
{
  "asm": "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_2DUP OP_DROP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "2NE2dLCZzw7nYSKaHouiSjKWHry9qXgcJyt",
  "segwit": {
    "asm": "0 b91d7ae4c9fc1edca8d16a679b2843560f50eeb78db6aa051c62d6d5b73f2013",
    "hex": "0020b91d7ae4c9fc1edca8d16a679b2843560f50eeb78db6aa051c62d6d5b73f2013",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "tb1qhywh4exfls0de2x3dfnek2zr2c84pm4h3km25pguvttdtdelyqfsqnquhy"
    ],
    "p2sh-segwit": "2NCdayxXk2GNnz3xFCDoQcdNgQFWhgh5qwP"
  }
}

Code:

[signature][publicKey][sha1image] //OP_2DUP
[signature][publicKey][sha1image][publicKey][sha1image] //OP_EQUAL
[signature][publicKey][sha1image][0] //OP_NOT
[signature][publicKey][sha1image][1] //OP_VERIFY
[signature][publicKey][sha1image] //OP_SHA1
[signature][publicKey][sha1(sha1image)] //OP_2DUP
[signature][publicKey][sha1(sha1image)][publicKey][sha1(sha1image)] //OP_DROP
[signature][publicKey][sha1(sha1image)][publicKey] //OP_HASH160
[signature][publicKey][sha1(sha1image)][hash160(publicKey)] //OP_EQUALVERIFY
[signature][publicKey] //OP_CHECKSIG
[1]

Classical mining is based on finding the smallest possible block hash. But as we know, r value of the signature can be smaller than usual if it starts with some zeros. Leaving half of the base point behind, I can imagine a system where miners collect transactions and try to find some value that can be added to "r" and can lead to smaller signatures. Users can receive such values in P2P way, because each miner can just share his "r2" public key to prove that miner found the lowest public key for that signature. Then, that user can send some satoshis in LN as a reward to that miner, and to unlock that coins, the miner have to reveal that private key for "r2" to the user. Then, that user can create smaller signature, leaving more room for other transactions in the blockchain.

Assuming one satoshi per byte fee rate and 2,000 transactions in the whole block, saving 5 bytes per transaction would mean earning 10k satoshi per block (and leaving some room for 40 more transactions 250 bytes each). Of course it is negligible for big miners, but for smaller ones it may be profitable, if they could fight for some satoshis. And the profitability limit will be quite high, because truncating five or six bytes may be profitable, but hitting eight or more will be exponentially more difficult, so it rather encourage hitting more transactions than more zeroes in single transaction.

It can be applied to any address type that involves public keys, including multisig and Segwit, because transaction fees are based on total transaction size. So, even if Segwit signatures are outside of the block, users can still pay less satoshis for including such transactions with "mined r values". Unfortunately, that kind of service cannot be applied for taproot, because that signatures has fixed size of 64 bytes, but they are compressed to single signatures anyway, so there is less need for that kind of compression.

Recently I found an interesting testnet transaction: 952656e19ce57698880ad6ada935f29ee2cae82c4e7486516908b630671dd84b. It seems to be some kind of puzzle, but probably even the author cannot just move the coins without actually solving it (which is not the case in well-known mainnet transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15). So, if I understand it correctly, the goal is to create any address with as low 160-bit hash as possible and then take these coins. I guess it is on testnet, because of the standardness limits on mainnet. The whole change seems to be quite simple, instead of "OP_EQUALVERIFY" there is "OP_LESSTHAN OP_VERIFY".

For now, we have public key hashes as outputs and then it is needed to reveal public key and signature in inputs. But the properties of ECDSA allows us to skip this public key and by having some address and some signature, it is possible to verify it (in exactly the same way as we can type some address and signature and verify any message, not necessary being a transaction). Then, why storing public keys in the blockchain is needed if they can be safely skipped and calculated from signature and address?

Instead of sending coins to "OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG" I sent them to "OP_HASH160 <hash> OP_EQUAL". Both hashes are exactly the same. Are they burned or is it possible to get them by using some kind of non-standard transaction?

For now, there are many services that offer cloud mining. The scheme used here is as follows: at first, you deposit coins to some website and then they are showing you some growing numbers. You can withdraw funds after reaching some value, you can also stick with some free plan or purchase some paid option, that will speed up your mining, depending on this item's price.

The problem with this type of sites is that most of them are just scams, you can deposit some coins, you can even withdraw them for a few months, but then, suddenly the whole website can disappear and reappear under completely new address.

It seems that blockchain also provide solution for this type of service. Instead of depositing coins to some cloud mining address, you can send them to some 2-of-2 multisig. Then, they can make sure that funds are really deposited, but at the same time you can make sure they just don't run away with your coins. And then, they can show you some growing numbers, allowing also some purchases of mining equipment or withdrawing coins.

If you decide to withdraw some of them, you can just create a new transaction spending coins from the multisig input and all they have to do is just signing it. More than that: if they want to gain your trust and show a good will, they can periodically create a transaction that allow you to withdraw all already mined coins and they can sign it.