Re: [bitcoin-dev] Thoughts on soft-fork activation
Thanks Anthony for this writeup! I find it incredibly disappointing that the idea of naive flag day fork activation is being seriously discussed in the form of BIP 9. Activation of forks is not only about the included changes but also around the culture of how changes to Bitcoin should be and are made. Whether we like it or not, how Taproot activates will set a community understanding and future norms around how many changes are made. Members of this list lost sleep and years off their life from stress fighting to ensure that the process by which Bitcoin changes is not only principled in its rejection of unilateral changes, but also that that idea was broadly understood, and broadly *enforced* by community members - the only way in which it has any impact. That fight is far from over - Bitcoin's community grows and changes daily, and the history around what changed and how has been rewritten time and time again. Worse still, the principled nature of Bitcoin's change process is targeted constantly as untrue in an attempt by various alternative systems to pretend that their change process of "developers ship new code, users run it blindly" is identical to Bitcoin. While members of this list may be aware of significant outreach efforts and design work to ensure that Taproot is not only broadly acceptable to Bitcoin users, but also has effectively no impact on users who wish not to use it, it is certainly not the case that all Bitcoin users are aware of that work, nor seen the results directly communicated to them. Worse still, it is hard to argue that a new version of Bitcoin Core containing a fixed future activation of a new consensus rule is anything other than "developers have decided on new rules" (even if it is, based on our own knowledge, not the case). Indeed, even the proposal by Anthony, which makes reference to my previous work has this issue, and it may not be avoidable - there is very legitimate concern over miners blocking changes to Bitcoin which do not harm them which users objectively desire, potentially purely through apathy. But to dismiss the concerns over the optics which set the stage for how future changes are made to Bitcoin purely because miners may be too busy with other things to upgrade their nodes seems naive at best. I appreciate the concern over activation timeline given miner apathy, and to some extend Anthony's work here addresses that with decreasing activation thresholds during the second signaling period, but bikeshedding on timeline may be merited. To not make every attempt to distance the activation method from the public perception unilateral activation strikes me as the worst of all possible outcomes for Bitcoin's longevity. Having a quieting period after BIP 9 activation failure may not be the best way to do that, but it seems like a reasonable attempt. Matt On 7/14/20 5:37 AM, Anthony Towns via bitcoin-dev wrote: > Hi, > > I've been trying to figure out a good way to activate soft forks in > future. I'd like to post some thoughts on that. So: > > I think there's two proposals that are roughly plausible. The first is > Luke's recent update to BIP 8: > > https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki > > It has the advantage of being about as simple as possible, and (in my > opinion) is an incremental improvement on how segwit was activated. Its > main properties are: > >- signalling via a version bit >- state tansitions based on height rather than median time >- 1 year time frame >- optional mandatory activation at the end of the year >- mandatory signalling if mandatory activation occurs >- if the soft fork activates on the most work chain, nodes don't > risk falling out of consensus depending on whether they've opted in > to mandatory activation or not > > I think there's some fixable problems with that proposal as it stands > (mostly already mentioned in the comments in the recently merged PR, > https://github.com/bitcoin/bips/pull/550 ) > > The approach I've been working on is based on the more complicated and > slower method described by Matt on this list back in January. I've got a > BIP drafted at: > > > https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki > > The main difference with the mechanism described in January is that the > threshold gradually decreases during the secondary period -- it starts at > 95%, gradually decreases until 50%, then mandatorily activates. The idea > here is to provide at least some potential reward for miners signalling > in the secondary phase: if 8% of hashpower had refused to signal for > a soft-fork, then there would have been no chance of activating until > the very end of the period. This way, every additional percentage of > hashpower signalling brings the activation deadline forward. > > The main differences between the two proposals is that the BIP 8 approach > has a relatively short time
Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
Good morning Mr. Lee, > Sorry. Re-sending with correction to CC bitcoin-dev > > I am sorry if this was already brought up in previous threads. If I know > lightning network correctly then HTLC is used to enforce settlements on > blockchain if there is a dispute. Could a person lose money if their HTLC > does not get confirmed in the timeframe or if an older HTLC gets > confirmed first? I see different ways this could happen. > > One, if the blockchain is very saturated with other transactions. The > reason we need lightning network is why it might have troubles with > settlements? This could happen, but the entire exercise is to move transactions off the blockchain, precisely to lower this risk. Otherwise, transfers onchain will take a long time. In practice, a long time to settle a payment will invalidate many real-world economic exchanges anyway (consider paying for food at a restaurant --- if your payments take days to settle, the food has gotten stale before the restaurant receives payment and releases your food). Thus, if an onchain transfer takes a long time to settle, there is already risk of economic loss present. By moving activity offchain, we reduce pressure onchain and improve settlement speeds on both offchain and onchain, reducing risk of economic loss due to delay. > Two, competition from a different conflicting HTLC. A newer > HTLC might not get confirmed before an older HTL. I cannot make sense of this. You cannot create conflicting HTLCs. Either you have some free money to create an HTLC, in which case there is no possible conflict with an existing HTLC (the fund is reserved for HTLCs, or it is yours without further encumbrance). Thus it is not possible to create a conflicting HTLC in any case: either you have funds (that are not already in an HTLC) to fund an HTLC and that HTLC cannot conflict with existing ones, or you have no funds and a new HTLC cannot be created until one of the HTLCs is resolved one way or another. > Three, denial of service > the lightning router so they never have a chance to send a settlement > HTLC. This is possible, but only that node risks loss. The reason why unilateral close is always possible is to handle the case where a routing node comes offline. If you have offered an HTLC to a routing node, you retain a timelock branch back to you (the "T" in HTLC). If the routing node goes offline past the timelock in the HTLC, then you unilaterally close the channel and drop the HTLC onchain. This is what lets you recover your funds. > > I found out about a recent attack technique that sounds like it might be > similar called "flood and loot". Roughly, my understanding of Flood and Loot is to make a lot of uneconomically tiny HTLCs going through a target victim forwarding node. You make circular routes going from your own node back to yourself. Then you refuse to actually claim the HTLCs sent back to yourself. Then you go offline. This means that the only way for the forwarding node to recover its funds is to drop the channel(s) involved onchain. But if the HTLCs are many and tiny, they are simply too uneconomic to claim onchain, so they just lose the channel funds as fees. > > Is this a concern on lightning network? Yes. Work is being done (anchor commitments) to mitigate the effects of onchain fees on Lightning. > I humbly say that I do not fully > understand all of lightning network yet. I am working to grasp the idea. > These are questions I look to find answer for. Another question I have. I > did read the paper Scalable Funding of Bitcoin Micropayment Channel > Networks. Would channel factories be better and eliminate my concern? They would not. Ultimately, your "final defense" is to drop the entire construction onchain until you reach the HTLCs and you can have the blockchain enforce the HTLC contract. It would *help* to reduce blockchain bloat by reducing the size of transactions to create multiple channels, and thus also secondarily helps reduce onchain fee pressure and also reduce Flood-and-Loot (which is basically a layer-crossing attack, taking advantage of lower-layer fees to create attacks on higher layers). But always the underlying problem remains: security costs something, and you have to pay for protection on the Internet when transacting with potentially untrusted (and untrustable) entities. It seems unlikely that "security costs something" can be eliminated. One can consider that modern-day state-imposed taxation is paying for security, for instance, of traditional face-to-face transactions. With Bitcoin, you can choose to either transact and pay for security, or not transact and forgo what you would have bought. With some tradeoffs, you can pay by other means that may be cheaper for you. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
Sorry. Re-sending with correction to CC bitcoin-dev I am sorry if this was already brought up in previous threads. If I know lightning network correctly then HTLC is used to enforce settlements on blockchain if there is a dispute. Could a person lose money if their HTLC does not get confirmed in the timeframe or if an older HTLC gets confirmed first? I see different ways this could happen. One, if the blockchain is very saturated with other transactions. The reason we need lightning network is why it might have troubles with settlements? Two, competition from a different conflicting HTLC. A newer HTLC might not get confirmed before an older HTL. Three, denial of service the lightning router so they never have a chance to send a settlement HTLC. I found out about a recent attack technique that sounds like it might be similar called "flood and loot". Is this a concern on lightning network? I humbly say that I do not fully understand all of lightning network yet. I am working to grasp the idea. These are questions I look to find answer for. Another question I have. I did read the paper Scalable Funding of Bitcoin Micropayment Channel Networks. Would channel factories be better and eliminate my concern? I am sending this to lightning-dev mailing list. I do not see lightning-dev emails because google recaptcha blocks me from the subscribe. Please CC me if you reply so I can read it. -- lee.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Thoughts on soft-fork activation
Hi, I've been trying to figure out a good way to activate soft forks in future. I'd like to post some thoughts on that. So: I think there's two proposals that are roughly plausible. The first is Luke's recent update to BIP 8: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki It has the advantage of being about as simple as possible, and (in my opinion) is an incremental improvement on how segwit was activated. Its main properties are: - signalling via a version bit - state tansitions based on height rather than median time - 1 year time frame - optional mandatory activation at the end of the year - mandatory signalling if mandatory activation occurs - if the soft fork activates on the most work chain, nodes don't risk falling out of consensus depending on whether they've opted in to mandatory activation or not I think there's some fixable problems with that proposal as it stands (mostly already mentioned in the comments in the recently merged PR, https://github.com/bitcoin/bips/pull/550 ) The approach I've been working on is based on the more complicated and slower method described by Matt on this list back in January. I've got a BIP drafted at: https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki The main difference with the mechanism described in January is that the threshold gradually decreases during the secondary period -- it starts at 95%, gradually decreases until 50%, then mandatorily activates. The idea here is to provide at least some potential reward for miners signalling in the secondary phase: if 8% of hashpower had refused to signal for a soft-fork, then there would have been no chance of activating until the very end of the period. This way, every additional percentage of hashpower signalling brings the activation deadline forward. The main differences between the two proposals is that the BIP 8 approach has a relatively short time frame for users to upgrade if we want mandatory activation without a supermajority of hashpower enforcing the rules; while the "decreasing threshold" approach linked above provides quite a long timeline. In addition, there is always the potential to introduce a BIP 91/148 style soft-fork after the fact where either miners or users coordinate to have mandatory signalling which then activates a pre-existing deployment attempt. I think the design constraints we want are: * if everyone cooperates and no one objects, we activate pretty quickly * there's no obvious exploits, and we have plausible contingency plans in place to discourage people from try to use the attempt to deploy a new soft fork as a way of attacking bitcoin, either via social disruption or by preventing bitcoin from improving * we don't want to ship code that causes people to fall out of consensus in the (hopefully unlikely) event that things don't go smoothly [0] In light of that, I think I'm leaning towards: * use BIP 8 with mandatory activation disabled in bitcoin core -- if you want to participate in enforcing mandatory activation, you'll need to recompile, or use a fork like bitcoin knots; however if mandatory activation occurs on the longest chain, you'll still follow that chain and enforce the rules. * be prepared to update the BIP 8 parameters to allow mandatory activation in bitcoin core if, after 9 months say, it's apparent that there aren't reasonable objections, there's strong support for activation, the vast majority of nodes have already updated to enforce the rules upon activation, and there's strong support for mandatory activation * change the dec-threshold proposal to be compatible with BIP 8, and keep it maintained so that it can be used if there seems to be widespread consensus for activation, but BIP 8 activation does not seem certain -- ie, as an extra contingency plan. * be prepared to support miners coordinating via BIP 91 either to bring activation forward in either BIP 8 or "decreasing threshold" or de-risk BIP 8 mandatory activation -- ie, an alternative contingency plan. This is more appropriate if we've found that users/miners have upgraded so that activation is safe; so it's a decision we can make later when we have more data, rather than having to make the decision early when we don't have enough information to judge whether it's safe or not. * (also, improve BIP 8 a bit more before deploying it -- I'm hoping for some modest changes, which is why "decreasing threshold" isn't already compatible with BIP 8) * (continue to ensure the underlying soft fork makes sense and is well implemented on its own merits) * (continue to talk to as many people as we can about the underlying changes and make sure people understand what's going on and that we've addressed any reasonable objections) I'm hopeful activating taproot will go smoothly, but I'm not 100% sure of it, and there
