Ben Carman [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-06-28 to 2023-05-22
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-07-27 00:22:35

- reply

📅 Original date posted:2023-07-25
🗒️ Summary of this message: Blinded paths in the Lightning Network can have a downside for privacy and decentralization, as they can enforce that only "compliant" nodes can reach a destination. This could lead to routing only through large regulated hubs, hurting payment reliability and sender side privacy. There is concern that lightning "chain analysis" companies could pressure businesses into implementing this.
📝 Original message:
Hi list,
This is an idea I had the other week about a potential downside of blinded paths that people should be aware of.
Blinded paths work by encrypting specific paths to reach the destination node, and each of these paths have an introduction point.
This has big privacy benefits for the receiving node as they can hide among an anon set of anyone within X hops of the introduction node (X being the size of the blinded path).
However, this can have a potential downside for privacy and decentralization on the network as a whole.
With blinded paths since you do not know the destination node the only way to pay them is through one of the given paths.
Because of this, they can be used to enforce that "compliant" nodes are the only ways to reach a given destination.
In my experience today you can get away with telling your compliance officer you will only open channels with people you trust, and we see this with some regulated businesses today (Cash App & River only open to sepcific peers).
However with blinded paths we could have a world where not only do they only open channels to specific peers but they enforce that when paying them, the payment must go through at least N "compliant" nodes first.
This would make it so the pleb routing nodes of today would be completely circumvented and users would be forced to route only through large regulated hubs.
The receiver would be hurting their payment reliability as they are removing potential paths they can receive from, but this is already the case for all blinded paths.
This could hurt sender side privacy as well, since payment reliability rapidly falls off the more hops that are needed it is likely the sender would need to be very closely connected the introduction node or any of the nodes along the blinded path, and if all these compliant nodes are data sharing they'll be able to track a payment as it happens through the network just through basic timing analysis.
My concern is lightning "chain analysis" companies could strong arm businesses into doing things like this under the guise of making sure you don't receieve OFAC coins. However, I am not sure if this is a "fixable" problem and just a trade off we'll have to make to get receiver privacy in lightning but wanted to put out there for people's opinions/awareness.
Best,
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230725/368cd2ad/attachment-0001.html>

2023-06-19 17:42:32

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: A potential griefing attack on LSPs providing Just-In-Time channels has been identified. The attack can be prevented by using PTLCs to sign the funding transaction.
📝 Original message:
Hi everyone,
I was chatting with Tony Giorgio the other day and he made me aware of a potential griefing attack that is possible today on LSPs that provide Just-In-Time channels.
The attack is very simple, when the LSP receives the payment and then opens a 0-conf channel to the client, the client could not claim the payment thus resulting in the LSP not getting paid and the client getting a free inbound lightning channel. The LSP could double spend the transaction but they still would lose the miner fees and as we are seeing today, that can be very expensive.
I am not sure if this has been proposed before but we can fix this with PTLCs!
Instead of having the LSP just broadcasting the funding transaction to the mempool, they can sign the funding transaction using adaptor signatures locked to the same secret as the invoice. Then when the client wants to claim the funds they can get the funding txid from the LSP, and then do the PTLC dance with the LSP based on using that funding transaction. If it all goes as planned the LSP can give the funding transaction signed using adaptor sigs to the client and the client can then decrypt the signatures and broadcast the transaction. Then the LSP can find the transaction in the mempool and extract the secret they need to claim the payment, thus making claiming the payment and opening the channel atomic so the client can't grief the LSP.
Not sure if this has been talked about before, if not I think we can throw it in the ever-growing pile of "PTLCs fixes this".
Best,
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230509/c7926ee7/attachment.html>

2023-06-09 13:13:23

- reply

2023-06-09 13:08:53

- reply

📅 Original date posted:2023-05-09
📝 Original message:
Hi everyone,
I was chatting with Tony Giorgio the other day and he made me aware of a potential griefing attack that is possible today on LSPs that provide Just-In-Time channels.
The attack is very simple, when the LSP receives the payment and then opens a 0-conf channel to the client, the client could not claim the payment thus resulting in the LSP not getting paid and the client getting a free inbound lightning channel. The LSP could double spend the transaction but they still would lose the miner fees and as we are seeing today, that can be very expensive.
I am not sure if this has been proposed before but we can fix this with PTLCs!
Instead of having the LSP just broadcasting the funding transaction to the mempool, they can sign the funding transaction using adaptor signatures locked to the same secret as the invoice. Then when the client wants to claim the funds they can get the funding txid from the LSP, and then do the PTLC dance with the LSP based on using that funding transaction. If it all goes as planned the LSP can give the funding transaction signed using adaptor sigs to the client and the client can then decrypt the signatures and broadcast the transaction. Then the LSP can find the transaction in the mempool and extract the secret they need to claim the payment, thus making claiming the payment and opening the channel atomic so the client can't grief the LSP.
Not sure if this has been talked about before, if not I think we can throw it in the ever-growing pile of "PTLCs fixes this".
Best,
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230509/c7926ee7/attachment.html>

2023-06-07 23:21:57

- reply

📅 Original date posted:2023-05-22
🗒️ Summary of this message: Using ALL|ANYONECANPAY in coinjoin can reduce steps, but it poses risks such as adding unwanted inputs, lower fee rates, and lack of uniformity. Verification code is available.
📝 Original message:The problem with using ALL|ANYONECANPAY is that you cannot verify beforehand that the other inputs are the inputs you want added to the transaction.
Some examples of bad things that could happen:
* Coordinator adds its own inputs, you still get your outputs but effectively paid fees for no privacy gain
* The inputs added could be paying at a lower fee rate than expected, causing the tx to take longer than what you paid for
* Different input types or amount are added so you no longer have the same uniformity across the inputs
* (if you care) An input from a sanctioned address is added, causing you to get "tainted" coins.
This is the code in ln-vortex that verifies the psbt on the client side if you are curious
https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616
Best,
benthecarman
________________________________
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Monday, May 22, 2023 7:51 AM
To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
Hi Bitcoin Developers,
I recently experimented with different sighash flags, PSBTs and realized ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
Steps:
- Register outputs.
- One user creates a signed PSBT with 1 input, all registered outputs and ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs to PSBT.
- Finalize and broadcast the transaction.
Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297
Tx: https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492
I plan to use this in joinstr if there are no major drawbacks and it can even be implemented by other coinjoin implementations.
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230522/9d45d394/attachment-0001.html>

2023-06-07 23:18:33

- reply

📅 Original date posted:2023-01-12
🗒️ Summary of this message: A proposal suggests using OP_UNVAULT with a burn address and a delay period of 0 as a not-so-simple covenant, similar to CTV, to create output restrictions. This could save computational costs but use more blockchain space.
📝 Original message:Hi list,
After reading through James's OP_VAULT proposal this week, I had a realization that this can be used for more than a deep cold storage wallet.
Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output.
When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (ie OP_RETURN `<random value>`)
and the `delay-period` to `0` we can use it as a not-so simple covenant with the `unvault-target-hash` being
set to whatever output restrictions you want to create.
Given this we can recreate a lot of what CTV promises, one of my favorites being
[Lloyd's improvement to DLCs](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html)
(I recommend reading that first)
A similiar construction could be done by creating a taproot tree similiar to LLoyd's construction with each leaf looking like:
`<hash-of-burn-spk> 0 <CET-hash_i> OP_UNVAULT <CET_i> CHECKSIG`
In the same as Lloyd's proposal: when the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose `unvault-target-hash`
hash is `CET-hash`) which distributes the funds according to the contract.
## Comparison
Compared to the original CTV proposal, this should get all the same computational savings. However, it would use more blockchain space.
The main downside I see is our final spending script will be slightly larger.
Instead of just having `<hash> OP_CTV` it will be replaced with `<hash> 0 <hash> OP_UNVAULT` (34 bytes extra, not including the witness discount).
However, this may be negligible in the case of a DLC with many outcomes as a lot of the input size will be coming from the control block.
This also can always be skipped by doing a cooperative close of the DLC if the internal-key of the taproot tree can be spent using something like MuSig.
I imagine a lot of the other applications for CTV can be recreated with OP_VAULT using this same trick.
# Credits
- Lloyd Fournier for the original proposal
- James O'Beirne for the OP_VAULT proposal and giving me the idea to skip the intial OP_VAULT and just use OP_UNVAULT
Best,
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230112/192b1f7f/attachment.html>

2023-06-07 22:54:34

- reply

📅 Original date posted:2021-06-28
📝 Original message:> If nSequence is set it should apply only to the first input of the
transaction, if it has multiple inputs.
This could have complications with DLCs and dual funded lightning. In both protocols the ordering of the inputs is not know until both parties have revealed all of their inputs, and during the reveal the nSequence is given. If we want DLCs and dual funded lightning to be compatible it would be better to have it define it as “at least one of the inputs of the transaction” instead of “it should apply only to the first input of the transaction”
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210628/88dc0ff3/attachment.html>