<div dir="auto"><div><br><div class="gmail_extra"><div class="gmail_quote">Den 8 feb 2017 02:16 skrev "James A. Donald" <<a href="mailto:jamesd@echeque.com">jamesd@echeque.com</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 2/8/2017 5:16 AM, Jameson Lopp wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From some quick googling it appears that there are ~100 Billion credit &<br>
debit card transactions per year. But the real question is how many<br>
/cash/ transactions occur? I suspect (globally) it is probably far<br>
higher than electronic transactions.<br>
<br>
Given that blockchain-based cryptocurrencies require every validator<br>
node to process the entirety of the network's transaction history, in<br>
order to scale them up to reach mainstream level volumes, more complex<br>
layers of transaction processing need to be built on top of the base<br>
layer in order to achieve sufficient scalability.<br>
</blockquote>
<br></div>
What I have been thinking on for many years is that you do not really need every full node to process the entirety of the network's transaction history, or indeed any nodes processing the entirety of the network's transaction history.  Rather, your node needs to be able to prove that every node connected to your node by a rather short chain of transactions is in agreement about all transactions directly or indirectly affecting you.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">... and you just reinvented Lightning Network. (It also sounds a bit like Ripple.)</div><div dir="auto"><br></div><div dir="auto">Alice and Bob creates a 2-of-2 multisignature transaction that they publish to to the blockchain. They assign X coins each, both paying themselves. Then they create a follow-up transaction which they don't publish, this works as a draft transaction, a digital tab. One that is signed by both parties.  </div><div dir="auto"><br></div><div dir="auto">It uses the Bitcoin locktime functionality to prevent doublespends before the locktime expiry (before expiry both parties needs to agree to spend coins to the blockchain, after expiry you only need one - this prevents permanently freezing funds).</div><div dir="auto"><br></div><div dir="auto">Alice tells Bob "you owe me $10 for that pizza", the two then modify the draft transaction to assign the payment output values accordingly. This is the basics of payment channels in Bitcoin. </div><div dir="auto"><br></div><div dir="auto">Lightning network is the networked version of that. People have payment channels to payment processors. Processors have payment channels between each other. </div><div dir="auto"><br></div><div dir="auto">Payments are routed across the nodes, and the sender verifies that it reaches the receiver. </div><div dir="auto"><br></div><div dir="auto">Unfortunately I know very little about the server side pieces of Lightning Network nodes. Somebody else can probably fill in on that. </div><div dir="auto"><br></div><div dir="auto">Performance for the same-server usecase is at least essentially unlimited since there's very little overhead necessary. Can't say anything about what happens in large loosely connected networks. </div></div>