Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

Good morning Chris, > > Absolute timelocks mean that you can set a timer where you put your node to > > sleep without risk of loss of funds (basically, once the absolute timelocks > > have resolved, you can forget about CoinSwaps). > > But I think the ability to spend at any time would be bette

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Hmm, could that not be accomplished by simply building this into new messages? eg, send "betterprotocol", if you see a verack and no "betterprotocol" from your peer, send "worseprotocol" before you send a "verack". Matt On 8/21/20 5:17 PM, Jeremy wrote: As for an example of where you'd want mul

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Service bits are advertised, protocol support is not. https://en.bitcoin.it/wiki/Protocol_documentation#Network_address e > On Aug 21, 2020, at 14:08, Jeremy wrote: > >  > Actually we already have service bits (which are sadly limited) which allow > negotiation of non bilateral feature suppo

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but for

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature support, so this would supercede that. -- @JeremyRubin On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo wrote: > This

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

This seems to be pretty overengineered. Do you have a specific use-case in mind for anything more than simply continuing the pattern we've been using of sending a message indicating support for a given feature? If we find some in the future, we could deploy something like this, though the current

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

I have a proposal: Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, which is completed after feature negotiation. This should make everyone happy/unhappy, as in a new protocol number it's fair game to change these semantics to be clear that we're acking more than v

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

I’m pretty sure one can run whatever they want even without a BIP. There is nobody here to do any “allowing”. On the other hand, standards development is tedious for good reason. Generally speaking, overloading is a primary source of complexity (creating more branches in code and human explanat

Re: [bitcoin-dev] Time to lower minrelaytxfee ?

No strong opinions but: Denial of service attacks can become 5x cheaper. If you don't thoroughly test https://github.com/bitcoin/bitcoin/issues/16499 these changes you can end up with bugs that can cause issues on p2p network. On Fri, Aug 21, 2020 at 4:00 AM Dan Bryant via bitcoin-dev < bitcoin-

Re: [bitcoin-dev] Time to lower minrelaytxfee ?

Having large portions of the network using a different minrelayfee could make it easier to reliably get different parts of the network to accept different conflicting transactions into their mempools, which could potentially be used to double-spend unconfirmed non-rbf transactions with more ease. N

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Sure, we could do a new message for negotiation, but there doesn’t seem to be a lot of reason for it - using the same namespace for negotiation seems fine too. In any case, this is one of those things that doesn’t matter in the slightest, and if one person volunteers to write a BIP and code, no

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

Hello, On 21/08/2020 05:20, ZmnSCPxj wrote: > Good morning, > > > >> Right, so if the taker uses only a single maker then they must have more >> than one UTXO. > > Spending one UTXO is fine, it is generating a transaction that has one output > that is problematic. > > What needs to happen is

Re: [bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340

Pieter, Thanks for the illuminating write-up. There seem to be two questions here, one technical and one process: 1. Is changing to even tie-breaker for R the correct choice technically? I can't comment on the performance characteristics of using a square/even tie-breaker and I'll assume the numb

[bitcoin-dev] Time to lower minrelaytxfee ?

It's been 5 years since minrealytxfee was lowered. At the time bitcoin was trading for $255 and it was agreed that the fee of 5000 sat/vkB was too high. It was lowered to 1000 sat/vkB. In regards to how much anti-DoS protection that provided, it comes out to $0.00255 / vkB in USD terms. To have

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

Hi Anthony, This is what I was implying in my last post (the reference to the unnecessary overload of message typing). However, if one imagines a sequence diagram for this communication it becomes obvious that all such messages are 100% redundant with verack. e > On Aug 20, 2020, at 19:37, An