LaurieRobles06U

bitcoin_beginners

# a single payment to a single recipient

Lightning wallets assume a single recipient for a single payment. Alice can send money to Bob in a single payment, and Alice can send money to Carol, but Alice cannot send money to both Bob and Carol in a single payment. Alice, or her wallet, must pay each independently and it's possible that Alice's payment to Carol succeeds while Alice's payment to Bob fails. On lightning, coordinating a single payment (ie input) to more than one recipient (ie outputs), where all recipients are paid or none are paid, is left to Alice and Bob and Carol to figure out. Maybe lightning wallets shouldn't coordinate a single payment with more than a single receiver in a trust minimized way, but it'd be useful, and surprisingly so, if they did.

# most lightning payments pay multiple recipients

When Alice pays Carol on the lightning network, Alice's money often travels through several other lightning nodes before arriving at Carol's lightning node. The nodes that Alice sends her money through don't do this for free. Alice pays them. What's more, those other lightning nodes only get paid by Alice if Carol gets paid. Those other lightning nodes are effectively Bob(s) from the previous section's example; that is, the other lightning nodes are additional trust-minimized recipients as part of Alice's payment to Carol. Only, those other lightning nodes are secondary to Alice's payment to Carol.

In the lightning protocol as-is, Carol can't make sure Alice's money travels through a specific Bob, and Bob can't enforce that Alice pays Carol through him. If Carol and Bob don't trust each other *nor* Alice, yet both *can* agree to receive money from Alice only if the other also gets paid, the lightning protocol as-is can't help them. If Carol and Bob want to enter such a contract, they have to get creative.
# trust minimized split payments enable trust minimized coordination

The lightning network coordinates delivery of bitcoin from Alice to Carol by paying several Bobs to move their bitcoin in Carol's direction. By design, Alice, the Bobs, and Carol don't need to trust each other much to do this. Ideally, they wouldn't need to trust each other at all. Less required trust means less required permission and less required permission means more freedom, opportunity, and competition. People want to coordinate and if they can't do so in a trust minimized way, fewer people will coordinate and the coordination that does happen will tend to be centralized.

# splitting a payment atomically and downstream is better ux

Imagine swiping your credit card five times when you buy something, once to pay Visa, another to pay the merchant, another to pay the merchant's landlord, another to pay the supplier, and another to pay the manufacturer. Now imagine the payment to the supplier fails and continues to fail, then swiping your card four times to get a refund from everyone you paid. If the complexity of Visa, the merchant, the landlord, etc coordinating with each other is thrust on the customer, the customer will prefer a merchant that doesn't expose the complexity, and such a preferred merchant will have more trusted relationships with the other parties.

That's a toy example, but we do atomic split payments on bitcoin's base layer because it's plain practical. Imagine paying two invoices to your LSP when you want to open a channel. What should they do with your funds when the second payment doesn't arrive? Or how about creating two bitcoin transactions every time you want to pay someone, one to pay the miner and one to pay the receiver? 

Atomicity means that when receivers coordinate they don't need to trust each other fully, and if the split happens downstream, the UX for the sender is identical whether there's one receiver or many.

# today's hacks are tomorrow's solutions

One way to be certain people want something is that they trip over themselves for solutions that work poorly. When they *really* want something, they create elaborate, inelegant, risky hacks that give them the faintest whiff of a satisfying solution. Should a better solution exist, you *know* they'll use it.

# hold invoices

Most non-wallet lightning companies (ones that don't have the luxury of going on-chain for atomic split payments) have currently implemented or at least explored using [hold invoices](https://bitcoinops.org/en/topics/hold-invoices/) for split payments. [Geyser does this](https://geyser.fund/entry/252) to non-custodially take a platform fee. [Robosats does this](https://learn.robosats.com/docs/escrow/) to fulfill an order conditional on an escrow agent's approval (their solution is custodial though because they can't be sure the buyer will be online to accept the payment). Mash once [explored this](https://blog.yonson.dev/log/2023-07-vol1/). [lnproxy](https://lnproxy.org) does this to hide a receiver's node from senders and proxies get paid to do so. We plan to cautiously do this [to take our sybil fee non-custodially](https://stacker.news/items/523435).

Using hold invoices this way allows applications to be Bob when their customer Alice pays their customer Carol. It's elaborate, inelegant, and risky, but any other solution is custodial, trusted, or imposes new requirements on the sender and/or receiver. These hold invoices give Alice, Bob, and Carol a way to coordinate a split payment without Bob or Carol taking custody of the other's funds, or trusting that Alice is willing and able to send funds to both of them. It also hides the identity of Carol's lightning node from Alice which is otherwise exposed.

This use of hold invoices recreates how a lightning node forwards a payment, using the familiar preimage and CTLV enforcement, but does so at the application layer. When Alice tells Bob she wants to pay Carol, Bob requests an invoice from Carol. Bob then wraps the invoice, meaning Bob's invoice is conditional on Carol's invoice being paid, and sends it to Alice. Alice then pays Bob's wrapped invoice and because Bob can't redeem Alice's payment without first paying Carol, Bob pays Carol and then claims his funds from Alice. Hence, at no point is Bob in custody of Alice's funds meant for Carol. And, when Bob wraps Carol's invoice, he can add an additional split payment to himself.

# many payments to many recipients 

The main, in-use alternative to the hold invoice approach is requesting Alice pay each Bob and Carol independently. One popular example of this approach is [nostr prisms](https://www.makeprisms.com/). Using programmatic wallet connections, an application requests invoices from an arbitrary number of Bobs and Carols, then sends them all to Alice's wallet to pay one by one. Pending adoption of a [soon to be merged(?) lnurl spec](https://github.com/lnurl/luds/issues/182), Bob might even be able to request proof that Alice paid Carol (assuming Carol isn't in cahoots with Alice to trick Bob).

# bolt12 and blinded paths

If I'm not mistaken, [Bolt12](https://bolt12.org/)'s blinded paths, when adopted widely, should replace the hold invoice approach. If Bob is provably the introduction point to a blinded path in an amount-less bolt12 offer that pays Carol, then Bob can enforce that he'll be paid when Alice pays Carol. Using this approach, it might be possible for several Bobs to be predictably paid when Carol does, assuming blinded paths can contain other blinded paths. This isn't my exact dream of a single payment being split along independent routes, to different receivers, with codependent settlement at the protocol layer, but maybe novel forms of decentralized coordination can wait for bolt13.

Atomic Split Lightning Payments, Hold Invoices, and Blinded Paths

Signal Facing Collapse After CIA Cuts Funding

I created an open-source Blockclock clone, you can build it for ±70 USD

news

I’ve been using Unchained Capital for quite a few years and have been very happy with them. They had a modest set up fee for my multisig vault and besides set up I just contacted them to double check my UTXO consolidation. Overall very pleased with them.

We’ve talked before about inheritance planning  on SN and for me I’m the most technical in my succession plan as of now (let’s see how my boys are as they get older). While technical I also don’t personally feel comfortable being 100% responsible for my entire stack given the future value I’m assuming so I like having assistance if needed. Yeah yeah I get Bitcoin is for the fully sovereign individual, but it’s also for Everyone who wants freedom money.

Ok ok so now, Unchained is charging $250 a year for support. This is a big increase from $0, but not a % of your stack so depending on how much you have, this is a lower fee than trad fi. I am planning to pay the fee this year as it’s due in a few weeks. Anyone else feel comfortable sharing that they use Unchained? I also see they have a section for a discount code. A long shot, but anyone else know how to get one so that I can preserve some sats?

Other than unchained capital I know there are other multi sig set ups that I may look into. On ramp sounds interesting. Anyone use them? 
 
Lastly to follow up on inheritance, Unchained has some free material:

Hi-level : https://help.unchained.com/unchained-inheritance-materials

Detailed plan: https://8198895.fs1.hubspotusercontent-na1.net/hubfs/8198895/Unchained%20Inheritance%20Protocol.pdf

Thanks!


Unchained Capital - The free ride stops now

Bitkit Wallet AMA - John Carvalho, CEO of Synonym

FrederickDavilaOKN

I want SN to stick around, so by association, I want this change. 

tech

Hi Stacker News!

I'm excited to share my new project Preturnio (https://preturnio.com) - a full-text search engine for Bitcoin. With Preturnio you can search for text inside every OP_RETURN, Coinbase transaction and ordinal transaction since the genesis block (block 0).

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_1.gif)

Block explorers can search for transactions, blocks and addresses but searching for arbitrary text is a challenge. Data is stored in the blockchain natively in hexadecimal format and not easily readable by humans. Preturnio solves this with an easy-to-use search interface. Just enter the text you’re looking for and Preturnio will return highlighted results found in any OP_RETURN, Coinbase or Ordinal transaction. See when the data was created, which block it was confirmed in and other relevant details.

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_3.png)

You can search for anything: source code, names, quotes, brc-20 tokens – any plain text you can think of, you can find in the blockchain with Preturnio.

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_4.png)

Share transactions with a direct link or even a preview image. Posting to Twitter will automatically create a Twitter card.

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_5.webp)

Ordinals are supported! Each inscription can be previewed inline or full screen. We support all transactions encoded with text-supported MIME types.

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_6.png)

We categorize inscriptions into two buckets – text and HTML. You can toggle to source code view with a familiar search interface to find the text you’re looking for inside the inscription payload. When you share an inscription, Preturnio will try to include a preview of the inscription whether it’s text or HTML.

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_8a.webp)

Once you’ve found your inscription, you can then search inside it with a familiar ‘Find’ experience to look for specific text. Here’s an example of looking through some HTML code of an inscription:

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_9.png)

Searching *inside* inscriptions is your new ordinal super power 💪. Looking for the receiving address of a specific BRC-20 token? Just search for the receiving address. Here’s an example:

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_10.png)

We’re big fans of the Ordinal News Standard - Preturnio detects inscriptions that adhere to the standard and exposes direct links to compatible news explorers to instantly read the news. See an example here: https://www.youtube.com/embed/EdsqYC5vZzE

Don’t trust Preturnio? You shouldn’t - so naturally each search result can be verified with a single click to on one of several public block explorers as well as ordinal explorers for inscriptions. It's also easy to copy the TX ID to verify on your own node.

![0](https://sfo3.digitaloceanspaces.com/preturnio/public/tweet_12.png)

Preturnio has also cross referenced all transactions against a published list of all known English words (more languages coming soon) so you can browse individual words stored somewhere on the blockchain. This is actually a lot of fun! See an example here: https://www.youtube.com/embed/7kVcQ909XMg

Check out the docs to learn about other search features supported. Feedback is encouraged and appreciated. Thanks for welcoming Preturnio - now go out there and find some cool stuff buried in the Bitcoin blockchain at https://preturnio.com

Jonathan.



Show SN: Preturnio - a full-text search engine for Bitcoin

Especially for those of us who have been on stacker.news a little longer, this is really important. I was lucky enough to to re-gain access with some help from @k00b and @alby support, but based on what I'm hearing, I gather there's some people who have lost access for good.

Here's a quote from Alby:

>Lightning Login was implemented in different ways by different wallets. This also adds some problems when attempting to make it a standard. The way Alby implemented it with the custodial accounts was indeed related to the lndhub credentials. This brings two problems: you depend on Alby's for your account since the login is linked to a custodial account. And with newer lndhub credentials, when those are renewed, you will lose the login. only legacy lndhub lightning login accounts could be recovered. But legacy lndhub credentials are somehow a security risk because they do not expire. All of these complications are simply to strongly recommend you to link your stacker news account to additional auth options as stated in the first part of the email.

Here's how to do it:
- Click on your profile name, top right, to drop down the menu. 
- Choose Settings in the menu
- At the very bottom of the Settings screen is the Auth Methods section. You can add additional authentication methods such as Nostr, Github, Email, etc. 