[We probably agree that all public DLTs need an incentive to verify transactions, and now I mean all transactions (even smart contracts that don't convert cryptocurrencies).]

We probably agree that all public DLTs need an incentive to verify transactions, and now I mean all transactions (even smart contracts that don't convert cryptocurrencies). So is there or can there be a public DLT that has no native token of its own to provide this incentive? I might ask even better: is it theoretically possible to have a DLT for smart contracts (such as Ethereum) and pay for transaction verification not with gas, but with a token from a completely different DLT? Like Bitcoin?

The reason for this would be quite simple: a new token would not have to be introduced, which would have to build trust from the very beginning (as with the ICO). I realize that transaction verifiers will always have to have an incentive to authenticate.

A cryptonetwork without a token, say X, could do some above-standard over Bitcoin, but we wouldn't want to make an X-coin to serve as a reward for verifiers, because then the project of cryptonetwork X would have to be big enough for the exchanges to notice. would introduce the X-coin / Bitcoin exchange pair. So we have a hypothetical DLT named X. Therefore, we introduce that some hypothetical transaction verifier on X be paid in Bitcoins.
Let's look at it specifically. I am "A". "A" sends a transaction to X's ledger to "B" in the form of a smart contract that Bitcoin does not understand. In order for a transaction to be written to the ledger, it must be verified. But the verifier does not want any X-coin, because he would have a problem with its exchangeability at the beginning of the operation. So what happens?

Let's make X an extension of Bitcoin. The very original idea was that X’s miner would be paid for in an already established token. This is a fundamentally different scenario than we see today, when new miners do not get too involved in a new project because they carry a relatively high risk. Suddenly they will knock so they can verify for the new X.

Because X has a protocol that Bitcoin does not understand, you need to have new authenticators (I thought so, but it's not true, read on). They will be motivated by paying for an already established cryptocurrency. This means that the new DLT network named X will benefit from the established trust in Bitcoin. Using cryptographic logic gates (such as those used in the construction of the Lightning Network), two DLTs can be combined (as we have seen, for example, in Atomic Exchanges).

A small number of verifiers for X, but a large one for Bitcoin, would not be a problem at all. I can imagine miners selling themselves to any DLT if they are paid out in Bitcoin. But I would still mind that I had to have two miners: a miner who would process the payout in Bitcoins to another miner on X. That sounds inefficient. But let's put that aside for now.

The introduction of new DLTs in the normal way is in principle similar to forking - a disproportionately unfavorable introduction of completely new DLTs. I understand the principle of the market, the tokens of only those DLTs that make sense will be retained, on the other hand, I do not think that this results in meaningless and continuous creation of more and more tokens.

The difference between X and forking or the classic introduction of the new DLT is abysmal: forking makes incompatible miners and shrinks the network. The introduction of a completely new DLT is again extremely risky. Therefore, here is a solution in the form of X. Recall that the reason for all this is the fact that Bitcoin cannot do some advanced operations because it does not have them logged. Because of this, the verifier does not know when to come into contact with an advanced transaction what to do and whether everyone else understands the same.

In practice, everything would be roughly done by the sender of the transaction paying the verifier X in Bitcoins, so the Bitcoin transaction will obviously contain some all-encompassing ID. A bitcoin transaction is completed only if the verifier for X publishes a new transaction in X's DLT, otherwise it could happen to verify it and get Bitcoins, but it will no longer appear on the blockchain (which is captured in the classic model, because I can not deny to a blockchain transaction and get a mining reward).

If we start to examine the added value of the verifier for X, we will simplify the whole thing. The X authenticator function can be performed by the X user himself and the transaction initiator  .

Central to this is evidence that the transaction ID in X appears on the Bitcoin blockchain. The initiator pays for this - he does not pay for the fact that he can pay, but he pays for it to solve the problem of complete disclosure or the problem of Byzantine generals, if you will. So, for example, I take a transaction for X and incorporate its ID into a Bitcoin transaction. The consensus will then be that if the shading Bitcoin transaction is in the Bitcoin blockchain before any conflicting one, then it is right. Cryptonetwork X then does not have to have its own native token. The conflict within X would be resolved according to the protocol.

Cryptonetwork thus only serves as a platform for public encryption keys aliases. Bitcoin's protocol will solve most potential problems, because it's actually enough to follow the Bitcoin blockchain where we integrated our X. If someone has a faulty transaction, it will be accepted in Bitcoin, but X users will ignore it. Of course, splits can occur in this virtual blockchain too.

The beauty is that even if you are the only user of your protocol, it will not compromise the security of your transaction at all. Imagine having the entire production process interwoven with smart contracts, electronic authentication and private key control (even if it would be damn expensive). Naturally, machines in the production process will also be able to create transactions because they have their own wallet. Machine-to-machine communication with the benefits of DLT would be implemented so that your machines understand your protocol. Sometime in the future, Bitcoin would function as a gigantic platform, where you pay for the amount of information included in the transaction (which is already partly true now).
Transactions X would no longer operate with the currency. The only API would be to interpret the Bitcoin blockchain into the X protocol language. Bitcoin would have only two functions - to put something into a public distributed database and reward the one who did it. No other things besides the P2PKH script would theoretically be needed.

If the new X were to manage ownership of the assets, I would still be able to do without a native token. This is because the asset (similar to the example above) will be interpreted by the Bitcoin blockchain and can track its own history of owners entered in the form of an account pair private-public key alias address.

With X you can make a corporate DLT (more than one blockchain), a completely private DLT or a fully permissionless DLT. All superstructure complexity is recorded in protocol X. Protocol X must be robust. Note that elementary objects (addresses) do not have to interact directly at all, as they interact virtually with each other.

So in the end, we went from complexity to total simplicity. It is possible that I overlooked something completely fundamental and it is completely useless, but not at all. Or something like that has been working for a long time. Please let me know. Thank you.

Hi everyone,
last time I thought about centralization making in decentralized networks and systems, exactly about Proof of Stake.
With PoW consensus mechanism, the users can't stop potential malicious user or group of users from simply buying their power in network via buying new ASICs because this isn't directly commited to blockchain.
By the principle you can't stop anyone buy a lot of hashing power. In this way I see PoS as the good way how to avoid this because coins in PoS which make the power can be bought only from blockchain users, so by the other words, users can decide not to make possible centralization because they do not allow selling coins to malicious users or pools. But not at all.
However, there are many ways how can centralization-lust groups hide their behavior by TOR principles, so you can think that you are selling your Ether or imaginary Bitcoin with PoS to common user, but the wallet is held by centralized mammoth. So the PoW is weak in holding too many coins instead of too many ASIC cards for mining, plus - and ironically - there isn't any way how to redistribute coins in free and decentralized manner as in PoW.
For example, state can always take control over the PoS network by anonymously buying the majority of the coins (it doesn't need to use violence, it can just use its economical dominance). There isn't any way how to recognise between institutional buyer and common buyer in the manner: No! You're Big Bro! I don't sell you 100 000 000 ETH, because you will take control over Ethereum blockchain!
By the way, if there will be any true-blockchain-decision-making mechanism, in pseudoanonymous network you can't recognize that the state is getting control over it (of course - if will the attack for getting control well distributed).
But if you assumpt, that there are only certain ways how to buy crypto if you don't have any digital coin for exchange yet, you probably can recognize it.
But clearly hypothetically, if all assets, cars and things for everyday use will be smart contract ensured, the only way how to buy crypto will be simpy trade your smart asset with it, and that means no identity revealing at the entry of trade, so the full pseudoanonymity (you will be sure not able to recognize between state and common user).
Anyway, the states can't buy all digital coins in the world, that unluckily don't figure them out from taking control over early beginning blockchains.
If you have any ideas how to avoid taking control over blockchains by economical mammoths, please reply. At now I see the biggest problem in the side of recognizing between state and the others.

Hi, everyone,
I have to ask you about SIGHASH_NOINPUT signature script. Means it that I can write a transaction its output can be rewritten in the future because the signature doesn't include output hash?
In original Eltoo whitepaper is written:

Notice that binding allows us to spend any output, without invalidating the signatures, as long as the output scripts and the input scripts match.

What means "output scripts and the input scripts match"? That means the next transaction must have the same output script?

[when this kickoff transaction must be broadcasted when one counterparty cheats]

Hello,
can, please, anybody help me with Channel Fatories in Linghtning Network understanding? Especially with this.
In original whitepaper is written:

Still, one quickly runs out of time by doing transactions in the channel, each requiring a smaller timelock on the commitment transaction. This was solved with a tree of transactions [2] as shown in figure 5.2 At any point in time only the path where all transactions have the lowest timelock of their siblings can be broadcast. In this way, many commitment transactions can be created before the timelocks get too low and the channel cannot be updated any more.

The picture is shown below.
https://royalsocietypublishing.org/cms/attachment/f70d41c4-3a17-4f70-beb3-409c5ab677f2/rsos180089f05.jpg
My questions are:
1. Is kickoff transaction broadcasted on blockchain while funding this channel? Or when this kickoff transaction must be broadcasted when one counterparty cheats and broadcasts the commitment with old state? I am friendly with invalidating via lower time in timelocks but not with the principle of transaction tree.

...A channel constructed this way has to be closed by broadcasting the newest commitment transaction as soon as the first timelock has elapsed, limiting the maximum lifetime of a channel. With relative timelocks, this problem can be solved elegantly. So we introduce a kickoff transaction. Timelocks only start ticking as soon as the kickoff transaction is broadcast, resulting in a potentially unlimited lifetime of a channel.

2.

3.3. Moving funds
A channel factory can be used to rebalance channels which have become one sided. A new allocation is set up which replaces every channel with a balanced new one while keeping the total stake of each party the same. As an advantage, funds can also be moved between channels, new channels can be created or old ones removed, changing the network connectivity without contacting the blockchain. Figure 9 shows such a rebalancing where funds are simultaneously moved to a different channel.

Picture here: https://royalsocietypublishing.org/cms/attachment/c9e15de8-eb12-4834-9879-8b12313d3344/rsos180089f09.jpg
How exactly?
3. What are replaceable transactions for?
4.

Note that the order of the replacement of transactions is important. One should always have a state where the path of lowest timelocks does not end in unsigned transactions. When a new path is created in the tree, the first transaction which diverges from the old active path must be signed last, so the rest of the path is already valid and the whole new path replaces the old path atomically.

Isn't it all still very limited because this "tree making" can't go infinitely? If this uses duplex payment channels, then, I think yes, it is.

If anybody knows something what is worth noting about Channel Factories, please write it here.
By the way, Channel Factories are implemented yet or not? I heard something about problems with new type of transaction (SIGHASH NOINPUT). I know that they can make channels virtually, but that's all.

All sources for this are available here: https://royalsocietypublishing.org/doi/full/10.1098/rsos.180089#RSOS180089F5

[kickoff transaction]

Hello,
can, please, anybody help me with Channel Fatories in Linghtning Network understanding? Especially with this.
In original whitepaper is written:

Still, one quickly runs out of time by doing transactions in the channel, each requiring a smaller timelock on the commitment transaction. This was solved with a tree of transactions [2] as shown in figure 5.2 At any point in time only the path where all transactions have the lowest timelock of their siblings can be broadcast. In this way, many commitment transactions can be created before the timelocks get too low and the channel cannot be updated any more.

The picture is shown below.

My questions are:
1. Is kickoff transaction broadcasted on blockchain while funding this channel? Or when this kickoff transaction must be broadcasted when one counterparty cheats and broadcasts the commitment with old state? I am friendly with invalidating via lower time in timelocks but not with the principle of transaction tree.

...A channel constructed this way has to be closed by broadcasting the newest commitment transaction as soon as the first timelock has elapsed, limiting the maximum lifetime of a channel. With relative timelocks, this problem can be solved elegantly. So we introduce a kickoff transaction. Timelocks only start ticking as soon as the kickoff transaction is broadcast, resulting in a potentially unlimited lifetime of a channel.

2.

3.3. Moving funds
A channel factory can be used to rebalance channels which have become one sided. A new allocation is set up which replaces every channel with a balanced new one while keeping the total stake of each party the same. As an advantage, funds can also be moved between channels, new channels can be created or old ones removed, changing the network connectivity without contacting the blockchain. Figure 9 shows such a rebalancing where funds are simultaneously moved to a different channel.

Picture here: https://royalsocietypublishing.org/cms/attachment/c9e15de8-eb12-4834-9879-8b12313d3344/rsos180089f09.jpg
How exactly?
3. What are replaceable transactions for?
4.

Note that the order of the replacement of transactions is important. One should always have a state where the path of lowest timelocks does not end in unsigned transactions. When a new path is created in the tree, the first transaction which diverges from the old active path must be signed last, so the rest of the path is already valid and the whole new path replaces the old path atomically.

Isn't it all still very limited because this "tree making" can't go infinitely? If this uses duplex payment channels, then, I think yes, it is.

If anybody knows something what is worth noting about Channel Factories, please write it here.
By the way, Channel Factories are implemented yet or not? I heard something about problems with new type of transaction (SIGHASH NOINPUT). I know that they can make channels virtually, but that's all.

All sources for this are available here: https://royalsocietypublishing.org/doi/full/10.1098/rsos.180089#RSOS180089F5

Hello,
I see in Lightning Network some small issue which besides defends the transfer of big amount of BTC. I use the example with café. Have you noticed that in case of sending secret, two transactions are actually valid and two would pass? The third transaction from the front is invalidated by the exchange of the secret, but not the two most recent before the exchange of the secret. That is why the waitress will bring the third coffee only when the secret is exchanged for the second transaction (the customer might broadcast older transaction without penalty at now). The process is always one "paying" as if behind. But before that, there are two transactions - the two latest. In the exchange of the second transaction commitment, the third transaction is already signed and the waitress can broadcast it and have her coffee paid for, without waiting for a secret.

Can this small problem be solved by atomicity - namely, between signing a second commitment, exchanging secret from first commitment and serving a second coffee (these actions must be totally contemporary (atomic) for maximum safety and how?

I speak about big amount of BTC at the beginning because if you are transferring more bitcoins, then the receiver is paid in advance and that is not safety.

Hello,
how is ensured that secret and new commitment transaction exchange take place at the same time? If for example Alice sends Bob the new commitment transaction only if he sends her a secret for penalization transaction activation, and she lies, it can end by balance freeze forever, because at now Alice has secret and Bob has nothing, so Bob can't send a transaction to blockchain (if he does it, Alice uses his secret to take all his money from the channel) and Alice does not do it because she wants Bob broke even if her money are freezed too.

Hi, everybody
Does anybody know what will happen if somebody breaks the linking between smart property token (for example a locked car) and real object? In relation with this, there may be issue with smart labels (which can be used to prove origin of certain products) - what if somebody simply breaks the physical lock? It isn't so hard until the container is indestructible. It may seem that smart property is great, but cryptography does not defend the object from violent physical destroying. It looks like we need to use some indestructible containers for all smart property in order to prevent this (for example metal case for your house in other side of the world which shares you bought using blockchain - it's nice that only you can unlock it, but anyone is still able to break it).

And this property is also very unpractical because for each unlock must be generated digital signature and the object has to be uninterruptly connected to see which address actually holds its digital token (respectively colored coin).

Does anybody know how to solve this without police?

[and set the funding transaction]

Hello,
I want to ask you if is lightning network potentially enough scalable to achieve stable Bitcoin in the future? If we admit that only new members open a new payment channel (and that LN is fully functionable and save) to connect into lightning network (and the amount of channel closing will be minimal) and set the funding transaction, is it enough little to avoid 8GB blocks and mining centralization?
Can't one hypothetical day the amount of new members per day be too high that the setting funding transactions on the blockchain (soon or later) overloads the network anyway?
Or that way: will be the amount of new participants per day increasing in ratio more than computational power of most computers (nodes)? Sorry, if is this question simple. Admit that not only financial services will run blockchain technology (include autonomous vehicles, factories, robots, smart homes etc. who all need to put a funding transaction on the blockchain).

I think that LN does not really solve the scalability problem at all. What if despite great transaction reduction will one day the amount of funding transactions be simply too high?