15928 stacked

I'll make an exception for you jaffy. Before super testnet my name was geistlight.

Lego blocks are primitives for making lego buildings

Key tweaking is one of many cryptographic primitives for making bitcoin applications

I'm not familiar with the term "shared secret pattern." The inspiration was bip47.

Both parties don't need to be online at the same time, you can email the whisper key to the recipient whenever you want, including while he's offline. The money will stay in the whisper address until the recipient uses the whisper key to sweep it into his wallet or send the money to someone else. There's no time limit, he can wait as long as he wants to get and use the whisper key.

Other than that you got it right. Another wrinkle with whisper addresses is that it involves a one-way communication and that is not automated at all, at least not in the current state. If the sender of the money refreshes the page or forgets to send the email or does any of the myriad things that people do to make a mistake, he will lose his donation and the intended recipient will never receive it. (That may be easy to mitigate by making the user click a button whenever they generate a whisper address. Then I could use an automatic email or something like nostr to automatically send the newly-generated whisper key to the recipient. But it would also make it easier to spam him with whisper keys that don't hold any value.)

Other issues that people pointed out on telegram include:

  • it doesn't help your privacy if you dox yourself to an exchange

  • the police could do a sting operation by sending you some money, waiting for you to consolidate it with your other funds, and then confiscating the total the next time you send it to an exchange

  • (BTW noobs consolidate their funds all the time. Noob-friendly wallets actually do it automatically on the assumption that it's what a noob would want)

  • if the whisper keys are sent via email then email is the new point of failure. Trudeau can tell google "show us all the emails containing whisper keys" and google will probably be happy to do it. Once they do that, your whisper addresses are doxed, assuming they know your linking key (which is supposed to be public on your website)

Putting address generation behind a generate button is a very good idea. I'll have to change the template message too. Instead of "you received money" it will have to say "maybe you received money" or similar.

Nostr payloads are not currently charged for, they are free. So you're not paying for them.

I'm definitely on board with sending whisper keys to the recipient via nostr. It would be a bit of spam though for any popular site because most whisper keys will never be used. But I can make a toggle when generating your linking key to "turn on nostr backup" or similar, where you put in your nostr pubkey and then your site will send an encrypted message to you every time someone generates a whisper key on your website.

The Omnibolt Daemon (OBD) is definitely a fork of LND and it's a btc-compatible fork, which means, the bitcoins in OBD are on the real lightning network, you can open channels to any other lightning user without them needing to run your fork, and you can send them bitcoins over those channels. But the USDTs in OBD require something like a parallel network, with its own set of channels. So I would say that's two networks, the "real" lightning network with bitcoins on it and an "omni" lightning network with omni tokens on it, one of which is USDT.

On the other hand, altcoins have been "on the lightning network" since day 1 (namely, Litecoin) and it is possible to use submarine swaps to transfer bitcoins over that network and "back into" the real lightning network. The same is now true of USDT. Which means the two networks are connected. And if they are connected, are they really just one big network or they still two separate ones? I'm not sure how to answer that but I hope this explanation helps.

This article is pretty helpful, I have a criticism. The human readable label for p2sh addresses says they are "wrapped segwit" addresses. I think that's a poor label because they are much more generic than that. They can encode any script and were used for multisig transactions long before segwit came out. Consider labelling these "script addresses" because they are the hash of a script and must be spent by satisfying the conditions of that script.

This is a fascinating post. One thing I've heard recommended for learning Latin -- after learning the basics -- is to jump straight into translating stuff from Latin into English with a Latin-to-English dictionary at your side.

There are lots of fiction books that have been Latined like Alice in Wonderland, Harry Potter, and the Hobbit. Get one of those and translate it back into English page by page. If you can do that, even with the help of a dictionary, you will be in a great position to read the classics and the vulgate and the medieval or renaissance works too.

Follow along with the tutorial instructions here: https://github.com/supertestnet/lightningescrow.io/

Start building on lightning escrow today!

How did you come up with the idea for lntxbot?

Don’t you have to kinda be officially partnered with businesses though?

No, it's an open api so other companies can integrate it without telling us.

you seemingly need some information about the kind of transactions so you know how to fairly arbitrate them. Like if you’re an escrow for particular products, you need to understand what is and is not expected. Or what the customer did or did not agree to.

Companies or individuals who integrate our api get nice easy api endpoints to settle or cancel payments themselves. They can create accounts on behalf of their users, display the qr codes, and do all the interactive bits for them, hitting the right endpoint when it's time to decide who gets the money. And yeah we just take a 1% cut every time (once we're out of beta) without needing to know what exactly is happening or what the contract is for.

I still need to document the api though and probably do a hello world tutorial and an explanation of some of the things developers can build on top of this.

Yes, the ux is terrible. I'm only a backend engineer, I don't know how to build a beautiful GUI. But you know what's cool about building it the way I did? Reliability. If the buyer has a path to the seller, the contract is guaranteed to work. If he doesn't, the contract never happens. I decided to build something ugly and reliable and hire someone to fix the ui later if/when we get funding rather than build something pretty that only works sometimes. It's a trade-off but I'm confident that I made the right choice, because it's easier to make ugly software pretty than it is to make broken software work.

The server never takes custody of funds, not even for a second (unlike p2plnbot), but I hesitate to use the phrase "100% non-custodial" on what is essentially a 2-of-3 multisig.

From the buyer's perspective, the moment you hit "send" on your wallet you no longer have control over that money. It is now contractually locked in an htlc where the seller can take the money if the escrow gives him the preimage, or -- if the escrow does not give the seller the preimage -- the payment will time out within 2 weeks and the buyer will get his money back.

I'm not sure what to call that. It's not "100% non custodial" because you, the buyer, no longer control what happens to the money. It's also not "100% controlled by the seller" because he can't take the money without help from the escrow. It's also not custodied by the escrow at all, not even for a second, because all the server is doing is giving a preimage to the seller or withholding it.

The term Unchained Capital uses for their similar setup is "collaborative custody." That is the term that I think fits best.

I absolutely agree! It has a rest api which is already fully functional btw >:D Any third party who wants to build on top of this can call the api commands and programmatically execute trades and/or refunds on behalf of their users, and we'll just take a 1% cut each time. (Well, right now we aren't taking any cut at all, but eventually we will.) I haven't documented the api but it's what the frontend uses so anyone can check the html to see how it works. For example, the code for creating a new escrow transaction looks like this:

1 function makeTx() { 2 var buyer_email = document.getElementsByName( "buyer-email" )[ 0 ].value; 3 var goods_or_services = document.getElementsByName( "goods-or-services" )[ 0 ].value; 4 var transaction_title = document.getElementsByName( "transaction-title" )[ 0 ].value; 5 var transaction_details = document.getElementsByName( "transaction-details" )[ 0 ].value; 6 var fee_payer = document.getElementsByName( "fee_payer" )[ 0 ].value; 7 var amount = document.getElementsByName( "amount" )[ 0 ].value; 8 var params = "buyer_email=" + buyer_email + 9 "&session_id=" + localStorage.session_id + 10 "&goods_or_services=" + goods_or_services + 11 "&title=" + transaction_title + 12 "&description=" + transaction_details + 13 "&fee_payer=" + fee_payer + 14 "&amount=" + amount; 15 var xhttp = new XMLHttpRequest(); 16 xhttp.onreadystatechange = function() { 17 if ( this.readyState == 4 && this.status == 200 ) { 18 var json = JSON.parse( this.responseText ); 19 if ( json.status == "success" ) { 20 window.location.href = "/seller-payment.html?tx=" + json.id; 21 } 22 } 23 } 24 xhttp.open( "POST", "/settx/", true ); 25 xhttp.setRequestHeader( "Content-type", "application/x-www-form-urlencoded" ); 26 xhttp.send( params ); 27 }

What changed?


The article doesn't mention that anything changed

It says everything changed


J/k I think it's just marketing talk

Yeah it's my protocol, Tristan's website