3 ms·

Some of my congestion control research that helps large scale users make throughput/latency tradeoffs using simple "transaction templates": https://utxos.org/u

Some of my congestion control research that helps large scale users make throughput/latency tradeoffs using simple "transaction templates": https://utxos.org/uses/scaling/ https://utxos.org/uses/scaling/ https://utxos.org/analysis/bip_simulation/ https://utxos.org/analysis/bip_simulation/ https://utxos.org/analysis/batching_sim/ https://utxos.org/analysis/batching_sim/ https://github.com/bitcoin/bitcoin/pull/21702 https://github.com/bitcoin/bitcoin/pull/21702

billytetrud 5y ago
Thanks Jeremy! Are all those links related to congestion control? In short, that's basically allowing transactions to be shifted from high-congestion times to lower-congestion times without delaying the transfer (eg the transfer from the sender, even if the receive won't get the coins immediately). Is that right? Or are there more benefits of it?
- jlrubin 5y ago
  Hi Billy, yes they all are. 1 -> high level idea, 2 -> basic simulation, 3 -> batching improvements, 4 -> the PR to bitcoin core. I have a lot more material scattered around too :) You understanding of the shifting from high congestion to low is spot on, but there are other benefits. The technique can also be used for more general smart contracts. I've been building a language, https://learn.sapio-lang.org https://learn.sapio-lang.org, for expressing smart contracts. You can do vaults, synthetic derivatives, sidechains, etc with it. One niche point I like to make too, btw, is that the delayed payouts can be into non-interactively initialized payment channels. So you could immediate begin spending/routing payments in the lightning network on open, and wait for low congestion to expand out your UTXO.
  - billytetrud 5y ago
    Ah very interesting. So Sapio is a library for constructing somewhat arbitrary programs using CTV as a mechanism for enabling more turing complete operations? Is Sapio turing complete (or, I guess equivalently would Bitcoin be turing complete with the addition of CTV)? So with non-interactively created channels, I don't quite understand how you would be able to immediately spend/route payments. Don't you always need to interact with your channel partner in order to do both of those things?
    - jlrubin 5y ago
      Yep! It's an e-dsl essentially, since you write a program and it compiles to bitcoin transactions. Sapio is turing complete (trivially, you can call any program you can write in regular rust from a Sapio contract). However, the output is a static set of transactions, which is not turing complete. However, if you have an updatable "finish!" clause, then Sapio can generate the logic for a "next step if N parties agree" or something similar, which lets you express the continuation logic in Sapio. For your last question, I think it is semantics. An "interaction" is (by my perhaps non-standard and definitely inconsistent terms) a back and forth communication between two parties. A non-interactively created channel is set up by either party (or a third party) and then the funds cannot move without the signoff of either party. However there's no guarantee that the funds can move, unless the parties receive a transmission from the creator informing them of the setup (think of this kind of like a memory leak in rust?). This isn't really an interaction as it can happen fully asynchronously, but it's sort of weird because if you don't get it you don't get paid... but assuming the person paying you wanted to pay you, they can try to let you know later! Then, payments (in one direction, i.e. A->B but not B->A) can be done in the same async half-interactive way. You just get the broadcast and save it to get more money. This might seem really niche (it is) but carving out these little pockets of what constitutes an interaction opens the door for some really interesting types of devices. E.g., imagine a "low power smart meter" that you can open a channel to and pay multiple times, but the smart meter only has a public key on it, no private key. All state (incl block headers) can be SPV checked and stored locally. Requiring a full interaction means that these devices have to have a private key accessible. This is sort of a contrived example, because there are better ways to make the smart meter, but it shows you the edge that exists at least.
      - billytetrud 5y ago
        Well, Sapio seems pretty cool. Composable scripts is definitely something we need in Bitcoin. So basically, the idea of non-interactive channel creation sounds basically like a way for someone to lock in their payment to someone without interacting with them. I suppose I can see the usefulness in that in certain situations. Especially situations where someone that you can interact with does care that you've paid the person who can't interact at the moment.

billytetrud 5y ago

Thanks Jeremy! Are all those links related to congestion control? In short, that's basically allowing transactions to be shifted from high-congestion times to lower-congestion times without delaying the transfer (eg the transfer from the sender, even if the receive won't get the coins immediately). Is that right? Or are there more benefits of it?

jlrubin 5y ago
Hi Billy, yes they all are. 1 -> high level idea, 2 -> basic simulation, 3 -> batching improvements, 4 -> the PR to bitcoin core. I have a lot more material scattered around too :) You understanding of the shifting from high congestion to low is spot on, but there are other benefits. The technique can also be used for more general smart contracts. I've been building a language, https://learn.sapio-lang.org https://learn.sapio-lang.org, for expressing smart contracts. You can do vaults, synthetic derivatives, sidechains, etc with it. One niche point I like to make too, btw, is that the delayed payouts can be into non-interactively initialized payment channels. So you could immediate begin spending/routing payments in the lightning network on open, and wait for low congestion to expand out your UTXO.
- billytetrud 5y ago
  Ah very interesting. So Sapio is a library for constructing somewhat arbitrary programs using CTV as a mechanism for enabling more turing complete operations? Is Sapio turing complete (or, I guess equivalently would Bitcoin be turing complete with the addition of CTV)? So with non-interactively created channels, I don't quite understand how you would be able to immediately spend/route payments. Don't you always need to interact with your channel partner in order to do both of those things?
  - jlrubin 5y ago
    Yep! It's an e-dsl essentially, since you write a program and it compiles to bitcoin transactions. Sapio is turing complete (trivially, you can call any program you can write in regular rust from a Sapio contract). However, the output is a static set of transactions, which is not turing complete. However, if you have an updatable "finish!" clause, then Sapio can generate the logic for a "next step if N parties agree" or something similar, which lets you express the continuation logic in Sapio. For your last question, I think it is semantics. An "interaction" is (by my perhaps non-standard and definitely inconsistent terms) a back and forth communication between two parties. A non-interactively created channel is set up by either party (or a third party) and then the funds cannot move without the signoff of either party. However there's no guarantee that the funds can move, unless the parties receive a transmission from the creator informing them of the setup (think of this kind of like a memory leak in rust?). This isn't really an interaction as it can happen fully asynchronously, but it's sort of weird because if you don't get it you don't get paid... but assuming the person paying you wanted to pay you, they can try to let you know later! Then, payments (in one direction, i.e. A->B but not B->A) can be done in the same async half-interactive way. You just get the broadcast and save it to get more money. This might seem really niche (it is) but carving out these little pockets of what constitutes an interaction opens the door for some really interesting types of devices. E.g., imagine a "low power smart meter" that you can open a channel to and pay multiple times, but the smart meter only has a public key on it, no private key. All state (incl block headers) can be SPV checked and stored locally. Requiring a full interaction means that these devices have to have a private key accessible. This is sort of a contrived example, because there are better ways to make the smart meter, but it shows you the edge that exists at least.
    - billytetrud 5y ago
      Well, Sapio seems pretty cool. Composable scripts is definitely something we need in Bitcoin. So basically, the idea of non-interactive channel creation sounds basically like a way for someone to lock in their payment to someone without interacting with them. I suppose I can see the usefulness in that in certain situations. Especially situations where someone that you can interact with does care that you've paid the person who can't interact at the moment.