Re: [bitcoin-dev] Bitcoin covenants are inevitable
> If the only realistic (fair, efficient & proportionate) way to pay for > Bitcoin's security was by having some inflation scheme that violated the 21 > million cap, then agreeing to break the limit would probably be what makes > sense, and in the economic interest of its users and holders. So, Paul Sztorc was right again, there are three options: Enormous Block Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I think using Merged Mining is the best option. More about that: https://www.truthcoin.info/blog/security-budget-ii-mm/ > Another option, if we were to decide we are over-secured in the short term, > would be to soft-fork in a reduction in the current and near-future mining > rewards, by somehow locking the coins in a contract that deprived the miner > of the full reward, and then using that contract to pay the rewards out far > in the future, should at some point we feel the security budget was > insufficient. Yes, that's also possible, RSK uses that. And making some kind of soft-fork for that is also possible, but I don't know if miners will agree to send some coinbase reward to " OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE". On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev wrote: >Bitcoin's finite supply is the main argument for people investing in it, the >whole narrative around bitcoin is based on its finite supply. While it has its >flaws and basically condemns bitcoin to be only used as a store >of value (and >not as a currency), I don't think it's worth questioning it at this point. > >Just my 2 sats. > >Giuseppe. A finite supply alone is not enough to give something value, as it must also be useful in some way. In the case of Bitcoin, various forms of cryptographic security must all work - and work together - to make Bitcoin useful. If the only realistic (fair, efficient & proportionate) way to pay for Bitcoin's security was by having some inflation scheme that violated the 21 million cap, then agreeing to break the limit would probably be what makes sense, and in the economic interest of its users and holders. There will always be competitive pressures with respect to efficiency, and both being over-secured and under-secured would be economically inefficient for a crypto currency, and thereby laving room for a more optimally-secured competitor to gain ground. Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. There is also zero agreement on how much security would constitute such an optimum. Figuring out how much security is needed, or even better, figuring out a way to have a market mechanism to answer that question, will be an important project. Another option, if we were to decide we are over-secured in the short term, would be to soft-fork in a reduction in the current and near-future mining rewards, by somehow locking the coins in a contract that deprived the miner of the full reward, and then using that contract to pay the rewards out far in the future, should at some point we feel the security budget was insufficient. Anthony Towns presented a form of this concept in greater detail at a Scaling Bitcoin conference some years ago. While this solution, if employed, would only work for some finite amount of time, it is possible that could give additional decades before the accumulated security budget was exhausted. Corey ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
Hi Peter, > Note that Wasabi already has a DoS attack vector in that a participant can > stop > participating after the first phase of the round, with the result that the > coinjoin fails. Wasabi mitigates that by punishing participating in future > rounds. Double-spends only create additional types of DoS attack that need to > be detected and punished as well - they don't create a fundamentally new > vulerability. I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast. Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460 If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users? /dev/fd0 Sent with Proton Mail secure email. --- Original Message --- On Monday, June 27th, 2022 at 12:43 AM, Peter Todd wrote: > On Sun, Jun 26, 2022 at 04:40:24PM +, alicexbt via bitcoin-dev wrote: > > > Hi Antoine, > > > > Thanks for sharing the DoS attack example with alternatives. > > > > > - Caroll broadcasts a double-spend of her own input C, the double-spend > > > is attached with a low-fee (1sat/vb) and it does not signal opt-in RBF > > > - Alice broadcasts the multi-party transaction, it is rejected by the > > > network mempools because Alice double-spend is already present > > > > I think this affects almost all types of coinjoin transaction including > > coordinator based implementations. I tried a few things and have already > > reported details for an example DoS attack to one of the team but there is > > no response yet. > > > > It was fun playing with RBF, DoS and Coinjoin. Affected projects should > > share their opinion about full-rbf as it seems it might improve things. > > > > Example: > > > > In Wasabi an attacker can broadcast a transaction spending input used in > > coinjoin after sending signature in the round. This would result in a > > coinjoin tx which never gets relayed: > > https://nitter.net/144bytes/status/1540727534093905920 > > > Note that Wasabi already has a DoS attack vector in that a participant can > stop > participating after the first phase of the round, with the result that the > coinjoin fails. Wasabi mitigates that by punishing participating in future > rounds. Double-spends only create additional types of DoS attack that need to > be detected and punished as well - they don't create a fundamentally new > vulerability. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BGP hijacking on Bitcoin p2p network
Hi Elias, Thanks for sharing the links. I have also started working on a simple chrome extension which connects to local bitcoin core and checks IP address of all peers for prefix length and other things. I would highlight peers with different colors based on certain things in this extension. https://github.com/144bytes/bitcoin-core-extension /dev/fd0 Sent with Proton Mail secure email. --- Original Message --- On Friday, June 10th, 2022 at 6:44 AM, Elias Rohrer wrote: > Hi alicexbt, > > Routing attacks have actually been studied quite a bit in literature. > > You may be interested in the research articles of Maria Apostolaki et > al.[1,2], Muoi Tran et al.[3], and related works. > > Best, > > Elias > > 1: https://arxiv.org/pdf/1605.07524.pdf > [2]: https://arxiv.org/pdf/1808.06254.pdf > [3]: https://allquantor.at/blockchainbib/pdf/tran2020stealthier.pdf > > On 9 Jun 2022, at 20:24, alicexbt via bitcoin-dev wrote: > > > Hi Bitcoin Developers, > > > > Based on this answer from 2014, bitcoin nodes are vulnerable to BGP > > hijacking. There was an incident in March 2022, twitter prefix was hijacked > > and details are shared in 2 blog posts: > > > > https://isc.sans.edu/diary/rss/28488 > > > > https://www.manrs.org/2022/03/lesson-learned-twitter-shored-up-its-routing-security/ > > > > 'nusenu' had written an article about Tor network being vulnerable to BGP > > hijacking attacks: > > https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijacking-attacks-56d3b2ebfd92 > > > > After doing some research I found that RPKI ROA and BGP prefix length can > > help against BGP hijacking attacks. I checked BGP prefix length and RPKI > > ROA for first 10 IP addresses returned in `getnodeaddresses` in bitcoin > > core and it had vulnerable results. > > > > https://i.stack.imgur.com/KD7jH.png > > > > Has anyone written a detailed blog post or research article like nusenu? If > > not I would be interested to write one in next couple of weeks? > > Looking for some "technical" feedback, links if this was already discussed > > in past with some solutions. > > > > /dev/fd0 > > > > Sent with Proton Mail secure email. > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
