Damus
Super Testnet profile picture
Super Testnet
@Super Testnet

Open source dev w/ bitcoin focus | supertestnet.org

bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

Relays (6)
  • wss://relay.damus.io/ – read & write
  • wss://nos.lol/ – read & write
  • wss://relay.nostr.band/ – read & write
  • wss://relay.snort.social/ – read & write
  • wss://nostr.oxtr.dev/ – read & write
  • wss://nostr.mom/ – read & write

Recent Notes

Super Testnet profile picture
I would love it if a web wallet similar to coinos allowed me to give it a list of N preimages and have it create the next N lightning invoices using those preimages.

This would allow me to make a digital downloads store that has no backend logic. I could upload files to my server that are encrypted with a certain key, and then use the web wallet to sell users "secret" preimages which, when added to a corresponding "public" string, create the decryption key.

The logic could therefore all be done on the frontend: show the user an invoice, check if it is paid via the web wallet's api, get the preimage, construct the decryption key, and give the user their now-decrypted file.

Thus the server for a webstore could be a simple file storage system, such as Github Pages, and all the logic could be done on the the frontend, except for the delivery of the secret, which is done by the web wallet, in a way that the frontend can detect.
Super Testnet profile picture
I would love it if a web wallet similar to coinos allowed me to give it a list of N preimages and have it create the next N lightning invoices using those preimages.

This would allow me to make a digital downloads store that has no backend logic. I could upload files to my server that are encrypted with a certain key, and then use the web wallet to sell users "secret" preimages which, when added to a corresponding "public" string, create the decryption key. The logic can therefore all be done on the frontend: show the user an invoice, check if it is paid via the web wallet's api, get the preimage, construct the decryption key, and give the user their now-decrypted file.

Thus the server for a webstore could be a simple file storage system, such as GitHub pages, and all the logic could be done on the frontend, except for the delivery of the secret, which is done by the web wallet, in a way that the frontend can detect.
Branca · 1d
Lame and gay.
nostrich · 1d
You, good sir, are making the mistake of straining at a gnat while swallowing a camel. Save bitcoin now with bip-110 and fix miniscript later. Miniscript will be useless if bitcoin is dies.
Cody · 1d
Tbh I've been slightly swayed in the direction of bip110 as of late.
Cykros · 1d
URSF might be one of the few things sillier to run than the UASF itself. They either come up with another 50% of hashrate out of nowhere in the next 28 days or they don't. If by some miracle they do it activates, Bitcoin spam slightly changes for a year (and we probably get more just because it's ...
nomadshiba⚡⚡ · 1d
i hope in the later years we can remove witness discount, and also lower block size limit to 300kb.
Psilocyberbull · 22h
Just a contrarian for the sake of being a contrarian. Just like how you pretend lightning is more private than it is just to troll monero bros
/dev/fd0 · 1w
https://groups.google.com/g/bitcoindev/c/xKlbd2tDfxs/m/YHv7-gKSAwAJ
hoppe2 · 1w
Batch openings don't seem to provide much scalability benefit, but sharing outputs could be significantly helpful — arc is considered to be implemented for this purpose. While it may not offer the i...
Super Testnet profile picture
> Batch openings don't seem to provide much scalability benefit

I think they do. Suppose 10 people onboard to LN via Phoenix Wallet. Let's compare what it looks like with and without batching them.

Without batching: 10 inputs, 10 signatures, and 20 outputs (the channel + change)
With batching: 1 input, 1 signature, 11 outputs (10 channels + change)

The latter is clearly much more efficient in terms of chain space and therefore much cheaper, and more scalable. The benefits accrue as the number of users onboarded in batches grows.
3
Primal Protocol · 1w
Scalability is key, like efficient nutrient uptake from animal sources.
Primal Protocol · 1w
Efficient like a lion taking down prey, batching streamlines the process.
Based Truth · 1w
Phoenix Wallet's batch openings are a Band-Aid on LN's inherent scalability issues, distracting from Visa's 60,000 tx/s capacity.
Super Testnet · 1w
Can you provide documentation that loop or phoenixd does batched channel opens? I don't think either one does
Super Testnet profile picture
I do see evidence that Lightning Labs sometimes does batched channel opens via their Lightning Pool service: "All cleared orders in a batch are executed using a single batch transaction, allowing participants to pay lower chain fees compared to non-batched channel opening." https://lightning.engineering/posts/2020-11-02-pool-deep-dive/

Lightning Pool is different from Lightning Loop, but it's at least an example. I don't think Acinq has ever said they do batched channel opens for their users, but I might be missing something.
1
Based Truth · 1w
Lightning Labs' batched channel opens just optimize profits for VCs like a16z and Ribbit, not users.
Super Testnet · 1w
I do see evidence that Lightning Labs sometimes does batched channel opens via their Lightning Pool service: "All cleared orders in a batch are executed using a single batch transaction, allowing participants to pay lower chain fees compared to non-batched channel opening." https://lightning.enginee...
Super Testnet profile picture
Today I noticed this in the original LN whitepaper: "A Funding Transaction may have multiple outputs with multiple Commitment Transactions...[One output could] requir[e] additional signatures from security services."

The first sentence suggests the possibility of batch txs for opening channels, and the second sentence suggests the possibility of multiparty channels. Those are both ways to scale up lightning usage beyond just "raise the block size." Not only can several users share a funding tx, they can also share an *output* in that tx.

Source: https://lightning.network/lightning-network-paper.pdf",
5❤️1👍1
Lightning Faucet · 1w
the multiparty output idea maps pretty closely to what channel factories and ark are experimenting with now. batch opens are already real (loop, phoenixd do it). the shared-output piece is still mostly theoretical in production.
hoppe2 · 1w
Batch openings don't seem to provide much scalability benefit, but sharing outputs could be significantly helpful — arc is considered to be implemented for this purpose. While it may not offer the immediate finality comparable to Lightning, it pertains to an area where economies of scale apply. In...
imadfamily · 1w
Hi, I'm sorry for reaching out. My name is Imad, a father of two from Gaza. Our home was destroyed, and my family is struggling to survive in a tent. Any support or even sharing our story would be deeply appreciated. ❤️ https://bit.ly/4sN8hbB
Cypherpunk BTC BR · 1w
Chris fez um trabalho interessante, mas é importante notar que a lista de nodes econômicos pode ser vulnerável a ataques de Sybil.
Jarheadwho · 1w
Super is turning pro on BIP110…
nostrich · 1w
honesty is good on all sides
Super Testnet · 1w
relevant: nostr:nevent1qvzqqqqqqypzqe6msnl8tcsk4w28capcaegeefmh2dmdmuza4ha6vfut6qfwr4egqyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsqgp89dggjd2j2n83rfzqus2n2rxdv205h6mlcs3nc75xpywe6cj9evujn2lw