While I'm also excited about the potential applications that atomic cross-chain swaps could enable, I have to agree with Carlton Banks that further improving on-chain scalability by utilizing atomic cross-chain swaps to spread transactions across multiple blockchains -- effectively using it as a load-balancing method of sorts -- is unlikely to come to fruition. I do like your vision of blurred lines between various cryptocurrencies though.

Of course transactions spread across multiple blockchains will be harder to get under control by an adversary than a single huge-ass blockchain with Gigabyte blocks (intentional hyperbole, but you should get the point). However it still doesn't change the fact that on-chain scaling as we know it is a linear function, no matter how we spread transactions across different currencies. It doesn't help that atomic cross-chain swaps still need to be settled at one point, thus hitting their respective blockchains and requiring those to have blockspace available in the first place.

Either way, I'm looking forward to see what atomic cross-chain swaps will bring -- seamless integration of cryptocurrencies and utility tokens come to mind -- I just don't think improved scalability in terms of transaction throughput will be one of its main use cases.

We're still in the midst of finding out which use cases are viable for blockchains and which aren't; in other words until blockchains have superseded something in earnest it's still a bit premature to talk about whether blockchains themselves will get replaced as well.

That being said, sure. I don't think any technology stays on top forever. Blockchains and decentralized ledgers in general could very well just lead to a dead end, for whatever technological or socio-economical reasons we've yet to fully understand. On the other hand it could change the way we deal with money, property and data forever... or at least a very long time. Only one way to find out.




DAGs are merely data structure, just like blockchains. Without a secure, trustless and permissionless way to prevent double-spends we might as well fall back to centralized solutions.

I guess we'd mostly have to rely on some of the larger merchants to publicize the amount of LN transactions they process each day and go from there. Despite the P2P trade (ie. C2C business) that Bitcoin enables it is fairly save to assume that at least in the forseeable future a significant amount of transactions will go to centralized entities such as exchanges, payment processors and possibly a handful of merchants that accept BTC directly (ie. traditional B2C business). This could provide enough data to extrapolate from there. The reliability and conclusiveness of said data is a different question though.

However I'm not sure if tps is all that meaningful a metric in the case of LN. After all the main challenges that LN will face in terms of scalability will likely largely depend on the payment capacity of each channel. LN may be able to process, say, 500,000 sub-cent transactions per second but only a couple of hundreds tps for everything bigger than USD 50,-. These are random, baseless, speculative examples of course -- point being that we'll probably have to stop thinking in terms of tps when it comes to LN.

So we'll probably have to rely on the following metrics to see the effectiveness of LN's scalability:

1) Network capacity / Channel capacities
2) Amount of on-chain transactions required for closing / opening channels

In the end we'll have to see in practice whether LN scales sufficiently. Especially 2) will be a metric to keep an eye on.


Keep in mind though that LN is not the scaling solutions to end all scaling problems. Any improvements in on-chain scalability will be multiplied by LN. Additional protocol layers inbetween may further improve on LN's scalability.

Thank you for the detailed response Danny, very much appreciated.


Validating the freshly mined blocks from the other miners is the step that I completely overlooked.

What happens if a new block is found before the previous block has been validated? Obviously the block will be empty, as transactions have yet to be re-checked, but will a miner speculatively relay the new block, hoping that the previous block is indeed valid? Basically a hail mary of sorts? Or is this a case where a miner will refrain from relaying the new block until they have validated the previous block?



...and between validating the previous block and updating the local mempool, empty to near-empty blocks happen, got it.

(ignoring other potential implementation / configuration / connectivity issues that can lead to near-empty blocks)

I stand corrected, thank you for clearing this one up. Come to think of it, it does make more sense and makes the network less prone to DOS attacks.

Do you by any chance know which part of adding transactions to a block the time consuming one is? That is, the reason why sometimes new nonces are quicker found than transactions added? Is it because transactions need to be-rechecked to ensure that they are still valid, ie. not spent by the previous block that has just been freshly found?

There may be an opening for correlation attacks, as to deduce which transactions were made. Question being whether such an attack would be feasible.

When trying to unravel LN's transaction history, an adversary is facing the following challenges:

1) Each node only routes a fraction of the network's traffic

2) Payments are routed in an onion style akin to TOR, ie. encrypted in layers in a way that prevents a routing node from knowing the initial sender and the final recipient.

It follows that an adversary can only indirectly derive transaction amount, sender and receiver by a) watching on-chain settlements and b) keeping track of their LN nodes' channel states (ie. where payment flow in their immediate neighbourhood and at which time).

a) is public but alone largely insufficient, b) requires control over a large number of LN nodes.

The more nodes an adversary controls, the less holes they have in the global transaction history, the more precise they can derive money flows. Owning 100% of nodes gives obviously full knowledge but is also pointless, as there would be no one left to be monitored. Owning 1% of nodes will probably give close to no usable information. The sweet spot will lie somewhere inbetween, but whether it's actually viable is a different question.



True, but keep in mind that most taxable events are fiat trades anyway. And those are largely linked to real identities.

Close, but not quite.


There's no such thing as a global pool of transaction, each miners keeps their own mempool. They will be mostly the same, but may differ to due differences in mining software, configuration and network connectivity.

Transaction validation doesn't happen until the miner tries to build a block.



Miners don't care about filling blocks.

Sure, they try filling them as good as possible as to reap transaction fees. But validating transactions takes time and if they happen to find a valid nonce before the block is fully filled they just sent the block to the other nodes in the network, lest some other miners beats them to it. Keep in mind that miners always keep hashing in the background, even as they are just collecting and validating transactions for a new block.



Each miner keeps their own copy of the blockchain. So they add the block to their copy of the blockchain and then tell the rest of the network about the update. Usually their blockchain is the longest one, because they just added a new block. As such, all other miners follow suit.

However if for some reason they missed a couple blocks, their copy of the blockchain will be shorter than the copies of the rest of the network, despite the newly added block. In this case they are out of luck and have to follow the longest blockchain, losing their block reward as their copy of the blockchain is no longer valid. This also makes each transaction this miner had put in their block unconfirmed, unless some other miner already included it in a block (for example the one that our miner missed).

If that's the case, then the miner drops their copy of the blockchain in favour of the longer one and starts building a new block, picking up and validating transactions from their own copy of the mempool as they go, just as mentioned above (ie. not really caring about making the block full and when in doubt releasing an only partially filled block).


TLDR; Miners don't necessarily fill blocks to its maximum because they validate as they go; Each node has their own copy of the mempool and the blockchain as there is no central transaction pool to pick up new transactions from.

No.

There's no way to reliably determine how much GH a miner is adding to the network, therefore you can't restrict it.

IP restrictions are easily circumvented. Identifying each miner by a unique ID would require a central authority, which would make the whole system moot.

These are also the reasons why PoW was conceived in the first place -- every other approach before it was either centralized or insecure. (PoS, amongst others, being an alternative approach to solve the same problem)

When talking about the insecurity of not using the Bitcoin blockchain I was referring to your paper example and not LN.

LN is trustless, as you don't require any overseeing third party to ensure your money's safety. The only third party required, if you can call it that, is the Bitcoin blockchain.

LN is permissionless, as no one can exempt you on LN's protocol level from participating in the network.

LN is fungible, as you can use Satoshis as is (and potentially sub-Satoshi amounts); Upon settlement these amounts can be used like any other Satoshis on the network.

LN is not immutable, but its on-chain settlement is and trying to make illicit changes to a LN channel state gets heavily punished, making it a losing value proposition to any would-be attacker -- akin to how mining for block rewards is more profitable than attempting a double-spend attack.

Throwing a piece of paper with a private key on it is indeed permissionless, but neither trustless, nor fungible, nor immutable.



Oh, I'm very well aware of what I said!

Here's the thing -- any internetless form of PoW would still require a form of handshake for keeping the blockchain state consistent across nodes.

Even if miners would solve hashes with pen and paper, sending the resulting blocks -- and therefore, their state of the shared ledger -- to the rest of the network using carrier pigeons, they would still need their counterparts to confirm that their state of the shared ledger is consistent with the rest of the network. They can't just throw a piece of paper in the wind like in your example with the private key -- they need acknowledgment from their counterparts, otherwise they end up on an orphaned chain. A handshake is still required, if only by carrier pigeon instead of TCP.

Vladimir Orehov, not Putin

Not that it changes anything, but next thing we know there'd be rumours all over the place about Putin running ICOs.

Well, maybe he does >_>



To make things even more silly, even if it impacted their business, what's that to the courts? Google is neither violating any rights nor is it abusing its market dominance to its own advantage. Even Orehov's argument is more a statement of entitlement than anything else:


What's next? Guy sues Tinder for the "moral damage" of not getting laid?

Programming languages are separate from the platforms they run on and vice versa.

Virtual machines running on blockchains are basically simple, decentralized operating systems. Think Windows, Linux or macOS, just way more minimalistic. These virtual machines are not the programming language. They interpret the programming language.

So will we see smart contract platforms supersede traditional, centralized solutions? I doubt it, as there are only limited use cases where the decentralization aspect of blockchains really comes to fruition. Which use cases these are, we are about to find out in the upcoming years.

How will this influence future programming languages? I guess very little, as in general high level programming languages should care very little about the underlying architecture. After all they are a means to abstract these details away. We probably will see more blockchain specific programming languages over the next few years, but they will likely stay in the niche that is the crypto ecosystem. Whether it will bring new concepts to other programming languages that don't work with blockchain smart contracts is a different question, but I expect smart contract programming languages to learn more from already existing languages than the other way round.



I very much hope so as well. What we currently have is in my opinion rather inadequate for immutable, permissionless transactions.

LocalBitcoins already had to close shop in some jurisdications (eg. Germany) due to regulatory problems. In the US there have been arrests of LocalBitcoins traders for illegal money transmitting services.

On the other hand we are seeing the first decentralized exchanges coming up, so I guess the game is on?

It is indeed too early to tell. And Bitcoin development is edging towards increased privacy either way (Schnorr Signatures + CoinJoin, Bulletproofs) so who knows what we'll end up with.



Bitcoin Magazine has a fairly comprehensive article series on the workings of the Lightning Network:

https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/

It's a lot to take in at first but helps a lot with getting familiar with some of the concepts involved.

Excellent point.

On the other hand I'm not sure if, in the long run, a fully anonymous cryptocurrency would not simply get banned from (KYC/AML compliant) exchanges altogether. Especially since transparent alternatives exist. So far privacy-focused cryptocurrencies have been left alone, but who knows if it stays that way once they grow big enough.

If the majority of people use LN for their everyday transactions the question of "taint" may become moot either way, since it would affect most of the available money supply.



Ooooh but that's the beauty of LN! The bartender is... the Bitcoin blockchain.

You open your tab with the Bitcoin blockchain, you close your tab with the Bitcoin blockchain. That's it. Just some bits of smart-contract magic and PoW as we know and love.

The only difference between the Bitcoin blockchain and your usual bartender is that the Bitcoin blockchain is incredibly distrustful and asks you for an advance deposit. But hey, being distrustful is part of a blockchain's job. And you can still use your money any way you like.

You mean the practical implications of soft forks regarding free alt coins as the result of a chain split?

None.

Unless something goes horribly wrong or weird or both a soft fork will usually not come with what amounts to an airdrop for holders of the original coin. It does, however, usually come with protocol upgrades such as SegWit.

The privacy aspect of LN will likely have little effect on how taxes are charged. Even as of now tax authorities have to rely on their citizens to report applicable income truthfully. Prosecution of tax evasion may be easier with on-chain transactiosn, but that doesn't release one from the legal duty of reporting taxable events, no matter how the transaction was sent or received.

The KYC part is a bit more tricky and there has been a handful of discussions about this already.

Two worries that come up regularly:

1) Running a LN node classifies as acting as a money transmitter, making it defacto illegal to run a LN node as a regular, unlicensed user.

2) Exchanges won't be legally able to accept Lightning transactions using their own LN nodes because they would be required by law to apply full KYC / AML policies on all in- and out-going transactions -- including routed ones -- which is technically unfeasible.

I don't think 1) will will ever come to pass, but may indeed cause trouble in some jurisdictions. Stranger things have happened. 2) we'll find out once the first exchange has consulted with their legal team and starts accepting LN deposits -- or not.



Enough for what? For deducing which transactions were made? Within certain limits, probably. In full, probably not.

Exploited for what, illegal, private transactions? Sure. But would this be a reason for giving up privacy altogether? Criminals will always find a way to stay private. Let's give everyone else a chance to stay private as well.

I never claimed that a block full of SegWit transactions has 4x the transaction capacity.

I'm well aware of the structural differences between SegWit and legacy transactions.


To clarify, my point is the following:

With SegWit, the maximum achievable blocksize, in raw data, ie. as bits and bytes that get stored on harddisks and propagated over the network is 4MB.

Yes, if the block is full and contains legacy transactions only it has merely 1MB. If the block is not full because it only contains a handful of transactions it's even less. If the block has part SegWit and part legacy transactions, it's somewhere inbetween.

But those are not the cases that interest us.

The important case is: What's the maximum amount of data that needs to be accounted for when storing and propagating a block. And this case is a block that is 100% filled with SegWit transactions. And that makes a block with roughly 4MB of data, signatures and all. So that is, effectively, the maximum blocksize.



Did you really just argue that Bitcoin would work just as well without the internet?

It's a fun exercise, but would not be trustless anymore, ie. would lack one of the core properties of Bitcoin.


To expand:

If you hand me a private key as payment I have no guarantee that you don't keep a backup somewhere. Or that you "paid" someone else with the very same private key. In other words, I would need to trust you.

Unlike cash or gold, a private key, being digital data, can be easily copied and thus double-spend. Which is why, in the digital realm, the likes of PoW (or PoS, or PoWhatever) are needed. Which, for better or worse, do need the internet or some other forms of communications channel as a means of data exchange.

Incorrect. While SegWit transactions are "weighted" differently than legacy transactions, the overall effective maximum filesize is 4MB. If most transactions are legacy transactions, the maximum blocksize is more towards 1MB. If most transactions are SegWit transactions, the maximum blocksize is more towards 4MB. It's still the same block though. For all intends and purposes, SegWit was a blocksize increase and that is effectively an increase to up to 4MB. No such thing as a differentiation between small legacy or large SegWit blocks.



Legacy and SegWit transactions are sitting side by side resulting in 1MB - 4MB blocks.



There's this thing called computers and software that handle the implementation details of such matters.

TCP requires handshakes. Should Bitcoin stop using TCP as one of its base layers?



Exactly.

Adding smaller denominations is an increase of fungibility and not a decline of scarcity, like your statement suggests.



If you could only buy / send / trade whole Bitcoins you couldn't use it as a viable means of exchange.

Why would you even require people to buy whole bitcoins?



What are you trying to say? There are both a handful of entities owning tonnes of gold and billions of people owning small portions of gold. Lots of people owning small portions of an asset doesn't make the asset worth less than if only few people own large portions of it. Quite the opposite. The more people own something, the better its liquidity, the healthier its market.

The way I understand sidechains they only hit the mainchain when settlement is necessary, not for every single asset transfer. Similar to Lightning Network's channel opening and closing transactions.

In other words, unless there's a dispute that needs to be handled on the mainchain, the transfer time of sidechain assets should not be affected by the the amount of mainchain confirmations being required for settlement.

Not everything that involves risk is automatically a casino. If everyone would follow this mindset humanity would still forage and hunt. Not necessarily a bad thing, mind you. But I've heard there's this thing called fire that some of the tribes are using to keep warm and cook their meat. Surely they must be crazy to take such a gamble.

Risk taking is part of what drives mankind forward. With every new innovation its inventor and society is taking a gamble on whether it will improve their lives.

What's your opinion on the stock market? Founding a company? Technological progress?

No, I do indeed mean that you can't have both big and small blocks. Either you try to keep the blocks as small as possible (ie. 1MB, or effectively 4MB as is the case with SegWit) or you increase the blocksize to another arbitrary number that may or may not be feasible in the long term. Either you try to move the majority of transactions off-chain with 2nd layer solutions, or you try to scale it linearly by increasing the block-size ever so often. Sure there was some political perspective to the whole debate as well, but from a technological perspective a slight increase from 1MB to 4MB -- as was the case with the SegWit softfork -- is a more prudent approach than even larger blocks.



I think we're both looking at Bitcoin's governance from two very different perspectives. I actually do see alt coin creation as part of the consensus mechanism, but I also missed a lot of the political details of what happened between 2014 - 2016. So I disagree with your statement of alt coin creation not being part of Bitcoin's evolution, but have yet to form my opinion on the political happenings that you brought into play.



Hence LN not being more permissioned in a meaningful way.

LN channels requiring an opening handshake doesn't make them any less censorship-resistant or trustless than on-chain transactions.



Serious question, what lead you to the conclusion that increased fungibility would effectively increase Bitcoin's supply? That's some Zenon level shit right here.

The existence of gold dust doesn't make gold bars any less scarce or valuable. In some places gold dust is used for overly fancy dishes and cocktails. You can literally shit gold, yet its value persists.