Dario Sneidermanis [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-21 to 2022-10-21
💬 Posted a total of 12 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Opt-in full-RBF, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:56:08

- reply

📅 Original date posted:2019-09-09
📝 Original message:
We went ahead with this idea and implemented it in muun wallet as an
experiment: you can scan an invoice, and if there isn't a route with enough
capacity to the destination node, we'll open a channel directly and, once
it's locked, fulfill the payment using that channel.
The initial idea was to improve the UX of not being able to route a
payment. However, since we have to wait until the channel is locked to make
the final hop of the payment, the full process might take about an hour,
depending on the block times. That generates a couple of UX challenges:
* The user is expecting lightning payments to be completed instantly, so it
might be preferable to fail the payment rather than locking it for an hour
until the channel is opened.
* Most invoices in the wild have 10/15 minute expirations, so they don't
even qualify for doing something like this.
* Even if the user generates the invoice manually, most interfaces default
to 1 hour expiration, which might be too little time.
Given these constrains, we decided that the best application for this flow
is to top-up your own node. That is, add outbound capacity to your node in
a non-custodial manner. We'd love to hear if you have some idea as to how
to make this use case better, or apply this concept to other use cases.
On Fri, Aug 16, 2019 at 12:58 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Dario,
>
> > Having said that, if the usability of the scheme "open channel, wait
> until it's locked, then send HTLC payment" were deemed good enough, then
> routing nodes could implement this idea to route payments "just in time",
> even if there aren't any pre-existing routes to the destination.
>
> This is a good idea, but one with some difficulties in implementation.
>
> * The current onion route format contains the next short-channel-id (and
> in particular not the node-id of the next hop in the route).
> Indeed, short-channel-ids were invented to reduce the size of the onion
> route format.
> If a channel used to exist between nodes, then the payer might have
> gotten this short-channel-id in the past via gossip.
> Then later, if the channel is closed, most implementations will forget
> the short-channel-id (and thus would probably also forget *which* node the
> short-channel-id used to be connected to, so determining the next node for
> the just-in-time channel opening would be difficult).
> * C-Lightning retains this information for some blocks but will forget
> it at some point.
> * Implementations that do this "just-in-time" channel-opening will need
> to remember this short-channel-id for longer.
> * The final HTLC going to the payee has the tightest time schedule.
> If this HTLC has a timeout that is too near, the payee will reject the
> payment.
> Since channel opening requires blocks to pass in order to confirm the
> funding transaction, by the time the HTLC reaches the payee, the timeout
> might now be judged too near and the payee will reject the payment anyway.
> * The spec itself recommends the use of "shadow routing".
> Briefly, the payer obscures who the payee is by adding a greater
> timeout to the payee than the minimum required by the payee.
> (since timeouts decrease at each hop, an intermediate node can guess
> who the payee is by determining how small the remaining timeout looks.)
> This can mitigate the above effect.
> C-Lightning implements shadow routing.
>
> However, this same idea would be greatly helped by trampoline routing:
>
> * The planned trampoline routing indicates the node id of the next
> trampoline hop, thus not requiring implementations to remember who a closed
> short-channel-id used to be connected to.
> * Trampoline nodes will generally require a much larger fee and timelock
> budget, because they also have to build routes.
> If the fee and timelock budgets are big enough, then the trampoline node
> might decide to open a direct channel to the next trampoline node
> "just-in-time" for the next trampoline hop.
>
> Regards,
> ZmnSCPxj
>
> >
> > On Wed, Aug 14, 2019 at 8:42 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > > Good morning Ecurrencyhodler,
> > >
> > > It seems to me a trusted model then.
> > > Regardless of who makes the channel (the payee cannot determine who
> the payer is anyway) the payee cannot trustlessly release the product until
> the channel is deeply confirmed, else your security is only 0-conf, not
> off-chain.
> > >
> > > Further, `push_msat` has the drawback of not providing
> proof-of-payment, thus an intermediate hop node may be unable to claim
> funds.
> > > (I believe `push_msat` was a mistake: you should simply make a normal
> HTLC payment (that provides proof-of-payment) after the channel is deeply
> confirmed, and `push_msat`, if you read lightning-rfc, does have this
> warning that you cannot trust money you receive that way until the channel
> is deeply confirmed.)
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Thursday, August 15, 2019 2:05 AM, ecurrencyhodler <
> ecurrencyhodler at gmail.com> wrote:
> > >
> > > > >So would `push_msat`; until confirmed deeply the channel opening
> can still be cancelled by double-spending and it would be foolhardy to
> deliver the product until the channel is deeply confirmed to be opened.
> > > >
> > > > Okay so there's 2 situations here I'd like to explore:
> > > >
> > > > 1. Bob -> routing node -> Me
> > > >
> > > > 2. Bob -> Me
> > > >
> > > > Scenario 1
> > > > If Bob pays the invoice and the routing node opens a payment channel
> and pushes sats to me, you could stipulate that the routing node isn't able
> to fully take ownership of the sats until 6 confirmations potentially via
> Hodl Invoices (by the time the routing nodes channel with pushed payments
> confirms with mine). But I could still make LN payments instantly through
> the routing node because the routing node just needs to wait until the 6
> confirmations and settle all accounts after the fact.
> > > >
> > > > Scenario 2
> > > > Bob and I know each other so if channel disappears, it's basically
> the same situation with Thor's instant channel. But we could completely
> remove scenario 2 and only allow routing nodes to open channels to me as
> long as Bob makes the payment.
> > > >
> > > > On Wed, Aug 14, 2019 at 12:03 AM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> > > >
> > > > > Good morning Ecurrencyhodler,
> > > > >
> > > > > > Hi ZmnSCPxj!
> > > > > >
> > > > > > Submarine swaps are a great current solution, but we still have
> to wait for confirmations.
> > > > >
> > > > > So would `push_msat`; until confirmed deeply the channel opening
> can still be cancelled by double-spending and it would be foolhardy to
> deliver the product until the channel is deeply confirmed to be opened.
> > > > > At least this way, you can perform the preparation in parallel to
> your other startup operations for starting your business before actual
> launch of your merchant website.
> > > > >
> > > > > >
> > > > > > >Further, while it involves fees, it does give you control over
> what nodes you make channels with, and would be a good investment in your
> future accessibility over the Lightning Network.
> > > > > >
> > > > > > What disadvantages do you see over this proposal and say
> something like autopilot? Or do you just prefer manual channel management
> overall?
> > > > >
> > > > > This should eventually be implementable by some kind of
> auto-system.
> > > > > It is still early days and a lot of infrastructure is yet to be
> written.
> > > > >
> > > > > Regards,
> > > > > ZmnSCPxj
> > > > >
> > > > > >
> > > > > > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj <
> ZmnSCPxj at protonmail.com> wrote:
> > > > > >
> > > > > > > Good morning Ecurrencyhodler,
> > > > > > >
> > > > > > > A current and practical way to set up incoming liquidity would
> be to take some onchain funds, create a channel to a high-uptime node on
> the network (just run an autopilot), then use a submarine swap (i.e. pay
> offchain funds to buy onchain funds).
> > > > > > > Then you can reuse the same onchain funds over and over to
> make more liquidity until the submarine swap provider runs out of onchain
> funds or you have sufficient liquidity or your money has been drained by
> the fees involved.
> > > > > > >
> > > > > > > While this requires onchain funds, presumably as a new
> business or merchant you will have capital in some form before starting
> your business.
> > > > > > > The most sensible way to store and transport financial capital
> is, of course, Bitcoin, thus you already have what is needed to start this,
> you simply have to do it before you perform other operations.
> > > > > > > Further, while it involves fees, it does give you control over
> what nodes you make channels with, and would be a good investment in your
> future accessibility over the Lightning Network.
> > > > > > >
> > > > > > > Regards,
> > > > > > > ZmnSCPxj
> > > > > > >
> > > > > > > Sent with ProtonMail Secure Email.
> > > > > > >
> > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > > > On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler
> Blockchains <ecurrencyhodler at gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi. I'd like to propose a way for instant inbound liquidity
> to be automated via invoices and would appreciate your feedback. It's
> similar to Thor's instant channel but this proposal would only be valuable
> if it becomes a standard across all lightning implementations and wallets.
> It won't work if it's limited to just one Lightning wallet.
> > > > > > > >
> > > > > > > > Proposal: Automated Inbound Liquidity With Invoices
> > > > > > > >
> > > > > > > > For Who: Full Lightning Network nodes
> > > > > > > >
> > > > > > > > Problem: Waiting for inbound liquidity as channel
> establishes when you first come online and want to receive a LN payment.
> > > > > > > >
> > > > > > > > Solution: Embedding the node uri of the invoice creator,
> along with amount to be routed.
> > > > > > > >
> > > > > > > > Scenario:
> > > > > > > >
> > > > > > > > 1. Bob wants to send me 100,000 sats.
> > > > > > > > 2. My node just came online and has 0 inbound liquidity.
> > > > > > > > 3. I create an invoice for 100,000 sats. My LN node
> recognizes I have 0 inbound liquidity so my wallet also embeds my URI in
> the invoice.
> > > > > > > > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to
> route. When it doesn’t see anything, it auto opens a channel + pushes
> 100,000 sat payment.
> > > > > > > > 5. I now own and can spend 100,000 sats instantly.
> > > > > > > >
> > > > > > > > Considerations:
> > > > > > > >
> > > > > > > > - This auto establishing of channels and pushing payments
> isn’t for all LN nodes. Just routing nodes.
> > > > > > > > - Bob doesn’t need to be the one to establish the
> channel. He can push the information down the line until a node dedicated
> to routing is found. The routing node can then be the one to establish the
> channel with me.
> > > > > > > > - Certain specifics need to be flushed out such as the
> size of Bob’s channel. Right now I think Bob can manually set the size of
> the channels to be established on his end. Should be smaller channels at
> first. If the person gets paid again, just establish another channel
> towards the same node if there isn't enough capacity.
> > > > > > > > - Routing nodes who provide this service can charge a
> premium.
> > > > > > > > - Bob, as a liquidity provider, won't cheat against
> himself so I can make LN payments instantly.
> > > > > > > > - The beauty behind this proposal is that I can receive a
> payment instantly, I can send payments instantly, and that it hides
> everything from me as an end user.
> > > > > > > > - Can possibly be extended to neutrino LN wallets if they
> are public.
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190909/ef59424f/attachment-0001.html>

2023-06-09 12:55:56

- reply

📅 Original date posted:2019-08-15
📝 Original message:
Hello Ecurrencyhodler,
We've been considering this flow for muun wallet, which has native
submarine swap functionality, so it wouldn't be too difficult to implement.
However, there's some problems with the idea:
* As ZmnSCPxj notes, the push_msat functionality doesn't work for
non-custodial setups, like a submarine swap. It does work for Bitrefill's
Thor (ie. turbo channels) because you are trusting them to hold your money
until the channel fully confirms. Per the RFC, "push_msat is an amount of
initial funds that the sender is *unconditionally* giving to the receiver".
* You *can* use an HTLC payment once the channel is deep enough, but you'll
have to wait until the channel is locked to receive the money and be able
to spend it. While this might be good enough for some use cases, like
charging your own node, it doesn't provide the seamless UX for lightning
payments you're looking for.
Having said that, if the usability of the scheme "open channel, wait until
it's locked, then send HTLC payment" were deemed good enough, then routing
nodes could implement this idea to route payments "just in time", even if
there aren't any pre-existing routes to the destination.
On Wed, Aug 14, 2019 at 8:42 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Ecurrencyhodler,
>
> It seems to me a trusted model then.
> Regardless of who makes the channel (the payee cannot determine who the
> payer is anyway) the payee cannot trustlessly release the product until the
> channel is deeply confirmed, else your security is only 0-conf, not
> off-chain.
>
> Further, `push_msat` has the drawback of not providing proof-of-payment,
> thus an intermediate hop node may be unable to claim funds.
> (I believe `push_msat` was a mistake: you should simply make a normal HTLC
> payment (that provides proof-of-payment) after the channel is deeply
> confirmed, and `push_msat`, if you read lightning-rfc, does have this
> warning that you cannot trust money you receive that way until the channel
> is deeply confirmed.)
>
> Regards,
> ZmnSCPxj
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, August 15, 2019 2:05 AM, ecurrencyhodler <
> ecurrencyhodler at gmail.com> wrote:
>
> > >So would `push_msat`; until confirmed deeply the channel opening can
> still be cancelled by double-spending and it would be foolhardy to deliver
> the product until the channel is deeply confirmed to be opened.
> >
> > Okay so there's 2 situations here I'd like to explore:
> >
> > 1. Bob -> routing node -> Me
> >
> > 2. Bob -> Me
> >
> > Scenario 1
> > If Bob pays the invoice and the routing node opens a payment channel and
> pushes sats to me, you could stipulate that the routing node isn't able to
> fully take ownership of the sats until 6 confirmations potentially via Hodl
> Invoices (by the time the routing nodes channel with pushed payments
> confirms with mine). But I could still make LN payments instantly through
> the routing node because the routing node just needs to wait until the 6
> confirmations and settle all accounts after the fact.
> >
> > Scenario 2
> > Bob and I know each other so if channel disappears, it's basically the
> same situation with Thor's instant channel. But we could completely remove
> scenario 2 and only allow routing nodes to open channels to me as long as
> Bob makes the payment.
> >
> > On Wed, Aug 14, 2019 at 12:03 AM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >
> > > Good morning Ecurrencyhodler,
> > >
> > > > Hi ZmnSCPxj!
> > > >
> > > > Submarine swaps are a great current solution, but we still have to
> wait for confirmations.
> > >
> > > So would `push_msat`; until confirmed deeply the channel opening can
> still be cancelled by double-spending and it would be foolhardy to deliver
> the product until the channel is deeply confirmed to be opened.
> > > At least this way, you can perform the preparation in parallel to your
> other startup operations for starting your business before actual launch of
> your merchant website.
> > >
> > > >
> > > > >Further, while it involves fees, it does give you control over what
> nodes you make channels with, and would be a good investment in your future
> accessibility over the Lightning Network.
> > > >
> > > > What disadvantages do you see over this proposal and say something
> like autopilot? Or do you just prefer manual channel management overall?
> > >
> > > This should eventually be implementable by some kind of auto-system.
> > > It is still early days and a lot of infrastructure is yet to be
> written.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > >
> > > > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> > > >
> > > > > Good morning Ecurrencyhodler,
> > > > >
> > > > > A current and practical way to set up incoming liquidity would be
> to take some onchain funds, create a channel to a high-uptime node on the
> network (just run an autopilot), then use a submarine swap (i.e. pay
> offchain funds to buy onchain funds).
> > > > > Then you can reuse the same onchain funds over and over to make
> more liquidity until the submarine swap provider runs out of onchain funds
> or you have sufficient liquidity or your money has been drained by the fees
> involved.
> > > > >
> > > > > While this requires onchain funds, presumably as a new business or
> merchant you will have capital in some form before starting your business.
> > > > > The most sensible way to store and transport financial capital is,
> of course, Bitcoin, thus you already have what is needed to start this, you
> simply have to do it before you perform other operations.
> > > > > Further, while it involves fees, it does give you control over
> what nodes you make channels with, and would be a good investment in your
> future accessibility over the Lightning Network.
> > > > >
> > > > > Regards,
> > > > > ZmnSCPxj
> > > > >
> > > > > Sent with ProtonMail Secure Email.
> > > > >
> > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler Blockchains <
> ecurrencyhodler at gmail.com> wrote:
> > > > >
> > > > > > Hi. I'd like to propose a way for instant inbound liquidity to
> be automated via invoices and would appreciate your feedback. It's similar
> to Thor's instant channel but this proposal would only be valuable if it
> becomes a standard across all lightning implementations and wallets. It
> won't work if it's limited to just one Lightning wallet.
> > > > > >
> > > > > > Proposal: Automated Inbound Liquidity With Invoices
> > > > > >
> > > > > > For Who: Full Lightning Network nodes
> > > > > >
> > > > > > Problem: Waiting for inbound liquidity as channel establishes
> when you first come online and want to receive a LN payment.
> > > > > >
> > > > > > Solution: Embedding the node uri of the invoice creator, along
> with amount to be routed.
> > > > > >
> > > > > > Scenario:
> > > > > >
> > > > > > 1. Bob wants to send me 100,000 sats.
> > > > > > 2. My node just came online and has 0 inbound liquidity.
> > > > > > 3. I create an invoice for 100,000 sats. My LN node recognizes
> I have 0 inbound liquidity so my wallet also embeds my URI in the invoice.
> > > > > > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to
> route. When it doesn’t see anything, it auto opens a channel + pushes
> 100,000 sat payment.
> > > > > > 5. I now own and can spend 100,000 sats instantly.
> > > > > >
> > > > > > Considerations:
> > > > > >
> > > > > > - This auto establishing of channels and pushing payments
> isn’t for all LN nodes. Just routing nodes.
> > > > > > - Bob doesn’t need to be the one to establish the channel. He
> can push the information down the line until a node dedicated to routing is
> found. The routing node can then be the one to establish the channel with
> me.
> > > > > > - Certain specifics need to be flushed out such as the size of
> Bob’s channel. Right now I think Bob can manually set the size of the
> channels to be established on his end. Should be smaller channels at
> first. If the person gets paid again, just establish another channel
> towards the same node if there isn't enough capacity.
> > > > > > - Routing nodes who provide this service can charge a premium.
> > > > > > - Bob, as a liquidity provider, won't cheat against himself so
> I can make LN payments instantly.
> > > > > > - The beauty behind this proposal is that I can receive a
> payment instantly, I can send payments instantly, and that it hides
> everything from me as an end user.
> > > > > > - Can possibly be extended to neutrino LN wallets if they are
> public.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190815/df1e0a9d/attachment.html>

2023-06-09 12:50:17

- reply

📅 Original date posted:2018-04-30
📝 Original message:
Something like this might also be useful for several use cases related to
RBF. For example:
Alice sends Bob an RBF-activated transaction T1 with the intention of
bumping its fee if necessary. Bob wants to send these funds to Carol, but
cannot wait until T1 confirms, so he crafts a transaction T2 that spends T1
using SIGHASH_NOINPUT, and pays Carol. Carol can now make sure she receives
the money even if Alice fee-bumps T1, as long as the outputs of the
replaced transactions are compatible.
Extra care should be taken to avoid rebinding, maybe by including an extra
input in T2 that doesn't use SIGHASH_NOINPUT.
On Mon, Apr 30, 2018 at 1:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-February/012460.html
> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [4] https://blockstream.com/eltoo.pdf
> _______________________________________________
> 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/lightning-dev/attachments/20180430/4b977159/attachment.html>

2023-06-09 12:48:15

- reply

📅 Original date posted:2017-12-20
📝 Original message:
This operation is called splice in/out, or clopen transaction. There's some
information here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000696.html
Cheers,
Dario
On Wed, Dec 20, 2017 at 9:52 PM, Jim Renkel <jim.renkel at comcast.net> wrote:
> Hello, all!
>
> I'm a long-time computer networking developer, but a newbie to
> cryptocurrency, and am interested in contributing to its development.
>
> While looking at the lightning network design and code, I've come up with
> an idea the would reduce the number of blockchain transactions used by the
> LN, and the fees paid to confirm them, in a common LN use case.
>
> I did a quick search and couldn't find this idea presented previously, but
> I may have missed it. If so, or if the idea is faulty, I'm sure you guys
> will let me know. :-)
>
> And forgive me if I don't have the terminology quite right yet.
>
> The use case I am referring to is the frequent, repeated purchases by a
> customer from the same merchant over an extended period of time. I think
> this will be a common use case.
>
> For example: Alice buys a cup of coffee from Bob's Coffee Shoppe every
> day, has done so for years, will do so for years.
>
> To use the LN to pay for these purchases, Alice opens and funds an LN
> channel to Bob. This takes one blockchain transaction.
>
> As coffees are purchased every day, funds are transferred from Alice to
> Bob in the channel without any blockchain transactions.
>
> Alice cannot afford to fund the channel for an extended period of time,
> and Bob is unwilling to wait an extended period of time to be paid for the
> coffees Alice has purchased.
>
> So every week or so, Alice and Bob close the channel, Alice gets back any
> unspent funds, and Bob gets the funds that have been transferred to him for
> Alice's purchases. Then Alice and Bob re-open the channel with new funding
> from Alice. Closing and re-opening the channel each take one blockchain
> transaction.
>
> Over the life of the channel, if there are n close/re-open cycles, 2*n
> blockchain transactions are required: 1 to open the channel initially, 2
> each time the channel is closed and re-opened (n-1 times), and 1 to close
> the channel finally.
>
> If the LN were enhanced with an operation to deposit and withdraw funding
> in the channel to and from the blockchain without closing the channel, this
> could be done with a single blockchain transaction that is essentially the
> merge of the closing and re-opening blockchain transactions.
>
> In this example, each adjustment will only pay Bob his accumulated but as
> yet unpaid funds and charge Alice for the new funds she places into the
> channel, but leave Alice's unspent funds in the channel. The channel could
> continue to operate between the launching and confirmation of the
> adjustment transaction if Alice has unspent funds in the channel.
>
> Then the n cycles would only require n+1 blockchain transactions: 1 to
> initially open the channel, 1 each time the channel funding is adjusted
> (total n-1), and 1 to finally close the channel. This is a significant
> reduction in the number of blockchain transactions required, approaching
> 50% in the limit as n approaches infinity.
>
> What about blockchain transaction fees? I've done the analysis, but it's
> quite long (several conditions and dozens of combinations of conditions to
> consider), so I won't include it here now. I will included it in another
> post if anyone is interested and doesn't do the analysis for themselves.
>
> The bottom line of the analysis is that the number of inputs and the
> number of outputs in the funding adjustment transaction are each never
> greater than the sum of the number of inputs and the number of outputs,
> respectively, in the channel opening and closing transactions that the
> adjustment transaction replaces.
>
> Thus the adjustment transaction is:
> - never bigger than the closing and re-opening transactions put together,
> - sometimes smaller, and
> - occasionally significantly smaller.
>
> And there's only one transaction instead of two, so ya always save on the
> transaction header! :-)
>
> Thus, the fee paid for the adjustment transaction, assuming the same fee
> rate for all the transactions, is:
> - never more than the sum of the fees paid for the closing and re-opening
> transactions,
> - sometimes less, and
> - occasionally significantly less.
>
> This reduction in fees is by an additive amount.
>
> Because the channel remains open while waiting for the adjustment
> transaction to confirm, there may be less urgency in having it confirm. So
> it's fee rate can be reduced, reducing the fee paid by a multiplicative
> amount.
>
> Combined, these two effects lead to a reduction in total fees paid for
> operating the channel, sometimes a significant reduction.
>
> Comments expected and welcome.
>
> If this high-level, bare-bones idea to seen to be worthy of further
> consideration, I would like to work with the community to flesh out a
> detailed specification, and, if consensus can be reached on that, to
> participate in the implementation of it.
>
> Jim Renkel
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171220/14cdd7b0/attachment-0001.html>

2023-06-07 23:15:48

- reply

📅 Original date posted:2022-10-21
📝 Original message:Hello Antoine,
Thanks for taking the time to answer every email with detailed analysis! I
can
see it's a lot of work. I'll answer inline.
On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Personally, I still think deferring full-rbf deployment, while it sounds
> reasonable to let existing services and applications adapt their software
and
> business models, doesn't come risk-free for the contracting protocols and
> multi-party applications affected by the pinning DoS vector. Deferring ad
> vitam aeternam left them exposed to disruptions when their traffic volume
> would start to be significant. While those use-cases
> (splicing/dual-channels/collaborative constructions) were mostly
vaporware a
> year ago when I raised the issue, it turns out they have become a far more
> tangible reality today. Beyond the 3 coinjoins services
> (Wasabi/Joinmarket/Whirlpool), we have new things like ln-vortex, or
Phoenix
> wallet and some LDK users planning to use dual-funded soon.
To solve the attack you described in [0], collaborative transaction
protocols
(such as dual-funded channels) need a *reliable* way to replace
transactions.
Otherwise, protocol parties using full-RBF may see replacements succeed in
their
own mempool, only to find out they weren't relayed to a miner once it's too
late
(ie. once the replacement that won is mined).
I'm calling a full-RBF deployment reliable to the point at which any
full-RBF-enabled node can broadcast a replacement and get it relayed all
the way
to a miner in a reliable manner (ie. with high-enough probability).
Even if we deployed opt-out (or mandatory!) full-RBF now and miners adopted
it
immediately, it would take almost a year (assuming normal deployment times)
for
it to be sufficiently deployed in the relaying layer to be considered
reliable.
An opt-in full-RBF deployment, as currently proposed (ie. without #25600),
has
very little chance of getting us nowhere near that kind of adoption.
Notice that #26323 (option 5 in the OP) has the advantage of getting us to a
reliable full-RBF network the fastest (in particular, much faster than the
current opt-in deployment) while not threatening zero-conf applications
until
the activation time. That is, #26323 gives us a way in which we don't need
to
choose between the security of one use case versus the other. We can have
both.
> I'm still looking forward to having more forums and communication channels
> between business/services operators and protocol developers, it sounds
like
> functional responsibilities between protocol and application layers could
be
> better clarified. However, I don't know if it should be the
responsibility of
> developers to solve every operational risk encumbered by a Bitcoin
business,
> like FX risk. I don't deny the interdependency between network policy
rules
> and business risk, I'm just saying Bitcoin protocol developers have
already
> heavily loaded engineering priorities between solving the half of dozen of
> Lightning vulnerabilities, working on the next consensus changes or
reviewing
> modularity refactoring of Bitcoin Core to extend the feature set in a
soft way
> (among tons of other examples).
I don't think asking for a predictable deployment timeline for a change that
would put some applications at increased risk could be described as
burdening
the developers with solving every operational risk. This deployment method
comparison's goal was precisely to soften the burden on core devs.
Cheers,
Dario
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221021/09da7c46/attachment-0001.html>

2023-06-07 23:15:46

- reply

📅 Original date posted:2022-10-20
📝 Original message:Hello list,
Given that the release of 24.0 is upon us and there is little time to make a
complex decision regarding the deployment method of full-RBF, we've
documented
the different alternatives and their trade-offs. I hope this helps get to
the
best possible deployment!
Gist: https://gist.github.com/esneider/4eb16fcd959cb8c6b657c314442801ee
# Current deployment options
1. Antoine's PR #26305: leave 24.0 as is, and merge opt-out in 25.0 or
later.
2. Marco's PR #26287: revert opt-in full-RBF in 24.0, and give more time to
figure out what's next.
3. Marco's PR #26287 + Antoine's PR #26305: revert opt-in full-RBF in 24.0,
and
merge opt-out in 25.0 or later.
4. Marco's PR #26287 + Anthony's PR #26323 (just the date commitment):
revert
opt-in full-RBF in 24.0, and commit in 25.0 or later to a later date for
opt-out activation.
5. Anthony's PR #26323: revert opt-in full-RBF in 24.0, and commit in 24.0
to a
later date for opt-out activation.
Notice that once full-RBF is fully deployed, having a config option to
disable
it is mostly a foot gun: you will only hurt yourself by missing some
transactions. Maybe options 4 and 5 could remove the flag altogether
instead of
making it opt-out.
There are a few more options, but I don't think they would reasonably have
any
consensus, so I trimmed them down to make it easier to process.
# Dimensions of analysis
1. Zero-conf apps immediately affected
If we leave the flag for full-rbf in 24.0, zero-conf apps could be
immediately affected. More specifically, as Anthony explained much more
clearly [0], they would be in danger as soon as a relatively big mining
pool operator enables the full-RBF flag.
It turns out that the class of apps that could be immediately affected
(ie.
apps that were directly or indirectly relying on the first-seen policy
in an
adversarial setting) is larger than zero-conf apps, as exposed by Sergej
[1]. Namely, the apps committing to an exchange rate before on-chain
funds
are sent/finalized would start offering a free(ish) american call
option.
2. Predictable deployment date
Committing to an activation date for full-rbf on the social layer (eg.
"we'll merge the opt-out flag in 25.0") has the benefit of being
flexible in
the event of new data points but becomes less predictable (both for
applications and for full-rbf proponents).
Committing to an activation date for full-rbf on the code has the
benefit
that once node operators start deploying the code, the date is set in
stone,
and we can reason about when full-RBF will be fully deployed and usable.
3. Code complexity
Handling the commitment to a date in the code introduces further code
complexity. In particular, it's a deployment mechanism that, as far as I
know, hasn't been tried before, so we should be careful.
4. Smooth deployment
Full-RBF deployment has two distinct phases when analyzing the adoption
in
the transaction relaying layer. First, there will be multiple disjoint
connected components of full-RBF nodes. Eventually, we'll get to a
single(ish) connected component of full-RBF nodes.
The first deployment phase is a bit chaotic and difficult to reason
about:
nobody can rely on full-RBF actually working; if it coincides with a
high-fees scenario, we'll get a big mempool divergence event, causing
many
other issues and unreliability in the relaying and application layers.
I'm calling smooth deployment to a deployment that minimizes the first
phase, eg. by activating full-RBF simultaneously in as many
transaction-relaying nodes as possible.
5. Time to figure out the right deployment
Figuring out the right deployment method and timeline to activate
full-rbf
might be more time-consuming than what we are willing to wait for the
stable
release of 24.0. Decoupling the protection to zero-conf apps from
choosing a
deployment method and an activation date for opt-out might be a good
idea.
I'm probably forgetting some dimensions here, but it may be enough to grasp
the
trade-offs between the different approaches.
# Comparison
Gist:
https://gist.github.com/esneider/4eb16fcd959cb8c6b657c314442801ee#comparison
# Timeline for full-RBF activation
If we make some UX trade-offs, Muun can be production ready with the
required
changes in 6 months. Having more time to avoid those trade-offs would be
preferable, but we can manage.
The larger application ecosystem may need a bit more time since they might
not
have the advantage of having been working on the required changes for a
while
already. Ideally, there should be enough time to reach out to affected
applications and let them make time to understand the impact, design
solutions,
implement them, and deploy them.
Finally, if a smooth deployment (as previously defined) is desired, we can
lock
an activation date in the code and give relaying nodes enough time to
upgrade
before activation. Assuming that the adoption of future releases remains
similar
to previous ones [2], one release cycle should get us to 22% adoption, two
release cycles to 61% adoption, and three release cycles to 79% adoption.
Assuming a uniform adoption distribution, the probability of an 8-connection
relaying node not being connected to any full-RBF node after one release
cycle
will be 0.14. After two cycles, it will be 0.00054, and after three cycles,
it
will be 0.0000038. Looking at these numbers, it would seem that a single
release
cycle will be too little time, but two release cycles may be enough.
Cheers,
Dario
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021031.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html
[2] https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
[Marco's PR #26287] https://github.com/bitcoin/bitcoin/pull/26287
[Antoine's PR #26305] https://github.com/bitcoin/bitcoin/pull/26305
[Anthony's PR #26323] https://github.com/bitcoin/bitcoin/pull/26323
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/d44995aa/attachment.html>

2023-06-07 23:14:19

- reply

📅 Original date posted:2022-10-12
📝 Original message:Hello Pieter,
Thanks for taking the time to comment! I'll answer inline.
On Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille <bitcoin-dev at wuille.net>
wrote:
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network.
That is
> presumably the reason why people are in favor of having the flag, even
default
> off - including me. I believe that policy's adoption is inevitable
eventually,
> but the speed at which that is achieved is certainly a function of
> availability and adopted of software which provides the option.
As stated in the original posting, I believe too that a full-RBF network is
not
only inevitable but also desirable. Miner incentives will eventually win,
so we
should address them before they fully kick in (ie. before transaction fees
become a meaningful portion of the block reward).
> So I have a hard time imagining how it would change anything
*immediately* on
> the network at large (without things like default on and/or preferential
> peering, ...), but I still believe it's an important step.
Notice that I'm not saying this changes anything immediately on the network
at
large. In fact, it is unlikely that the opt-in flag alone would be enough to
migrate the network at large to full-RBF.
There's a real possibility that, after deployment of the opt-in flag,
either no
meaningful hashing power adopts it or no connected component of
transaction-relaying nodes adopts it. If that's the case, the deployment
won't
help nodes participating in multi-party funded transactions protect against
the
class of attacks described in [1] (which was, as I understand, the original
intention of #25353).
If that's not the case, it means that at least some meaningful hashing power
adopted it and that there exist some connected components of
transaction-relaying nodes that adopted it. This is certainly far from
having
wide adoption of full-RBF in the network at large. However, once we reach
that
minimal level of adoption in the mining and relaying layers, any node on a
full-RBF connected component can send an on-chain payment to an application
and
then get a replacement mined. That is, applications that accept incoming
on-chain payments from untrusted parties can be immediately exposed to
full-RBF
transaction replacements, even if they didn't opt into full-RBF in their
nodes.
In an adversarial setting, such as the one for zero-conf applications (as
defined in the original posting), this increases the risk of an attack
substantially, making the entire strategy moot.
> In my view, it is just what I said: a step towards getting full RBF on the
> network, by allowing experimentation and socializing the notion that
> developers believe it is time.
Those are worthy goals. I believe we can design a deployment strategy for
full-RBF that takes them into account and, at the same time, gives a clear
timeline for any affected application to adapt.
This could be one such proposal:
1. We activate opt-in full-RBF on testnet now.
2. We commit now (in the code) to a block height in the future at which
opt-out
full-RBF will activate on mainnet.
The first point will allow for experimentation and give a testing ground to
all
affected applications. The second point socializes the notion that
developers
believe it is time, giving a clear message and timeline for anyone affected
to
adapt. It also has the benefit that many more nodes will have upgraded by
the
time we reach the activation block height, making the transition to a
full-RBF
network much more predictable and easy to reason about.
There's an argument to be made that the miner incentive incompatibility
problem
of a non-full-RBF network gets measurably worse at the time of the next
halving.
To fix this, we could choose any block height before that, giving a clear
and
predictable transition timeline.
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
On Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille <bitcoin-dev at wuille.net>
wrote:
> On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <
> aj at erisian.com.au> wrote:
>
> > On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev
> wrote:
> >
> > > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via
> bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> > >
> > > > Thanks for the fast answer! It seems I missed the link to the PR,
> sorry for the
> > > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > > It is not clear to me why you believe the merging of this particular
> pull request poses an immediate risk to you.
> >
> >
> > Did you see the rest of Dario's reply, bottom-posted after the quoted
> > text? Namely:
>
> Oh, my mail client for some reason chose to hide all that. Dario, I'm
> sorry for missing this; I see now that you were certainly aware of what the
> PR under consideration did.
>
> Further comments inline.
>
> > On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
>
> > > The question then is whether an opt-in flag for full-RBF will have
> enough
> > > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > > objective of allowing nodes participating in multi-party funding
> protocols
> > > to assume that they can rely on full-RBF. If it is, then zero-conf
> applications
> > > will be at severe risk (per the logic in the initial email).
>
> >
> >
> > That logic seems reasonably sound to me:
> >
> > - if adding the option does nothing, then there's no point adding it,
> > and no harm in restricting it to test nets only
> >
> > - if adding the option does do something, then businesses using zero-conf
> > need to react immediately, or will go from approximately zero risk of
> > losing funds, to substantial risk
> >
> > (I guess having the option today may allow you to manually switch your
> > node over to supporting fullrbf in future when the majority of the
> network
> > supports it, without needing to do an additional upgrade in the meantime;
> > but that seems like a pretty weak benefit)
>
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network. That
> is presumably the reason why people are in favor of having the flag, even
> default off - including me. I believe that policy's adoption is inevitable
> eventually, but the speed at which that is achieved is certainly a function
> of availability and adopted of software which provides the option.
>
> That said, I think it's a bit of a jump to conclude that the only two
> options are that either the existence of the flag either has no effect at
> all, or poses an immediate threat to those relying on its absence. In my
> view, it is just what I said: a step towards getting full RBF on the
> network, by allowing experimentation and socializing the notion that
> developers believe it is time. So I have a hard time imagining how it would
> change anything *immediately* on the network at large (without things like
> default on and/or preferential peering, ...), but I still believe it's an
> important step.
>
> Cheers,
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221012/5280640b/attachment-0001.html>

2023-06-07 23:14:18

- reply

📅 Original date posted:2022-10-07
📝 Original message:Hello David,
Thanks for the fast answer! It seems I missed the link to the PR, sorry for
the
confusion. I'm referring to the opt-in flag for full-RBF from #25353
(https://github.com/bitcoin/bitcoin/pull/25353).
On Fri, Oct 7, 2022 at 2:21 PM David A. Harding <dave at dtrt.org> wrote:
> On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> > Hello list,
> >
> > I'm Dario, from Muun wallet [...] we've been reviewing the latest
> > bitcoin core release
> > candidate [...] we understood we had at least a year from the initial
> > opt-in deployment until opt-out was deployed, giving us enough time to
> > adapt
> > Muun to the new policies. However, when reviewing the 24.0 release
> > candidate
> > just a few days ago, we realized that zero-conf apps (like Muun) must
> > *immediately turn off* their zero-conf features.
>
> Hi Dario,
>
> I'm wondering if there's been some confusion. There are two RBF-related
> items in the current release notes draft:[1]
>
> 1. "A new mempoolfullrbf option has been added, which enables the
> mempool to accept transaction replacement without enforcing BIP125
> replaceability signaling. (#25353)"
>
> 2. "The -walletrbf startup option will now default to true. The wallet
> will now default to opt-in RBF on transactions that it creates.
> (#25610)"
>
> The first item (from PR #25353) does allow a transaction without a
> BIP125 signal to be replaced, but this configuration option is set to
> disabled by default.[2] There have been software forks of Bitcoin Core
> since at least 2015 which have allowed replacement of non-signaling
> transactions, so this option just makes that behavior a little bit more
> accessible to users of Bitcoin Core.
The "activation" of full-RBF after deployment works in a pretty interesting
way:
1. If no miner is running full-RBF or there aren't easily accessible
connected
components of nodes running full-RBF connected to the miners, then
full-RBF
is mostly ineffective since replacements aren't relayed and/or mined.
2. There's a middle ground where *some* connected components of full-RBF
nodes
can relay and mine replacements, where some full-RBF nodes will be able
to
replace via full-RBF and some won't (depending on their peers).
3. With high enough adoption, the relay graph has enough density of full-RBF
nodes that almost all full-RBF nodes can replace transactions via
full-RBF.
While there have been forks of Bitcoin Core (like Bitcoin Knots) running
full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
So,
Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
be
picked up by most node operators. Making the flag opt-out (ie. on by
default)
would make it easier still. We are dealing with a gradient going from hard
enough that we are still in 1, to easy enough that we get to 3.
The question then is whether an opt-in flag for full-RBF will have enough
adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
objective of allowing nodes participating in multi-party funding protocols
to
assume that they can rely on full-RBF. If it is, then zero-conf applications
will be at severe risk (per the logic in the initial email).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221007/a17e3454/attachment.html>

2023-06-07 23:14:16

- reply

📅 Original date posted:2022-10-07
📝 Original message:Hello list,
I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the
past
few days we've been reviewing the latest bitcoin core release candidate,
and we
found some troubling facts related to the opt-in full-RBF deployment.
We first learned about the opt-in full-RBF proposal last June when it was
announced on the mailing list. Closing the gap between the protocol's relay
policies and the miner incentives is inevitable, so it was a welcomed
addition.
Furthermore, allowing transaction replacements that remove the opt-in RBF
flag
was deeply problematic.
At the time, we understood we had at least a year from the initial opt-in
deployment until opt-out was deployed, giving us enough time to adapt Muun
to
the new policies. However, when reviewing the 24.0 release candidate just a
few
days ago, we realized that zero-conf apps (like Muun) must *immediately turn
off* their zero-conf features.
I understand this wasn't the intention when designing the opt-in deployment
mechanism. Given this new information, do you see a path where we can delay
the
opt-in deployment and find a safer way to deploy full-RBF?
It'd be great for this deployment to be a success so that we can continue
fixing
the remaining relay policy problems, such as package relay and the RBF
rules.
Maybe we could go straight to an opt-out deployment locked by code at a
certain
height in the future to give time to everyone and, at the same time, avoid a
huge mempool divergence event?
Below is our analysis of how zero-conf apps break with opt-in full-RBF. I
hope
it helps.
Cheers,
Dario
# How do zero-conf apps work
While the workings and trade-offs of zero-conf applications might be known
by
many in this list, it's useful to define precisely how they work to
understand
how they break.
We call zero-conf applications to entities that accept on-chain payments
from
*untrusted parties* and will sometimes deliver the paid-for product or
service
without waiting for the transaction to be included in a block.
Some examples of zero-conf apps:
- Muun's submarine swaps for outgoing lightning payments
- Bitrefill's on-chain payments for gift cards and phone top-ups
- Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at
least
the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
General Byte)
All of these applications are receiving incoming on-chain transactions for
which
they don't control the inputs, and performing a risk analysis to decide
whether
they are ok with accepting the payment without confirmation.
In practice, this works because once the bitcoin P2P network has fully
propagated a non-RBF transaction, you need the collaboration of a miner to
replace it, which isn't easy to get today. Even though many of the biggest
miners offer off-band transaction broadcasting services, they currently
won't
process conflicting transactions.
Roughly, the risk analysis goes like this:
1. if an incoming transaction is RBF (direct or inherited)
--> too risky, wait for 1 conf (or more) since it can be replaced at any
time
2. if the payment is for an amount greater than X
--> too risky, wait for 1 conf (or more), since the amount is worthy of a
sophisticated attacker
3. wait for full(ish) propagation of the incoming transaction
4. if there's no double-spend attempt
--> accept 0-conf
As with any other risk analysis, there's always a false-negative detection
rate,
leading to an expected loss, which the zero-conf app should be willing to
bear.
Notice that the expected loss is tunable via the amount X in the above
analysis.
# Why are zero-conf apps not protected with an opt-in deployment
Full-RBF adoption works on three different layers:
- The transaction application layer
- The transaction relaying layer
- The transaction mining layer
If an application wants to replace with full-RBF an *outgoing* transaction,
it
will need:
- An upgraded node that opted into full-RBF, from which it can broadcast the
replacement transaction
- A connected component of upgraded nodes that opted into full-RBF, that can
relay the replacement transaction
- A miner in that connected component with an upgraded node that opted into
full-RBF, that can mine the replacement transaction
However, an application cannot control whether a replacement to an
*incoming*
transaction is relayed via full-RBF. As soon as a single application can
generate replacements easily via full-RBF, all other applications have to
assume
that any incoming transaction from an untrusted party might be replaced via
full-RBF. That is, for the application layer this is a forced upgrade.
As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
analysis performed by zero-conf applications stops working because the
transactions to analyze are all incoming transactions from untrusted
parties.
Since some wallets already implement cancel functionality for opt-in RBF
transactions, enabling the same functionality for every transaction wouldn't
require much work, making canceling any unconfirmed transaction a one-click
experience. After this, the security model of zero-conf applications goes
from
"susceptible to attacks from miners" to "anyone can perform an attack, with
an
easy-to-use interface".
That is, the opt-in deployment of full-RBF doesn't protect zero-conf
applications from having to turn off their zero-conf features very soon
after
the initial deployment. All mitigations are mostly ineffective against
untrusted parties.
# Other things we have to fix
While it's clear how full-RBF breaks zero-conf applications, other more
subtle
things break in *many* wallets (Muun included). If given the opportunity, we
would like to fix them before deployment. One could argue that these things
were already broken, but they get considerably worse as the network adopts
full-RBF (even with an opt-in deployment), so we should fix them.
## Mental model for unconfirmed incoming transactions
Many wallets with support for on-chain payments (Muun included) show
incoming
external transactions in some way to their users before they confirm. This
is a
common practice because not showing them leads users to worry that their
money
disappeared (exchanges doing this is the #1 issue we have to deal with in
our
customer support channels).
With full-RBF, wallets should make it extremely clear to users that
unconfirmed
funds are not theirs (yet). Otherwise, protocol-unaware users that are
transacting on-chain with untrusted parties can be easily scammed if they
don't
know they have to wait for a confirmation. Eg. in Argentina, it's pretty
common
to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
## Block explorers as payment receipts
Most wallets with support for on-chain payments (Muun included) use the
transaction view of a block explorer as a shareable payment receipt. The
sender
of an on-chain transaction usually shares this link with the receiver to let
them know they made a payment. Protocol-unaware receivers sometimes take
this
link as proof of payment.
Most explorers currently don't track payment replacements and, more
importantly,
don't warn users that unconfirmed funds are not theirs (yet). With full-RBF,
wallets should either stop relying on explorers for this functionality or
wait
for them to support it explicitly.
# Impact at Muun
Work to transition Muun from using zero-conf submarine swaps to using
payment
channels is ongoing, but we are still several months away from being
production
ready. This means we would have to turn off outgoing lightning payments for
+100k monthly active users, which is a good chunk of all users making
non-custodial lightning payments today.
Furthermore, the more subtle fixes imply non-trivial amounts of product work
that we cannot reasonably deploy before they start affecting users.
While I cannot talk for other applications, there are many impacted in one
way
or another, and none of the ones I checked with were aware of this change,
or
its implications.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221007/d8b61478/attachment.html>

2023-06-07 18:11:43

- reply

📅 Original date posted:2018-04-30
📝 Original message:Something like this might also be useful for several use cases related to
RBF. For example:
Alice sends Bob an RBF-activated transaction T1 with the intention of
bumping its fee if necessary. Bob wants to send these funds to Carol, but
cannot wait until T1 confirms, so he crafts a transaction T2 that spends T1
using SIGHASH_NOINPUT, and pays Carol. Carol can now make sure she receives
the money even if Alice fee-bumps T1, as long as the outputs of the
replaced transactions are compatible.
Extra care should be taken to avoid rebinding, maybe by including an extra
input in T2 that doesn't use SIGHASH_NOINPUT.
On Mon, Apr 30, 2018 at 1:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-February/012460.html
> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [4] https://blockstream.com/eltoo.pdf
> _______________________________________________
> 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/20180430/4b977159/attachment.html>

2023-06-07 15:39:18

- reply

📅 Original date posted:2015-06-20
📝 Original message:se, lo re putearon a Peter Todd en reddit por esto
On Jun 19, 2015 7:42 AM, "Peter Todd" <pete at petertodd.org> wrote:
> Yesterday F2Pool, currently the largest pool with 21% of the hashing
> power, enabled full replace-by-fee (RBF) support after discussions with
> me. This means that transactions that F2Pool has will be replaced if a
> conflicting transaction pays a higher fee. There are no requirements for
> the replacement transaction to pay addresses that were paid by the
> previous transaction.
>
>
> I'm a user. What does this mean for me?
> ---------------------------------------
>
> In the short term, very little. Wallet software aimed at average users
> has no ability to reliably detect conditions where an unconfirmed
> transaction may be double-spent by the sender. For example, Schildbach's
> Bitcoin Wallet for Android doesn't even detect double-spends of
> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
> that propagate them. The least sophisticated double-spend attack
> possibly - simply broadcasting two conflicting transactions at the same
> time - has about 50% probability of success against these wallets.
>
> Additionally, SPV wallets based on bitcoinj can't even detect invalid
> transactions reliably, instead trusting the full node(s) it is connected
> too over the unauthenticated, unencrypted, P2P protocol to do validation
> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
> double-spends that spend the output of the conflicting transaction. I've
> personally tested this with Schildbach's Bitcoin Wallet for Android,
> which shows such invalid transactions as standard, unconfirmed,
> transactions.
>
> Users should continue to assume that unconfirmed transactions could be
> trivially reversed by the sender until the first confirmation. In
> general, only the sender can reverse a transaction, so if you do trust
> the sender feel free to assume an unconfirmed transaction will
> eventually confirm. However, if you do not trust the sender and/or have
> no other recourse if they double-spend you, wait until at least the
> first confirmation before assuming the transaction will go through.
>
> In the long term, miner support of full RBF has a number of advantages
> to users, allowing you to more efficiently make transactions, paying
> lower fees. However you'll need a wallet supporting these features; none
> exist yet.
>
>
> I'm a business. What does this mean for me?
> -------------------------------------------
>
> If you use your own node to verify transactions, you probably are in a
> similar situation as average users, so again, this means very little to
> you.
>
> If you use a payment processor/transaction API such as BitPay, Coinbase,
> BlockCypher, etc. you may or may not be accepting unconfirmed
> transactions, and they may or may not be "guaranteed" by your payment
> processor even if double-spent. If like most merchants you're using the
> API such that confirmations are required prior to accepting orders (e.g.
> taking a meaningful loss such as shipping a product if the tx is
> reversed) nothing changes for you. If not I recommend you contact your
> payment processor.
>
>
> I'm a miner. Why should I support replace-by-fee?
> -------------------------------------------------
>
> Whether full or first-seen-safe⁵ RBF support (along with
> child-pays-for-parent) is an important step towards a fully functioning
> transaction fee market that doesn't lead to users' transactions getting
> mysteriously "stuck", particularly during network flooding
> events/attacks. A better functioning fee market will help reduce
> pressure to increase the blocksize, particularly from the users creating
> the most valuable transactions.
>
> Full RBF also helps make use of the limited blockchain space more
> efficiently, with up to 90%+ transaction size savings possible in some
> transaction patterns. (e.g. long payment chains⁶) More users in less
> blockchain space will lead to higher overall fees per block.
>
> Finally as we'll discuss below full RBF prevents a number of serious
> threats to the existing level playing field that miners operate in.
>
>
> Why can't we make accepting unconfirmed txs from untrusted people safe?
> -----------------------------------------------------------------------
>
> For a decentralized wallet, the situation is pretty bleak. These wallets
> only have a handful of connections to the network, with no way of
> knowing if those connections give an accurate view of what transactions
> miners actually know about.
>
> The only serious attempt to fix this problem for decentralized wallets
> that has been actually deployed is Andresen/Harding's double-spend
> relaying, implemented in Bitcoin XT. It relays up to one double-spend
> transaction per double-spent txout, with the intended effect to warn
> recipients. In practice however this functionality makes it easier to
> double-spend rather than harder, by giving an efficient and easy way to
> get double-spends to miners after the fact. Notably my RBF
> implementation even connects to Bitcoin XT nodes, reserving a % of all
> incoming and outgoing connection slots for them.
>
> Additionally Bitcoin XT's double-spend relaying is subject to attacks
> include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
> interactive attacks⁷ among many others.
>
>
> What about centralised wallets?
> -------------------------------
>
> Here the solutions being deployed, planned, and proposed are harmful,
> and even represent serious threats to Bitcoin's decentralization.
>
>
> Confidence factors
> ------------------
>
> Many services such as BlockCypher² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ even in the event of a double-spend. The
> key component of these predictions is to sybil attack the P2P network as
> a whole, connecting to as many nodes as possible to measure transaction
> propagation. Additionally these services connect to pools directly via
> the getblocktemplate protocol, repeatedly downloading via GBT the lists
> of transactions in the to-be-mined blocks to determine what transactions
> miners are attempting to mine.
>
> None of these measures scale, wasting significant network and miner
> resources; in one instance a sybil attack by Chainalysis even completely
> blocked the users of the SPV wallet Breadwallet⁴ from accessing the
> network. These measures also don't work very well, giving double-spend
> attackers incentives to sybil attack miners themselves.
>
>
> Transaction processing contracts with miners
> --------------------------------------------
>
> The next step after measuring propagation fails is to contract with
> miners directly, signing contracts with as much of the hashing power as
> possible to get the transactions they want mined and double-spends
> rejected. The miners/pools would then provide an authenticated API
> endpoint for exclusive use of this service that would allow the service
> to add and remove specific transactions to the mempool on demand.
>
> There's a number of serious problems with this:
>
> 1) Mining contracts can be used to double-spend
>
> ...even when they're being used "honestly".
>
> Suppose Alice is a merchant using CoinPayCypher, who has contracts with
> 75% of the hashing power. Bob, another merchant, meanwhile uses a
> decentralized Bitcoin Core backend for payments to his website.
>
> Mallory wants to double-spend Bob's to buy his expensive products. He
> can do this by creating a transaction, tx1, that pays Alice, followed by
> a second transaction, tx2, that pays Bob. In any circumstance when
> Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
> the chance of Malory's double-spend succeeding becomes ~75% because
> CoinPayCypher's contracts with mining ensure the transaction paying
> Alice will get mined.
>
> Of course, dishonest use and/or compromise makes double-spending
> trivial: Malory can use the API credentials to ask miners to reject
> Bob's payment at any time.
>
>
> 2) They still don't work, without 51% attacking other miners
>
> Even if CoinPayCypher has 75% of the hashing power on contract, that's
> still a potentially 75% chance of being double-spent. The 25% of miners
> who haven't signed contracts have no _decentralized_ way of ensuring
> they don't create blocks with double-spends, let alone at low cost. If
> those miners won't or can't sign contracts with CoinPayCypher the only
> next step available is to reject their blocks entirely.
>
>
> 3) Legal contracts give the advantage to non-anonymous miners in
> Western jurisdictions
>
> Suppose CoinPayCypher is a US company, and you're a miner with 1%
> hashing power located in northern China. The barriers to you succesfully
> negotiating a contract with CoinPayCypher are significant. You don't
> speak the same langauge, you're in a completely different jurisdiction
> so enforcing the legal contract is difficult, and being just 1%,
> CoinPayCypher sees you as insignificant.
>
> Who's going to get the profitable hashing power contracts first, if at
> all? Your English speaking competitors in the west. This is inherently a
> pressure towards centralization of mining.
>
>
> Why isn't this being announced on the bitcoin-security list first?
> ------------------------------------------------------------------
>
> I've had repeated discussions with services vulnerable to double-spends;
> they have been made well aware of the risk they're taking. If they've
> followed my own and others' advice they'll at minimum have constant
> monitoring of the rate of double-spends both on their own services and
> on the P2P network in general.
>
> If you choose to take a risk you should accept the consequences.
>
>
> How do I actually use full RBF?
> -------------------------------
>
> First get the full-RBF patch to v0.10.2:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
>
> The above implementation of RBF includes additional code to find and
> preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
> Secondly, try out my replace-by-fee-tools at:
>
> https://github.com/petertodd/replace-by-fee-tools
>
> You can watch double-spends on the network here:
>
> http://respends.thinlink.com/
>
>
> References
> ----------
>
> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
> variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet",
> Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html
>
> 2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
> June 2nd, 2014, Erik Voorhees,
>
> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
>
> 3) Coinbase Merchant API, Accessed Jun 19th 2015,
> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>
> 4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
> March 14th 2015, Grace Caffyn, Coindesk,
>
> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
>
> 5) "First-Seen-Safe Replace-by-Fee",
> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
>
> 6) "Cost savings by using replace-by-fee, 30-90%",
> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>
> 7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
> Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan
> Capkun,
> Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
> http://eprint.iacr.org/2015/578
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/2c858ddf/attachment.html>

2023-06-07 15:39:18

- reply

📅 Original date posted:2015-06-20
📝 Original message:Sorry about that, ignore me
On Jun 20, 2015 11:11 PM, "Dario Sneidermanis" <dariosn at gmail.com> wrote:
> se, lo re putearon a Peter Todd en reddit por esto
> On Jun 19, 2015 7:42 AM, "Peter Todd" <pete at petertodd.org> wrote:
>
>> Yesterday F2Pool, currently the largest pool with 21% of the hashing
>> power, enabled full replace-by-fee (RBF) support after discussions with
>> me. This means that transactions that F2Pool has will be replaced if a
>> conflicting transaction pays a higher fee. There are no requirements for
>> the replacement transaction to pay addresses that were paid by the
>> previous transaction.
>>
>>
>> I'm a user. What does this mean for me?
>> ---------------------------------------
>>
>> In the short term, very little. Wallet software aimed at average users
>> has no ability to reliably detect conditions where an unconfirmed
>> transaction may be double-spent by the sender. For example, Schildbach's
>> Bitcoin Wallet for Android doesn't even detect double-spends of
>> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
>> that propagate them. The least sophisticated double-spend attack
>> possibly - simply broadcasting two conflicting transactions at the same
>> time - has about 50% probability of success against these wallets.
>>
>> Additionally, SPV wallets based on bitcoinj can't even detect invalid
>> transactions reliably, instead trusting the full node(s) it is connected
>> too over the unauthenticated, unencrypted, P2P protocol to do validation
>> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
>> double-spends that spend the output of the conflicting transaction. I've
>> personally tested this with Schildbach's Bitcoin Wallet for Android,
>> which shows such invalid transactions as standard, unconfirmed,
>> transactions.
>>
>> Users should continue to assume that unconfirmed transactions could be
>> trivially reversed by the sender until the first confirmation. In
>> general, only the sender can reverse a transaction, so if you do trust
>> the sender feel free to assume an unconfirmed transaction will
>> eventually confirm. However, if you do not trust the sender and/or have
>> no other recourse if they double-spend you, wait until at least the
>> first confirmation before assuming the transaction will go through.
>>
>> In the long term, miner support of full RBF has a number of advantages
>> to users, allowing you to more efficiently make transactions, paying
>> lower fees. However you'll need a wallet supporting these features; none
>> exist yet.
>>
>>
>> I'm a business. What does this mean for me?
>> -------------------------------------------
>>
>> If you use your own node to verify transactions, you probably are in a
>> similar situation as average users, so again, this means very little to
>> you.
>>
>> If you use a payment processor/transaction API such as BitPay, Coinbase,
>> BlockCypher, etc. you may or may not be accepting unconfirmed
>> transactions, and they may or may not be "guaranteed" by your payment
>> processor even if double-spent. If like most merchants you're using the
>> API such that confirmations are required prior to accepting orders (e.g.
>> taking a meaningful loss such as shipping a product if the tx is
>> reversed) nothing changes for you. If not I recommend you contact your
>> payment processor.
>>
>>
>> I'm a miner. Why should I support replace-by-fee?
>> -------------------------------------------------
>>
>> Whether full or first-seen-safe⁵ RBF support (along with
>> child-pays-for-parent) is an important step towards a fully functioning
>> transaction fee market that doesn't lead to users' transactions getting
>> mysteriously "stuck", particularly during network flooding
>> events/attacks. A better functioning fee market will help reduce
>> pressure to increase the blocksize, particularly from the users creating
>> the most valuable transactions.
>>
>> Full RBF also helps make use of the limited blockchain space more
>> efficiently, with up to 90%+ transaction size savings possible in some
>> transaction patterns. (e.g. long payment chains⁶) More users in less
>> blockchain space will lead to higher overall fees per block.
>>
>> Finally as we'll discuss below full RBF prevents a number of serious
>> threats to the existing level playing field that miners operate in.
>>
>>
>> Why can't we make accepting unconfirmed txs from untrusted people safe?
>> -----------------------------------------------------------------------
>>
>> For a decentralized wallet, the situation is pretty bleak. These wallets
>> only have a handful of connections to the network, with no way of
>> knowing if those connections give an accurate view of what transactions
>> miners actually know about.
>>
>> The only serious attempt to fix this problem for decentralized wallets
>> that has been actually deployed is Andresen/Harding's double-spend
>> relaying, implemented in Bitcoin XT. It relays up to one double-spend
>> transaction per double-spent txout, with the intended effect to warn
>> recipients. In practice however this functionality makes it easier to
>> double-spend rather than harder, by giving an efficient and easy way to
>> get double-spends to miners after the fact. Notably my RBF
>> implementation even connects to Bitcoin XT nodes, reserving a % of all
>> incoming and outgoing connection slots for them.
>>
>> Additionally Bitcoin XT's double-spend relaying is subject to attacks
>> include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
>> interactive attacks⁷ among many others.
>>
>>
>> What about centralised wallets?
>> -------------------------------
>>
>> Here the solutions being deployed, planned, and proposed are harmful,
>> and even represent serious threats to Bitcoin's decentralization.
>>
>>
>> Confidence factors
>> ------------------
>>
>> Many services such as BlockCypher² have attempted to predict the
>> probability that unconfirmed transactions will be mined, often
>> guaranteeing merchants payment³ even in the event of a double-spend. The
>> key component of these predictions is to sybil attack the P2P network as
>> a whole, connecting to as many nodes as possible to measure transaction
>> propagation. Additionally these services connect to pools directly via
>> the getblocktemplate protocol, repeatedly downloading via GBT the lists
>> of transactions in the to-be-mined blocks to determine what transactions
>> miners are attempting to mine.
>>
>> None of these measures scale, wasting significant network and miner
>> resources; in one instance a sybil attack by Chainalysis even completely
>> blocked the users of the SPV wallet Breadwallet⁴ from accessing the
>> network. These measures also don't work very well, giving double-spend
>> attackers incentives to sybil attack miners themselves.
>>
>>
>> Transaction processing contracts with miners
>> --------------------------------------------
>>
>> The next step after measuring propagation fails is to contract with
>> miners directly, signing contracts with as much of the hashing power as
>> possible to get the transactions they want mined and double-spends
>> rejected. The miners/pools would then provide an authenticated API
>> endpoint for exclusive use of this service that would allow the service
>> to add and remove specific transactions to the mempool on demand.
>>
>> There's a number of serious problems with this:
>>
>> 1) Mining contracts can be used to double-spend
>>
>> ...even when they're being used "honestly".
>>
>> Suppose Alice is a merchant using CoinPayCypher, who has contracts with
>> 75% of the hashing power. Bob, another merchant, meanwhile uses a
>> decentralized Bitcoin Core backend for payments to his website.
>>
>> Mallory wants to double-spend Bob's to buy his expensive products. He
>> can do this by creating a transaction, tx1, that pays Alice, followed by
>> a second transaction, tx2, that pays Bob. In any circumstance when
>> Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
>> the chance of Malory's double-spend succeeding becomes ~75% because
>> CoinPayCypher's contracts with mining ensure the transaction paying
>> Alice will get mined.
>>
>> Of course, dishonest use and/or compromise makes double-spending
>> trivial: Malory can use the API credentials to ask miners to reject
>> Bob's payment at any time.
>>
>>
>> 2) They still don't work, without 51% attacking other miners
>>
>> Even if CoinPayCypher has 75% of the hashing power on contract, that's
>> still a potentially 75% chance of being double-spent. The 25% of miners
>> who haven't signed contracts have no _decentralized_ way of ensuring
>> they don't create blocks with double-spends, let alone at low cost. If
>> those miners won't or can't sign contracts with CoinPayCypher the only
>> next step available is to reject their blocks entirely.
>>
>>
>> 3) Legal contracts give the advantage to non-anonymous miners in
>> Western jurisdictions
>>
>> Suppose CoinPayCypher is a US company, and you're a miner with 1%
>> hashing power located in northern China. The barriers to you succesfully
>> negotiating a contract with CoinPayCypher are significant. You don't
>> speak the same langauge, you're in a completely different jurisdiction
>> so enforcing the legal contract is difficult, and being just 1%,
>> CoinPayCypher sees you as insignificant.
>>
>> Who's going to get the profitable hashing power contracts first, if at
>> all? Your English speaking competitors in the west. This is inherently a
>> pressure towards centralization of mining.
>>
>>
>> Why isn't this being announced on the bitcoin-security list first?
>> ------------------------------------------------------------------
>>
>> I've had repeated discussions with services vulnerable to double-spends;
>> they have been made well aware of the risk they're taking. If they've
>> followed my own and others' advice they'll at minimum have constant
>> monitoring of the rate of double-spends both on their own services and
>> on the P2P network in general.
>>
>> If you choose to take a risk you should accept the consequences.
>>
>>
>> How do I actually use full RBF?
>> -------------------------------
>>
>> First get the full-RBF patch to v0.10.2:
>>
>> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
>>
>> The above implementation of RBF includes additional code to find and
>> preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
>> Secondly, try out my replace-by-fee-tools at:
>>
>> https://github.com/petertodd/replace-by-fee-tools
>>
>> You can watch double-spends on the network here:
>>
>> http://respends.thinlink.com/
>>
>>
>> References
>> ----------
>>
>> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
>> variants of existing attacks w/ Bitcoin XT and Android Bitcoin
>> Wallet",
>> Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
>>
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html
>>
>> 2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
>> June 2nd, 2014, Erik Voorhees,
>>
>> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
>>
>> 3) Coinbase Merchant API, Accessed Jun 19th 2015,
>> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>>
>> 4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
>> March 14th 2015, Grace Caffyn, Coindesk,
>>
>> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
>>
>> 5) "First-Seen-Safe Replace-by-Fee",
>> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>>
>> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
>>
>> 6) "Cost savings by using replace-by-fee, 30-90%",
>> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>>
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>>
>> 7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
>> Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan
>> Capkun,
>> Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
>> http://eprint.iacr.org/2015/578
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/74d91624/attachment.html>