You can get it directly from your node, for example:
This command will print totalDifficulty for each block. You can save it to some text file and draw some chart using Excel or any other software.

Now, in the Lightning Network, all transactions are stored by all parties that have some open channel between them. There is a need for watchtowers, sometimes some payments are impossible to route because of too low amounts on "proxy peers". How it will turn out if we put all of this stuff on a sidechain? On Bitcoin, there still will be two transactions: one depositing coins into the sidechain and another, withdrawing them. Both can be constructed in the same way as in LN.

Currently, in the Lightning Network, nodes have to be online 24/7, all the time, because in other case someone could send some older transaction and close the channel with older account balances that it should be closed. If they cannot be online, they have to use watchtowers. In the sidechain, there will be no need for using additional watchtower, because every sidechain node will act as a global watchtower for the whole network, as it is organized in Bitcoin when you can send on-chain transaction and wait for confirmations.

The routing problem will be solved by creating different closing transaction. If Alice and Bob have some channel, but Alice wants to send coins to Charlie, which for example uses only on-chain Bitcoin coins, then all that is needed is creating a bit different closing transaction, taking Alice and Bob coins as an input and at least three outputs that could be spent only by Alice, only by Bob and only by Charlie.

Is OP trying to implement tx cut-through? It is closer to that idea than to LN...

This article explains it well: https://nakamotoinstitute.org/mempool/hyperbitcoinization/

But still, that's not always the case. I am mining some CPU-based coins and there I can see the opposite: the BTC price in fiat increased and CPUchain price in BTC (sic!) goes up. So, it really depends on the market, some alts dropped, but some unexpectedly raised.

1. CPU withdrawal is hanging for 5 days, still unconfirmed.
2. After clicking "orders" button I always get 404 page.
3. BTC faucet timer never stops, so I cannot get any coins out of it.

I also have many doubts, for example will there be any replay protection? Because there are thousands of blocks mined after block 388,000. Some of them used argon2d, some used RandomX, if they will be replayed on "luck2", it will cause a lot of damage!

N-of-N multisig is too much disagreement when N is big, like one thousand, one million or more, one person rejecting to sign can destroy the whole concept. If you want to use CPU for mining Bitcoin, it is better to find some cloud miner, lock some funds in 2-of-2 multisig Lightning Network channel and then you and the cloud mining service both put the same amount of coins in such address. It can be one-direction channel where you can receive some rewards for your shares in single satoshis. If there will be many users, it may be profitable, but expect rather 1/1000 th of satoshi payments (or even less if needed, since when going off-chain we can split the coin to even smaller parts as needed in the future).

Why? We have OP_ADD that can add two numbers, so we can simply add two seeds and then hash the result. Nobody knows other party's seed, so it is safe to do so. Of course it is only a kind of thought experiment to explain what we can do if we would have unlimited script. For now I think that by having 2-of-2 multisig we can get exactly the same as by any script or any opcode we can introduce to make trustless betting and it won't be any better than that.

We don't need it. By using OP_SHA256 on some number we can get some hash. All that is needed is checking if it is greater/less than some other number pushed on the stack. The exact number depends on house edge, amount being placed by both parties and in general casino and player can choose any target here. There is not that much different than calculating some number in range from 0 to 10000 and checking if it is less/greater than some number, just the numbers have more hex digits and are calculated in different ways allowed by the Script, that's all.

Why? Player and casino work together to choose the inputs, the outputs and the amounts of the same transaction. Both parties have to sign the whole transaction and agree upfront on the whole bet. If they don't, then transaction won't be created, because it needs signatures from the casino and from the player. They also decide what should be the target number and if the hash of the (for example sum) of the seeds should be above or below the target (so is the player betting HI or LO), what amount should be locked in the winning address and how likely it should be to win it by the casino or by the player.

Both parties can reveal hashes of their seeds. If anyone won't reveal its seed, then funds will be frozen on the winner's address forever. That's the same what will happen when they send these coins to 2-of-2 multisig address and the loser refuses to sign the transaction in favour of the winner. Funds have to be frozen to make sure they are assigned to the winner.

But then this transaction will be confirmed and there will be no way of changing anything.

It should be possible to know the result of the bet without being able to get the reward. Without signature there would be a problem to determine who should show its seed first. By having signatures, any party can do it safely, because there is no way to get the reward without being the winner, even when having both seeds.

It is still better than in currently existing centralized solutions when casino can disappear just like that and get the funds from the player. It is of course possible to replace 2-of-2 multisig with some kind of 2-0f-3 multisig, but then a lot of trust is put into some escrow service that may or may not be honest. By freezing the funds, both players are incentivized to remain honest, as they both lose if they stop cooperating: the winner will lose the coins, but will have the proof that somebody was dishonest, so the loser will lose some reputation. And everyone else's coins will be worth more, because these coins will be thrown out of circulation.

What do you think about BIG CoinJoin transactions? For example as big as adding one more input or output would exceed the maximum block size, so the newly mined block will finally contain nothing more than one huge CoinJoin transaction.

I didn't think mainly about deanonymization, rather I thought about confirming more transactions per block without increasing the maximum block size. It could be especially useful when we have something like this in mempool:

A -> B -> C -> D -> E -> F -> G

Then, the miner could create a "CoinJoin proposal" like this:

A -> G

And if A will sign it, the miner will save some space. If not, the miner could propose something else, for example:

A -> B -> G

Of course, when we have N transactions in mempool, there are 2^N-(N+1) possible combinations of such "CoinJoin proposals". To avoid spam, we can add some nonce and difficulty to them (since such proposals are "not-yet-signed-by-all-participants" transactions). And if the miner won't collect all needed signatures, it can still use the original non-CoinJoin transactions.

Co prowadzi do odkorkowania mempoola, ponownego odzyskania dominacji przez BTC, spadek kursu sprawia, że wszyscy uciekają z powrotem do króla krypto i historia rozpoczyna się od nowa. A jeśli opłaty on-chain wzrosną do niebotycznych rozmiarów, no to cykl pozostanie ten sam, jedynie ludzie będą wracać do LN-BTC, ewentualnie do jeszcze niższych warstw w przyszłości.

Tak czy inaczej, pytanie postawione wcześniej jest cały czas aktualne: co zamiast? Dopóki ktoś czegoś nie wymyśli, to będzie tak, jak obecnie. Nawet jeśli odpowiedź na to pytanie brzmi zdaniem niektórych "po prostu zwiększcie rozmiar bloku", to wciąż: to musi pójść przez jakiś soft-fork, nie ma innej drogi wprowadzania zmian na BTC. Oryginalny blok ciągle będzie miał limit 1 MB, nawet jeśli do niego będzie doczepiony blok segwit-future-version o rozmiarze 1 GB.

If that "elthree" is centralized, then yes, sure. But if you want to use your "elthree" across many exchanges or across any parties, then that thing should be somehow standardized and it should have an option where you control your funds all the time. For example: you can do "eltwo" by depositing funds to exchange (instead of channel opening), trading (instead of "eltwo" transactions) and withdrawing them (instead of channel closing). Is it "eltwo"? Yes, it is on the same level as LN. Is it centralized? Yes. You cannot control your coins directly and that's the difference between "globally recognized and standardized elthree" and "exchange/wallet centralized elthree". The former will be created, the latter exist today in custodial LN wallets.

That is the only option, because in other cases some nodes will receive payments and others do not. And that's not how it works: you have a route from A to B and this route as a whole is either completed or not. If it is completed, then fine, every node updates its closing transaction. But if there is any problem at any point of this transaction chain, then everything is rolled back to the state as if that payment from A to B was never started. If some node will try to use any state of "half-baked coins", then some penalty transaction will be broadcasted by some other node.

If you have message hash (z) and signature (r,s) and you know that r.x is the same as your public key, then you can restore k and create any signature you want. There is no need to modify previous solution.

If you know some public key and you know r value of the signature, then you can always check is it the same or not, so you cannot remove that information from your challenge, unless you change it to some value where these two values are not related at all.

Technically, it is possible, but you have to force that on all of your nodes (and it wouldn't work for other LN nodes). You can always deposit some coins to some 2-of-2 multisig address and never generate channel closing transaction. But, the consequences are, that nobody will be able to touch that coins alone, then both parties have to be online and agree on channel closing to do that. In case of peers that don't trust each other it is unacceptable, but if you really want that feature, you can technically get it, if you want to disable uncooperative channel close.

It seems to be quite simple:

z=message
r=signature_pubkey_x
d=privkey
k=signature_privkey

s=(z+rd)/k

d=k
s=(z+rk)/k
s=z/k+r
s-r=z/k
1/(s-r)=k/z
z/(s-r)=k

Yes, we have that kind of network and it is called regtest. The difficulty is at the lowest possible level and you can mine the whole coin supply in no time.

1. Start two nodes. If you want to use GUI, you can run bitcoin-qt in regtest mode. You need one node as a server, your second node can be a client, just choose different folder when starting it.
2. Open console and connect both nodes:
You should see one connection in the bottom right corner.
3. Generate one block to be synchronized with the network:
4. Run your miner, for example cpuminer by JayDDee and start solo mining:

So, what is the content of this error message?

W taki, że został oskarżony o działanie niezgodne z prawem i miał przez to kłopoty, gdyby nie to, no to pewnie nadal by można było kupić jego monety z fizycznymi Bitcoinami w środku. Po prostu gość został zmuszony do zaprzestania umieszczania fizycznych BTC w swoich monetach. Tutaj spodziewam się, że może być podobnie, chyba że ktoś się pokusił o przejście wszystkich prawnych procedur wymaganych do takiej działalności.