Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Good morning Antoine, > > Since the issue here is that eclipsing of Bitcoin nodes is risky, it > > strikes me that a mitigation would be to run your Bitcoin fullnode on > > clearnet while running your Lightning node over Tor > > We clearly mention that risk of running a Bitcoin node over Tor, where do we > recommend running a LN node over Tor ? Nowhere, *I* am the one recommending this. Running both Bitcoin and Lightning nodes on clearnet automatically links them, making them easier to attack, whereas running Lightning on Tor does not. Of course, they could still be linked by onchain transaction monitoring, but at least this increases the effort to attack, hopefully it becomes marginally less desirable to attack you. On the other hand, you *could* run them on different public IP addresses, if you happen to have more than one; for those who do not even have a single public IP address there is no real choice if you want to let others to connect to you, Tor hidden service is the only Lightning-supported way to be accessible without a public IP. (There are sections of the world where commodity "home" internet connections do not automatically get a public IP, and the privilege of getting one may be an additional cost; though of course if you have no real intent to help support either the Bitcoin or Lightning networks, you do not need a public IP anyway, and with IPv6 it becomes less and less likely that a randomly-chosen entity would be unlucky enough to not get a public IP.) > > The victim *could* instead check that the absolute timelocks seem very far > > in the future relative to its own view of the current blockheight. > I think you're right it's really dependent on CLTV_delta deployed on the path > and time-dilation offset. The alternative you're proposing is a good one, but > you shouldn't know where you're in the path and max CLTV is 2048 blocks IIRC. Seeing an incoming payment that violates the max CLTV is a good indication you have been eclipsed. On the other hand, if your Bitcoin node is eclipsed, then it seems likely your Lightning node is also eclipsed (if running over the same hardware) and you might not receive any indication over Lightning that you have been eclipsed anyway. I suppose we need to identify just exactly *what* ways a node of either type can be eclipsed; it seems that mitigations that protect against one kind of eclipse will not work in general with other kinds of eclipse. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
Hi ZmnSCPxj,
> (Of note as well, is that the onchain contract provided by such services
is the same in spirit as those instantiated in channels of the Lightning
Network, thus the same attack schema works on the onchain side.)
If you onchain contract uses a timelock and has concurrent transactions
arbiter by this one , it's subject to time-dilation attack. So yes
submarine swaps, or any kind of atomic swap is concerned. We note this in
discussion.
But you're right for the attack cost, you don't need a channel to these
services, which is also concerning for their attack surface.
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
strikes me that a mitigation would be to run your Bitcoin fullnode on
clearnet while running your Lightning node over Tor
We clearly mention that risk of running a Bitcoin node over Tor, where do
we recommend running a LN node over Tor ?
> And this seems to tie with what you propose: that the LN node should
use a different view-fullnode from the broadcast-fullnode.
Yes in Countermeasures - Link layer diversity, specially if it's easy for
an attacker to provoke a transaction broadcast by buying a channel to the
LN node.
> A mitigation to this would be to run a background process which sleeps
for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
Yeah instead of having every node operator running their own hacky scripts,
without them being bulletproofs on detection, I'm working on getting such
mitigations directly in Core, easily deployable for everyone.
> The victim *could* instead check that the absolute timelocks seem very
far in the future relative to its own view of the current blockheight.
I think you're right it's really dependent on CLTV_delta deployed on the
path and time-dilation offset. The alternative you're proposing is a good
one, but you shouldn't know where you're in the path and max CLTV is 2048
blocks IIRC.
Thanks for your reading and review,
Cheers,
Antoine
Le mer. 3 juin 2020 à 22:58, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :
> Good morning Gleb and Antoine,
>
> This is good research, thank you for your work.
>
> > **Targeting Per-Hop Packet Delay** is based on routing via the victim,
> and the victim should have at least two channels with the attacker.
>
> The existence of offchain-to-onchain swap services means that the attacker
> needs only build one channel to the victim for this attack to work.
> Rather than route to themselves, the attacker routes to a convenient
> service providing such a swap service, and receives the stolen funds
> onchain, with no need even for an incoming channel from a different node.
> (Of note as well, is that the onchain contract provided by such services
> is the same in spirit as those instantiated in channels of the Lightning
> Network, thus the same attack schema works on the onchain side.)
>
> Indeed, the attack can be mounted on such a service directly.
>
> Even without such a service, the incoming channel need not be directly
> connected to the victim.
>
>
> > [Tor is tricky](https://arxiv.org/abs/1410.6079) too
>
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
> strikes me that a mitigation would be to run your Bitcoin fullnode on
> clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on)
> "only" loses you the ability to pay, receive, or route (and thereby earn
> forwarding fees), but as long as your blockchain view is clear, it should
> be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin
> node when transactions are broadcast with the attached Bitcoin node (as
> noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some
> random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a
> different view-fullnode from the broadcast-fullnode.
>
>
> > if a node doesn’t observe a block within the last 30 minutes, it
> attempts to make a new random connection to someone in the network.
>
> A mitigation to this would be to run a background process which sleeps for
> 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
> It might want to `disconnectnode` any previous node it attempted to
> connect to.
>
> However I note that the help for `addnode` contains the text "though such
> peers will not be synced from", which confuses me, since it also refers to
> the `-connect` command line option, and `-connect` means you only connect
> out to the specific nodes, so if those are not synced from huh?
>
> And of course the interesting part is "how do we get a `${BITCOINNODE}`
> that we think is not part of the eclipsing attacker?"
>
>
> > If a Lightning node is behind in its Bitcoin blockchain view, but
> Lightning payments between honest nodes are still flowing through it, this
> node will
Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Hi Joachim,
Fantastic questions!
I think it makes sense to think about it in terms of today, and then in
terms of a long-dated future where wallets have much richer native
understandings of these things. This helps preserve the purity of the
arguments I'm making with respect to what it would look like today v.s.
what it could look like with strong integration.
Today:
1) I would expect that exchanges do this as a CTV txn that is one initial
confirmation to a single output, and then that output expands to either all
the payments in the batch, or to a histogram of single-layer CTVs based on
priority/amount being spent. E.g, either A -> B -> {C,D,E,F,G...} or
A->B->{C -> {D,E,F}, G -> {H, I J}, K -> }. I would further expect that
the entire tree would include fees such that it will get into at least the
bottom of the mempool. See https://utxos.org/analysis/batching_sim/ for
more info. If txns land in the mempool, then users learn about it (even
with an un-updated wallet) just like the learn of normal unconfirmed
transactions. Even this simple two-step transaction can deliver massive
batching savings. OpTech has some coverage of this simple
commit-now-distribute-later scheme here
https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-new-opcode-for-transaction-output-commitments
.
I'd also expect that exchanges in particular already store their outbound
transactions in resilient storage (for audit and compliance as well as
liability protection), so they would likely be able to make this data
available to their customers on inquiry if discarded.
I'm all for redundancy, so exchanges can also e.g. send an email with a
backup file if they want to. But that's not necessary for it to work today,
you can just watch the mempool like wallets already do.
A slightly patched wallet can treat CTV outs as more confirmed (e.g., like
an own-change address) than a normal unconfirmed out.
2) I would expect that exchanges pay a reasonable amount of fees for the
transaction so it can expect to at least get to the bottom range of the
mempool for children, and top of the mempool for the parent. Your question
seems to be more about after this phase.
First I would note that it is truly O(log(N)), but E[O(1)], because it
amortizes. That is, to claim out all of the outputs is a total overhead of
O(N), not O(N log N). Fees in this model are paid by CPFP. Because CPFP is
currently *Child* pays for parent and not *Children* pay for parent, we
don't (unfortunately) have rational txn selection for this case. Any wallet
can construct this spend path by rebroadcasting (if evicted) the parents
and spending the txn. The exchange can also 'bound' themselves to seeing a
transaction to completion by including some change address at the leaf node
layer (not much overhead depending on radix).
Thus the payer of fees is the person who needs to spend.
3) Not exactly, the middle txns are immutable. but it may be possible to
construct a low-fee longchain which can cause transaction pinning. If you
do a shallow tree as described in (1), the current lightning carve should
help to prevent this.
Future:
1) Most likely the desirable radix for a tree is something like 4 or 5
which minimizes the amount of work on an individual basis (you can compute
this by figuring out how deep the tree would be and the per-tx overheads, 4
or 5 pop out as being minimal overhead and the benefit is recursive).
Mempool broadcast still should work, but it's possible that for privacy
reasons it's preferred to not broadcast through mempool. It's also possible
that all payouts are into non-interactive lightning channels with N-of-N
taproot at each layer, so you receive a proof through your lightning wallet
and can immediately route payments, and when you want to close
opportunistically cooperate to reduce chain overhead. You can think of CTV
as an anchor for bootstrapping these layer two protocols with an on-chain
bisection algorithm to discover online participants to re-negotiate with. A
privacy and scalability win!
I further expect business wallets (like exchanges) to be able to credit
deposits from CTV trees without requiring full expansion. This is also a
privacy win, and can decrease latency of moving large value funds (e.g.,
exceeding inter exchange channel balances) and crediting funds for trading.
2) I think we'll eventually converge on a non-destructive way of adding
fees. RBF is destructive in that you're replacing a TX. CPFP is destructive
in that you have a spend a coin to drive progress. Without a new opcode you
can emulate this with CTV by at nodes in the tree having a consumable
output that serves as a CPFP hook/a RBF hook. You can see some discussion
here (animated, so use pres mode)
https://docs.google.com/presentation/d/1XDiZOz52XyJc4LDSbiD9_JAaJobyF5QDGtR3O9qD7yg/edit#slide=id.g7d267915e2_0_44.
This adds some extra chain weight, but is possible without further
extension. What I think we'll eventually land on is a way of doing a tx
that
Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Hello everyone, regarding OP_CTV, I am considering the scaling use case, specifically an exchange (or similar) who wants to batch pay to OP_CTV to many users, and I wonder 1) How do you expect the exchange to communicate the proof of the payment to the user wallets such that they are able to construct the follow up transactions and accept the payment. This is UI question. Do you expect exchanges to provide a certain importable file/blob that the wallet will allow you to entry? 2) Who pays the fees and how for the transaction within the structure that OP_CTVed output is committed to? Say there is a tree structure and I want to get the coin out. Someone needs to send log(N) transactions to the chain in order for me to get access to the final UTXO I am interested in. Who can construct such transaction path and what do they need for it and who pays fees on that (which input)? 3) Depending on 2) above, is it not possible for a malicious entity who is among the many users being paid, but who has very small UTXO there relative to others, to construct this middle transaction and use a very small fee rate in order to DoS other participants. Is it even possible for this attacker to create the middle transaction with RBF disabled? Thank you, Joachim Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, November 26, 2019 1:50 AM, Jeremy via bitcoin-dev wrote: > Bitcoin Developers, > > Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY > (replaces previous OP_SECURETHEBAG BIP). Primarily: > > 1) Changed the name to something more fitting and acceptable to the community > 2) Changed the opcode specification to use the argument off of the stack with > a primitive constexpr/literal tracker rather than script lookahead > 3) Permits future soft-fork updates to loosen or remove "constexpr" > restrictions > 4) More detailed comparison to alternatives in the BIP, and why > OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may make > it semi-redundant. > > Please see: > BIP:https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki > Reference > Implementation:https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify > > I believe this addresses all outstanding feedback on the design of this > opcode, unless there are any new concerns with these changes. > > I'm also planning to host a review workshop in Q1 2020, most likely in San > Francisco. Please fill out the form here https://forms.gle/pkevHNj2pXH9MGee9 > if you're interested in participating (even if you can't physically attend). > > And as a "but wait, there's more": > > 1) RPC functions are under preliminary development, to aid in testing and > evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted` > shows one way to use OP_CHECKTEMPLATEVERIFY. See: > https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs. > `sendmanycompacted` is still under early design. Standard practices for using > OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a separate > BIP. This work generalizes even if an alternative strategy is used to achieve > the scalability techniques of OP_CHECKTEMPLATEVERIFY. > 2) Also under development are improvements to the mempool which will, in > conjunction with improvements like package relay, help make it safe to lift > some of the mempool's restrictions on longchains specifically for > OP_CHECKTEMPLATEVERIFY output trees. See: > https://github.com/bitcoin/bitcoin/pull/17268This work offers an improvement > irrespective of OP_CHECKTEMPLATEVERIFY's fate. > > Neither of these are blockers for proceeding with the BIP, as they are > ergonomics and usability improvements needed once/if the BIP is activated. > > See prior mailing list discussions here: > > * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html > * > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html > > Thanks to the many developers who have provided feedback on iterations of > this design. > > Best, > > Jeremy > -- > [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Stamping transaction
Good morning Mostafa, > The main point of stamping transactions is decoupling transactions from the > block. > > Blockchain size matters > SegWit is a good witness that shows blockchain size matters. Nowadays, Data > storage is cheap and easy, but that doesn't mean it's a simple matter. If you > need to have a data-center to keep a copy of a blockchain, then you are far > from a decentralization system. > > A Solution > Stamping transaction is a simple idea to keep the size of the blockchain as > small as possible. The question that I was looking to answer is how we can > decouple the transaction from the blocks. > Who cares about the transaction that happened 10 years ago. In the real world > you may go to your bank and ask them to give you transaction history. But > they probably have limits. They might say we just only keep the last 3 months > in our system. Stamping transaction is not how you would be able to keep **blockchain** size low. The reason why very old history is retained is that, if a new node is brought up, you need to prove to that node that you are in fact the correct owner of the current coins. Thus the entire history of Bitcoin is needed when starting a new node, and why archive nodes exist. You might argue that banks do not do that, and that is because we want to do better than banks; we know that existing currency systems have not only the "official" minter, but also many "unofficial" minters (commonly called counterfeiters) which dilute the value of the currency. It is this insistence on a full accounting of the provenance for every satoshi that separates Bitcoin from previous currency systems; bank fraud exists, and it hides in such sloppy techniques as deleting old transaction records. Work has been done to have client-side validation (i.e. the owner of a coin keeps the entire history, and when paying, you hand over the entire history of your coin to the payee, instead of everyone validating every transaction). Look up Peter Todd for some initial work on this. > Implementation > > > First off, the proposed mechanism can be made into a softfork by using an > > unspendable `scriptPubKey` with 0 output value. > SoftFork is not possible here. Because the transaction will not be saved > inside the block (only tx hashes). Block format needs to be changed. > Therefore the block will be invalid. That greatly reduces the chances your proposal will get into Bitcoin; you would need to have very good advantages to counterbalance the tremendous risk that hardforks introduce in the continuity of the coin. Bitcoin has never gone through a hardfork that has not instead created a new cryptocurrency, so any solution that requires a hardfork is going to be unlikely to be accepted by everyone. > > Engineering-wise, block validation now needs to memorize the last N block > >hashes. > I don't think we need to memorize the last N block hashes. We can have > something like: > ``` > Current_Height - Height_Of(tx.stamp) <= N > ``` ... `Height_Of()` would basically be a mapping from block hashes to block heights, with the number of elements equal to the height of the blockchain, and thus continuously growing. Thus, validation is expected to become more expensive as the blockchain grows. Since stamped transactions have a time-to-live anyway, instead you can use a *set* of the most recent N block hashes. Then you simply check if the stamp is in the set. This creates a data structure that is constant in size (at each block, you remove the block from N blocks ago), which is good for validation. > Incentives > I think Stamping transactions have nothing to do with the incentivization > mechanism. Forgive me if I couldn't get your point. A stamped tranasction has a stamp, an unstamped transaction has no stamp. The stamped transaction is larger because of the stamp. Larger transactions are more expensive because fees. Thus, stamped transactions are more expensive than unstamped transactions. Convince me why I would make *my* transaction stamped when I can just convince *everyone else* to stamp *their* transactions and use unstamped transactions myself. If you propose that all transactions must be stamped in a new version of Bitcoin, then take note that users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. Why should users prefer a more expensive transaction format? For the good of the network? That is precisely an incentives problem: if it is so good for the network, then it should be good for an individual user, because the network is made up of individual users anyway; if individual users are not incentivized to use it, then that fact suggests it might not be as good for the network as you might think. If you answer "the stamp can be discounted" then be aware that validating the stamp is still a cost on every node, and it is that cost that we want to be reflected in pricing every byte
Re: [bitcoin-dev] Stamping transaction
Good day ZmnSCPxj Thank you so much for your time to read my proposal. About your comments, I do agree with some of them but maybe we need to discuss more about them. You might agree that any changes (especially a fundamental change like stamping transactions) comes with advantages and probably some disadvantages. I believe the advantages of stamping transactions are worth having it. *The main point of stamping transactions is decoupling transactions from the block. * *Blockchain size matters* SegWit is a good witness that shows blockchain size matters. Nowadays, Data storage is cheap and easy, but that doesn't mean it's a simple matter. If you need to have a data-center to keep a copy of a blockchain, then you are far from a decentralization system. *A Solution* Stamping transaction is a simple idea to keep the size of the blockchain as small as possible. The question that I was looking to answer is how we can decouple the transaction from the blocks. Who cares about the transaction that happened 10 years ago. In the real world you may go to your bank and ask them to give you transaction history. But they probably have limits. They might say we just only keep the last 3 months in our system. *Implementation* > First off, the proposed mechanism can be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. SoftFork is not possible here. Because the transaction will not be saved inside the block (only tx hashes). Block format needs to be changed. Therefore the block will be invalid. > Engineering-wise, block validation now needs to memorize the last N block hashes. I don't think we need to memorize the last N block hashes. We can have something like: ``` Current_Height - Height_Of(tx.stamp) <= N ``` *Incentives* I think Stamping transactions have nothing to do with the incentivization mechanism. Forgive me if I couldn't get your point. *Mempool* It's bad of me that I don't really know how mempool works in Bitcoin. My assumption is that there are some junk transactions (transactions that are valid but have very low or zero fees) inside the mempool. Stamping transactions might help to get rid of them time to time. Best Regards, Mostafa On Sun, Jun 7, 2020 at 8:40 AM ZmnSCPxj wrote: > Good morning Mostafa, > > First off, the proposed mechanism can be made into a softfork by using an > unspendable `scriptPubKey` with 0 output value. > > For example, a stamp could by convention be any 0-value output whose > `scriptPubKey` is ` OP_0`, which should be unspendable. > > Post-softfork nodes would reject blocks where some transaction is stamped > and the stamped `` is not within the last N blocks. > Pre-softfork nodes would not see anything special about the unspendable > `scriptPubKey` and would just accept it (but would not relay such > transactions due to standardness). > > Engineering-wise, block validation now needs to memorize the last N block > hashes. > > The mempool design currently assumes that a transaction that enters the > mempool is always valid unless any UTXOs it spends have been removed. > This is important since miner block selection algorithms assume the > mempool contains transactions that are currently valid. > Thus, there is the additional need to drop transactions from the mempool > if they are stamped with a block that has dropped from the stamp TTL. > > Another issue is incentives. > The stamp takes up blockchain space that is paid for by the creator of the > transaction. > Further, the creator of the transaction gains no advantage from the > stamped transaction; it is others who gain an advantage (the stamped > transaction is more likely to be dropped from the mempool). > Discounting the stamp somehow will probably make this into a hardfork. > It might be sneaked into the witness somehow by adding it as a field > somewhere in the new parts of Taproot (there is, a new block of data in > Taproot that can be used for this), but note that the cost will still be > non-zero (and users of this feature will still have a disadvantage in that > their transactions are more likely to be dropped from the mempool). > > Finally, it is expected to increase bandwidth use since a dropped stamped > transaction will probably be rebroadcast with a new stamp, so effectively > the transaction is retransmitted again with a different stamp. > > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
