"And all of the transaction were free", Wait? Since when are transactions free and instant? Is that part of this upgrade? The only costs are with the "bank transaction"?
When Katy wants to pay ₿3 to Billie, Katy just sends a key (via email or some API) to Billie which enables Billie to withdraw ₿3 from the account of Katy. But Billie does not do that. Billie just keeps that message like you keep your login to your bank account.
When Katy wants to pay another ₿5 to Billie, Katy sends a key to Billie which enables Billie to withdraw ₿8 from the account of Katy.
Now Katy paid Billie ₿8 in two transactions. All via email, letter, telephone or - most likely - API. Nothing at all happened on the Bitcoin network.
In other words, Billie has no guarantee that the key she holds will be valid tomorrow; Katy could empty that account at any time, and Billie would then hold nothing except the evidence of Katy's wrongdoing.
Katy could empty that account at any time
Realistically, the spending conditions are either limited by time. So Billie knows she needs to withdraw until a certain date or Katy could betray her. Or the spending conditions contain a punishment for betrayal. So if Katy tries to withdraw money she assigned to Billie, Billie can intervene, get her money and punish Katy.
they are locked down. the funds in a lightning channel are locked in a 2 of 2 multisig address, and can only be moved upon mutual consent (ie. by updating the state of the channel), or by one party after sufficient time has passed (in case of an uncooperative peer).
Are you talking about compared to regular transactions, or because network fees (per byte) are high?
That $1 enables as many transactions as you want between party A and B, of which party B may have dozens of open channels with other nodes to facilitate routing from party A to C etc.
OP was describing something in the context of Taproot and now you and others are talking about Lightning. What is the new development here?
https://blog.chainalysis.com/reports/bitcoin-taproot-upgrade
https://medium.com/blockstream/taproot-activation-enhanced-t...
This function is provided by script: https://en.bitcoin.it/wiki/Script
Isn’t this an example of a centralized bottleneck?
Roughly speaking the Lightning Network works similar to a „current account“ that businesses have between each other but does not require the actors to trust each other. The parties initiate a transaction by each one sending Bitcoin to a public multi signature address. The resulting transaction cannot be spent by any one alone. Now, this unspent transaction serves as an initial balance and opens a channel between the parties on the layer 2 network. Bitcoin may now be wired back and forth between the parties on layer 2 w/o needed to be settled individually on the Bitcoin block chain. Finally, if all parties agree by signing a second, settling transaction the resulting balance is written back to the Blockchain to whatever address the participants initially agreed upon. Theoretically, there could have been billions of Bitcoin transactions over the years on the Lightning Network which would be eventually represented by only two transactions on the chain.
Now, taproot improves this scheme by introducing Schnorr signatures. Up to now every member of the multisig transaction I just talked about needed to contain the public keys of all parties which in turn needed to be verified against all their private keys. Since transactions are limited in their size, this limited the applicability of multisig transactions. Now, Schnorr signatures allow for aggregation of public keys so the transaction only needs to contain a single number instead of hundreds or thousands. Of course, this also speeds up validations of transactions.
I hope this all made sense. I have yet to see practical applications of a Lightning Network „scheme“ but I heard El Salvador is using it for cheap Bitcoin transactions (although not applying Schnorr signatures yet).
Parent talks about the „Lightning Network“
So is the "BMW and its suppliers" network I imagined. But this network is simpler and more customized to the needs of this particular use case.
Of course using the LN would be a viable alternative to a custom solution.
I do wonder how it could ensure the code running is the actual code signed for as its hash would be different though.
At signing time, the signer reveals a hash for every non-taken branch, so that the commitment still checks that leaf being executed was an admissible one.
The dead-code elimination goes further than that, because at the top level this hash root is hidden inside a public key which can be a key controlled by all the participants jointly (or some subset if appropriate). At signing time if these top level parties are available and cooperate they can just sign, and no script is ever revealed, it's impossible for third parties to tell it was ever there-- saving resources and preserving privacy.
(And the possibility to complete the transaction using the script means they don't gain from failing to cooperate)