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

[ZmnSCPxj via bitcoin-dev]

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 better, and getting 
> > 100% online 144 blocks a day, 2016 blocks a retargeting period is becoming 
> > more and more feasible.
>
> You can always put your node to sleep as a maker, and your watchtowers
> will protect you.

Assuming you have multiple watchtowers, yes.

It would be best if watchtowers for CoinSwap and watchtowers for Lightning 
could be the same thing, and ideally, a watchtower would not even know if what 
it was watching were a Lightning channel or a CoinSwap until an attack happens.

>
> What do you mean by the point about 100% online nodes getting more
> feasible? Many bitcoin nodes have been always-on for years, I think I
> missed something.

Not all locations on Earth make it easy to be 100% online.
However, as the technology of you puny humans advance, it becomes more and more 
possible for a random point on Earth to be 100% online.

> > > You're right that attempting such an move by the taker is riskless, but
> > > its not costless. The taker sets up the entire CoinSwap protocol because
> > > they wanted more privacy; but if the taker broadcasts the Alice contract
> > > transaction and waits for the timeout, then all they've achieved is
> > > spent miner fees, got their own coin back and draw attention to it with
> > > the unusual HTLC script. They've achieved no benefit from what I see, so
> > > they won't do this. Any taker or maker who attempts anything like this
> > > will be spending miner fees.
> >
> > They would be spending miner fees from the funds being stolen, thus still 
> > costless.
> > In particular, let us imagine a simple 1-maker swap.
> >
> > -   The taker and the maker complete the swap.
> > -   The taker now has possession of:
> > -   The private key for its incoming HTLC.
> > -   The pre-signed contract transaction for its outgoing HTLC.
> > -   The taker spends from its incoming HTLC using the private key.
> > -   The maker ignores this, because this is just normal operation.
> > -   Fees paid for this is not an additional cost, because a taker that 
> > wants to put its freshly-private funds into cold storage will do this 
> > anyway.
> > -   The taker gets a fresh, private coin from this incoming HTLC, so it 
> > gets the privacy it paid for.
> > -   The taker waits for the incoming-HTLC-spend to confirm.
> > -   The taker broadcasts the pre-signed contract transaction, in the hope 
> > that the maker is offline.
> > -   The fees paid for this are from the contract transaction that the 
> > taker is trying to steal.
> > Even if the theft attempt fails, the taker has already gotten its 
> > private money out, and is thus not risking anything.
> >
> > -   Semantically, the outgoing HTLC is already "owned" by the maker 
> > (the maker has private key to it).
> > -   Thus, the taker commits an action that the maker pays fees for!
> > -   The maker cannot react except to spend via the hashlock branch.
> > In particular, because the taker-incoming (maker-outgoing) UTXO is 
> > already spent, it cannot retaliate by also broadcasting the contract 
> > transaction of the taker-incoming (maker-outgoing) HTLC.
> >
> > -   The theft succeeds (the timelock passes) because the maker happens to 
> > be offline for that long.
> > -   This is "free money" to the taker, who has already gotten what it 
> > paid for --- private money in cold storage --- from the CoinSwap.
> > -   Even if the stolen fund reveals the contract, the taker can 
> > re-acquire privacy for the funds it stole for free, by paying for --- wait 
> > for it --- another CoinSwap for its swag.
>
> Yep you're right, I get it.
>
> The biggest defense against theft will have to be multiple redundant
> watchtowers. But as you say the attack is riskless and costless for the
> taker to attempt, so they might try anyway even if the probability of
> success is very low.
>
> If this attack becomes widespread then it effectively breaks the
> property that maker's coins remain unspent indefinitely. It seems like
> that would lead to makers increasing their CoinSwap fees because they
> know they'll always have to spend a bit of miner fees afterwards.
>
> Hopefully the success rate for this attack can be low enough that
> taker's human niceness will stop them trying. But for sure this is a
> concerning problem.

Indeed.

We also cannot use succinct atomic swaps because their asymmetry makes them 
unroutable --- you can only use it for single-maker swaps.
This makes it obvious to the maker that you have only a single maker.

> > Using an absolute timelock (implemented by a `nLockTime` tx directly off 
> > the 2-of-2, not `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 

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

[Matt Corallo via bitcoin-dev]

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 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 old nodes you'll still do it if B is unknown to them. An 
example of this would be (were it not already out without a feature negotiation existing) WTXID/TXID relay.


The SYNC primitve simply codifies what order messages should be in and when you're done for a phase of negotiation 
offering something. It can be done without, but then you have to be more careful to broadcast in the correct order and 
it's not clear when/if you should wait for more time before responding.



On Fri, Aug 21, 2020 at 2:08 PM Jeremy mailto:jlru...@mit.edu>> wrote:

Actually we already have service bits (which are sadly limited) which allow 
negotiation of non bilateral feature
support, so this would supercede that.
--
@JeremyRubin 



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

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 support, so this would supercede that.
> --
> @JeremyRubin
> 
> 
>> On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo  
>> wrote:
>> 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 proposal makes it 
>> possible to do it on a per-feature case.
>> 
>> The great thing about Suhas' proposal is the diff is about -1/+1 (not 
>> including tests), while still getting all the 
>> flexibility we need. Even better, the code already exists.
>> 
>> Matt
>> 
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> > 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 version.
>> > 
>> > I don't care about when or where these messages are sequenced overall, it 
>> > seems to have minimal impact. If I had free 
>> > choice, I slightly agree with Eric that verack should come before feature 
>> > negotiation, as we want to divorce the idea 
>> > that protocol number and feature support are tied.
>> > 
>> > But once this is done, we can supplant Verack with HANDSHAKENACK or 
>> > HANDSHAKEACK to signal success or failure to agree 
>> > on a connection. A NACK reason (version too high/low or an important 
>> > feature missing) could be optional. Implicit NACK 
>> > would be disconnecting, but is discouraged because a peer doesn't know if 
>> > it should reconnect or the failure was 
>> > intentional.
>> > 
>> > --
>> > 
>> > AJ: I think I generally do prefer to have a FEATURE wrapper as you 
>> > suggested, or a rule that all messages in this period 
>> > are interpreted as features (and may be redundant with p2p message types 
>> > -- so you can literally just use the p2p 
>> > message name w/o any data).
>> > 
>> > I think we would want a semantic (which could be based just on message 
>> > names, but first-class support would be nice) for 
>> > ACKing that a feature is enabled. This is because a transcript of:
>> > 
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > VERACK
>> > 
>> > NODE1:
>> > FEATURE A
>> > VERACK
>> > 
>> > It remains unclear if Node 1 ignored B because it's an unknown feature, or 
>> > because it is disabled. A transcript like:
>> > 
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > FEATURE C
>> > ACK A
>> > VERACK
>> > 
>> > NODE1:
>> > FEATURE A
>> > ACK A
>> > NACK B
>> > VERACK
>> > 
>> > would make it clear that A and B are known, B is disabled, and C is 
>> > unknown. C has 0 support, B Node 0 should support 
>> > inbound messages but knows not to send to Node 1, and A has full bilateral 
>> > support. Maybe instead it could a message 
>> > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit 
>> > rather than inferred from ACK/NACK.
>> > 
>> > 
>> > --
>> > 
>> > I'd also propose that we add a message which is SYNC, which indicates the 
>> > end of a list of FEATURES and a request to 
>> > send ACKS or NACKS back (which are followed by a SYNC). This allows 
>> > multi-round negotiation where based on the presence 
>> > of other features, I may expand the set of features I am offering. I think 
>> > you could do without SYNC, but there are more 
>> > edge cases and the explicitness is nice given that this already introduces 
>> > future complexity.
>> > 
>> > This multi-round makes it an actual negotiation rather than a pure 
>> > announcement system. I don't think it would be used 
>> > much in the near term, but it makes sense to define it correctly now. 
>> > Build for the future and all...
>> > 
>> > 
>> > 
>> > --
>> > @JeremyRubin 
>> > 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

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 old nodes you'll still do it if B is unknown to them. An example of
this would be (were it not already out without a feature negotiation
existing) WTXID/TXID relay.

The SYNC primitve simply codifies what order messages should be in and when
you're done for a phase of negotiation offering something. It can be done
without, but then you have to be more careful to broadcast in the correct
order and it's not clear when/if you should wait for more time before
responding.


On Fri, Aug 21, 2020 at 2:08 PM Jeremy  wrote:

> Actually we already have service bits (which are sadly limited) which
> allow negotiation of non bilateral feature support, so this would supercede
> that.
> --
> @JeremyRubin 
> 
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

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 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 proposal makes it
> possible to do it on a per-feature case.
>
> The great thing about Suhas' proposal is the diff is about -1/+1 (not
> including tests), while still getting all the
> flexibility we need. Even better, the code already exists.
>
> Matt
>
> On 8/21/20 3:50 PM, Jeremy wrote:
> > 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 version.
> >
> > I don't care about when or where these messages are sequenced overall,
> it seems to have minimal impact. If I had free
> > choice, I slightly agree with Eric that verack should come before
> feature negotiation, as we want to divorce the idea
> > that protocol number and feature support are tied.
> >
> > But once this is done, we can supplant Verack with HANDSHAKENACK or
> HANDSHAKEACK to signal success or failure to agree
> > on a connection. A NACK reason (version too high/low or an important
> feature missing) could be optional. Implicit NACK
> > would be disconnecting, but is discouraged because a peer doesn't know
> if it should reconnect or the failure was
> > intentional.
> >
> > --
> >
> > AJ: I think I generally do prefer to have a FEATURE wrapper as you
> suggested, or a rule that all messages in this period
> > are interpreted as features (and may be redundant with p2p message types
> -- so you can literally just use the p2p
> > message name w/o any data).
> >
> > I think we would want a semantic (which could be based just on message
> names, but first-class support would be nice) for
> > ACKing that a feature is enabled. This is because a transcript of:
> >
> > NODE0:
> > FEATURE A
> > FEATURE B
> > VERACK
> >
> > NODE1:
> > FEATURE A
> > VERACK
> >
> > It remains unclear if Node 1 ignored B because it's an unknown feature,
> or because it is disabled. A transcript like:
> >
> > NODE0:
> > FEATURE A
> > FEATURE B
> > FEATURE C
> > ACK A
> > VERACK
> >
> > NODE1:
> > FEATURE A
> > ACK A
> > NACK B
> > VERACK
> >
> > would make it clear that A and B are known, B is disabled, and C is
> unknown. C has 0 support, B Node 0 should support
> > inbound messages but knows not to send to Node 1, and A has full
> bilateral support. Maybe instead it could a message
> > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit
> rather than inferred from ACK/NACK.
> >
> >
> > --
> >
> > I'd also propose that we add a message which is SYNC, which indicates
> the end of a list of FEATURES and a request to
> > send ACKS or NACKS back (which are followed by a SYNC). This allows
> multi-round negotiation where based on the presence
> > of other features, I may expand the set of features I am offering. I
> think you could do without SYNC, but there are more
> > edge cases and the explicitness is nice given that this already
> introduces future complexity.
> >
> > This multi-round makes it an actual negotiation rather than a pure
> announcement system. I don't think it would be used
> > much in the near term, but it makes sense to define it correctly now.
> Build for the future and all...
> >
> >
> >
> > --
> > @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] Generalizing feature negotiation when new p2p connections are setup

[Matt Corallo via bitcoin-dev]

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 proposal makes it possible to do it on a per-feature case.


The great thing about Suhas' proposal is the diff is about -1/+1 (not including tests), while still getting all the 
flexibility we need. Even better, the code already exists.


Matt

On 8/21/20 3:50 PM, Jeremy wrote:

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 version.


I don't care about when or where these messages are sequenced overall, it seems to have minimal impact. If I had free 
choice, I slightly agree with Eric that verack should come before feature negotiation, as we want to divorce the idea 
that protocol number and feature support are tied.


But once this is done, we can supplant Verack with HANDSHAKENACK or HANDSHAKEACK to signal success or failure to agree 
on a connection. A NACK reason (version too high/low or an important feature missing) could be optional. Implicit NACK 
would be disconnecting, but is discouraged because a peer doesn't know if it should reconnect or the failure was 
intentional.


--

AJ: I think I generally do prefer to have a FEATURE wrapper as you suggested, or a rule that all messages in this period 
are interpreted as features (and may be redundant with p2p message types -- so you can literally just use the p2p 
message name w/o any data).


I think we would want a semantic (which could be based just on message names, but first-class support would be nice) for 
ACKing that a feature is enabled. This is because a transcript of:


NODE0:
FEATURE A
FEATURE B
VERACK

NODE1:
FEATURE A
VERACK

It remains unclear if Node 1 ignored B because it's an unknown feature, or 
because it is disabled. A transcript like:

NODE0:
FEATURE A
FEATURE B
FEATURE C
ACK A
VERACK

NODE1:
FEATURE A
ACK A
NACK B
VERACK

would make it clear that A and B are known, B is disabled, and C is unknown. C has 0 support, B Node 0 should support 
inbound messages but knows not to send to Node 1, and A has full bilateral support. Maybe instead it could a message 
FEATURE SEND A and FEATURE RECV A, so we can make the split explicit rather than inferred from ACK/NACK.



--

I'd also propose that we add a message which is SYNC, which indicates the end of a list of FEATURES and a request to 
send ACKS or NACKS back (which are followed by a SYNC). This allows multi-round negotiation where based on the presence 
of other features, I may expand the set of features I am offering. I think you could do without SYNC, but there are more 
edge cases and the explicitness is nice given that this already introduces future complexity.


This multi-round makes it an actual negotiation rather than a pure announcement system. I don't think it would be used 
much in the near term, but it makes sense to define it correctly now. Build for the future and all...




--
@JeremyRubin 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

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
version.

I don't care about when or where these messages are sequenced overall, it
seems to have minimal impact. If I had free choice, I slightly agree with
Eric that verack should come before feature negotiation, as we want to
divorce the idea that protocol number and feature support are tied.

But once this is done, we can supplant Verack with HANDSHAKENACK or
HANDSHAKEACK to signal success or failure to agree on a connection. A NACK
reason (version too high/low or an important feature missing) could be
optional. Implicit NACK would be disconnecting, but is discouraged because
a peer doesn't know if it should reconnect or the failure was intentional.

--

AJ: I think I generally do prefer to have a FEATURE wrapper as you
suggested, or a rule that all messages in this period are interpreted as
features (and may be redundant with p2p message types -- so you can
literally just use the p2p message name w/o any data).

I think we would want a semantic (which could be based just on message
names, but first-class support would be nice) for ACKing that a feature is
enabled. This is because a transcript of:

NODE0:
FEATURE A
FEATURE B
VERACK

NODE1:
FEATURE A
VERACK

It remains unclear if Node 1 ignored B because it's an unknown feature, or
because it is disabled. A transcript like:

NODE0:
FEATURE A
FEATURE B
FEATURE C
ACK A
VERACK

NODE1:
FEATURE A
ACK A
NACK B
VERACK

would make it clear that A and B are known, B is disabled, and C is
unknown. C has 0 support, B Node 0 should support inbound messages but
knows not to send to Node 1, and A has full bilateral support. Maybe
instead it could a message FEATURE SEND A and FEATURE RECV A, so we can
make the split explicit rather than inferred from ACK/NACK.


--

I'd also propose that we add a message which is SYNC, which indicates the
end of a list of FEATURES and a request to send ACKS or NACKS back (which
are followed by a SYNC). This allows multi-round negotiation where based on
the presence of other features, I may expand the set of features I am
offering. I think you could do without SYNC, but there are more edge cases
and the explicitness is nice given that this already introduces future
complexity.

This multi-round makes it an actual negotiation rather than a pure
announcement system. I don't think it would be used much in the near term,
but it makes sense to define it correctly now. Build for the future and
all...



--
@JeremyRubin 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

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 explanation). Nevertheless this is verack 
payload, no additional messages are necessary or helpful.

e

> On Aug 21, 2020, at 07:15, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> 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 reason 
> they shouldn’t just decide and be allowed to run with it. Rough consensus and 
> running code, as it were :)
> 
> Matt
> 
> 
>>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev 
>>>  wrote:
>>> 
>>> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev 
>>> wrote:
>>> In thinking about the mechanism used there, I thought it would be helpful to
>>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>>> messages received before a VERACK.  A draft of my proposal is available here
>>> [2].
>> 
>> Rather than allowing arbitrary messages, maybe it would make sense to
>> have a specific feature negotiation message, eg:
>> 
>> VERSION ...
>> FEATURE wtxidrelay
>> FEATURE packagerelay
>> VERACK
>> 
>> with the behaviour being that it's valid only between VERSION and VERACK,
>> and it takes a length-prefixed-string giving the feature name, optional
>> additional data, and if the feature name isn't recognised the message
>> is ignored.
>> 
>> If we were to support a "polite disconnect" feature like Jeremy suggested,
>> it might be easier to do that for a generic FEATURE message, than
>> reimplement it for the message proposed by each new feature.
>> 
>> Cheers,
>> aj
>> 
>> ___
>> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Greg Sanders via bitcoin-dev]

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-dev@lists.linuxfoundation.org> wrote:

> 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 parity with the last reduction, we would
> need to reduce minrealytxfee to 22 sat/vKB, though an even more
> conservative reduction to 100 or 50 sat/vKB would be welcome.
>
> With the growing adoption of LN, there is a need for ultra-low-fee
> on-chain TXNs.  Having these queue and confirm overnight, or even
> waiting until the Sunday lull would still probably be welcome to many
> users.  The fact that the mempool is going empty at least every week
> indicates that miners have not reached the floor of what they are
> willing to mine.
>
> About 2 years ago there was a PR (#13922) to try to make a reduction
> from 1000 to 200 sat/vkB.  It was widely accepted but the submitter
> eventually closed it in favor of PR #13990.
>
> If minrelaytxfee is already parameterized and configurable in
> bitcoin.conf, how could it be detrimental to operation of a node to
> change the default?
>
> References:
>
> *
> https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
> * https://github.com/bitcoin/bitcoin/pull/13922
> * https://github.com/bitcoin/bitcoin/pull/13990
> ___
> 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

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

[Nadav Ivgi via bitcoin-dev]

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. Node operators that accept unconfirmed payments with a
minrelayfee that's higher than what other nodes/miners are typically
accepting would be at risk.

Relying on unconfirmed transactions is of course discouraged so I'm not
sure how much weight this should be given if at all, but I thought it was
at least worth bringing up.

Nadav


On Fri, Aug 21, 2020 at 11:00 AM Dan Bryant via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 parity with the last reduction, we would
> need to reduce minrealytxfee to 22 sat/vKB, though an even more
> conservative reduction to 100 or 50 sat/vKB would be welcome.
>
> With the growing adoption of LN, there is a need for ultra-low-fee
> on-chain TXNs.  Having these queue and confirm overnight, or even
> waiting until the Sunday lull would still probably be welcome to many
> users.  The fact that the mempool is going empty at least every week
> indicates that miners have not reached the floor of what they are
> willing to mine.
>
> About 2 years ago there was a PR (#13922) to try to make a reduction
> from 1000 to 200 sat/vkB.  It was widely accepted but the submitter
> eventually closed it in favor of PR #13990.
>
> If minrelaytxfee is already parameterized and configurable in
> bitcoin.conf, how could it be detrimental to operation of a node to
> change the default?
>
> References:
>
> *
> https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
> * https://github.com/bitcoin/bitcoin/pull/13922
> * https://github.com/bitcoin/bitcoin/pull/13990
> ___
> 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

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

[Matt Corallo via bitcoin-dev]

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 reason they shouldn’t 
just decide and be allowed to run with it. Rough consensus and running code, as 
it were :)

Matt


> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev 
>  wrote:
> 
> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev 
> wrote:
>> In thinking about the mechanism used there, I thought it would be helpful to
>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>> messages received before a VERACK.  A draft of my proposal is available here
>> [2].
> 
> Rather than allowing arbitrary messages, maybe it would make sense to
> have a specific feature negotiation message, eg:
> 
>  VERSION ...
>  FEATURE wtxidrelay
>  FEATURE packagerelay
>  VERACK
> 
> with the behaviour being that it's valid only between VERSION and VERACK,
> and it takes a length-prefixed-string giving the feature name, optional
> additional data, and if the feature name isn't recognised the message
> is ignored.
> 
> If we were to support a "polite disconnect" feature like Jeremy suggested,
> it might be easier to do that for a generic FEATURE message, than
> reimplement it for the message proposed by each new feature.
> 
> Cheers,
> aj
> 
> ___
> 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

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

[Chris Belcher via bitcoin-dev]

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 that this single UTXO is spent to two outputs: the 
> CoinSwap 2-of-2 and the change output.
> This is because intermediate makers will have very high likelihood of 
> generating such a pattern (it is unlikely they have an exact amount that a 
> taker would require of them), and the occassional maker might have a very 
> large UTXO that it can use for similar purposes.
> 
> One thing a taker can do would be to multipath its CoinSwap, i.e. it spends 
> any number of UTXOs and creates two outputs, which are actually two separate 
> CoinSwap 2-of-2s to different makers.
> As each maker is unaware of the other, this should be similar to the case 
> where the maker is an intermediate hop and is getting its incoming HTLC from 
> another maker, which is unlikely to have a precise amount and will thus have 
> a transaction that has two outputs, the 2-of-2 CoinSwap and the change.

Agreed.
I write about multipath CoinSwap routes in the original design document,
under "Combining multi-transaction with routing"


 === Miner fees ===
 Makers have no incentive to pay any miner fees. They only do
 transactions which earn them an income and are willing to wait a very
 long time for that to happen. By contrast takers want to create
 transactions far more urgently. In JoinMarket we coded a protocol where
 the maker could contribute to miner fees, but the market price offered
 of that trended towards zero. So the reality is that takers will pay all
 the miner fees. Also because makers don't know the taker's time
 preference they don't know how much they should pay in miner fees.
 The taker will have to set limits on how large the maker's transactions
 are, otherwise makers could abuse this by having the taker consolidate
 maker's UTXOs for free.
>>>
>>> Why not have the taker pay for the first maker-spent UTXO and have 
>>> additional maker-spent UTXOs paid for by the maker?
>>> i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 
>>> BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).
>>> Disagreements on feerate can be resolved by having the taker set the 
>>> feerate, i.e. "the customer is always right".
>>> Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it 
>>> pays for the mining fees for that extra UTXO.
>>> The maker can always reject the swap attempt if it has to spend multiple 
>>> UTXOs and would lose money doing so if the taker demands a too-high feerate.
>>
>> Having the taker pay for just one UTXO will have an unfortunate side
>> effect of resulting in the maker's money being split up into a large
>> number of UTXOs, because every CoinSwap they take part in has an
>> incentive to increase their UTXO count by one. At the start of
>> JoinMarket this was an issue where then a taker wanting to CoinJoin a
>> large would come along and the result would be a huge CoinJoin
>> transaction with many many small inputs. Perhaps the taker could pay for
>> 2-3 UTXOs to counteract this. (Of course the exact number would be
>> configurable by the taker user, but defaults usually don't get changed).
>>
>> I'm still not convinced with having makers contribute to miner fees. In
>> JoinMarket we tried to get makers to contribute a little to miner fees
>> and simply they never did in any meaningful way. The market has spoken.
>> In terms of incentives makers are happy to wait a very long time, if we
>> assume they're just HODLers then even if they earn a few thousand
>> satoshis that's good.
>>
 == Contract transaction definitions ==
 Contract transactions are those which may spend from the 2-of-2 multisig
 outputs, they transfer the coins into a contract where the coins can be
 spent either by waiting for a timeout or providing a hash preimage
 value. Ideally contract transactions will never be broadcast but their
 existence keeps all parties honest.
 M~ is miner fees, which we treat as a random variable, and ultimately
 set by whichever pre-signed RBF tx get mined. When we talk about the
 contract tx, we actually mean perhaps 20-30 transactions which only
 differ by the miner fee and have RBF enabled, so they can be broadcasted
 in sequence to get the contract transaction mined regardless of the
 demand for block space.
>>>
>>> The highest-fee version could have, in addition, CPFP-anchor outputs, like 
>>> those being proposed in Lightning, so even if onchain fees rise above the 
>>> largest fee reservation, it is possible to add even more fees.
>>> Or not.
>>> Hmm.
>>
>> I think RBF transactions are better because they ultimately use less
>> block space than CPFP.
>>
>> There 

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

[John Newbery via bitcoin-dev]

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 numbers you give are correct. An enormous
benefit that you don't mention (but Nadav and Lloyd do) is that
standardizing to a single tie-breaker for R points and public keys is much
simpler to explain and much easier for implementers and developers to
understand. I've explained the taproot proposals to many people through the
optech workshops and bitdevs meetups, and people are invariably confused by
which type of tie-breaker to use where. Absent a large performance benefit
for having different tiebreakers, I think this alone is good reason to
standardize to one tie-breaker.

2. Is it too late in the process to change? No. We're building things to
last years, hopefully decades. We should measure a hundred times and cut
once. A benefit of the long lead time of taproot is that as we get more
information, we can improve the proposal. Let's do that here. Nadav and
Lloyd have both written alternative implementations of taproot and are
happy to make this change. Presumably if this was going to cause serious
pain for any other implementer/developer they would have raised objections
by now.

Summary: We should change the proposal and implementation to use even
tie-breakers everywhere.

John #notoquadraticresiduetiebreakers Newbery

On Wed, Aug 12, 2020 at 7:49 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello all,
>
> The current BIP340 draft[1] uses two different tiebreakers for conveying
> the Y coordinate of points: for the R point inside signatures squaredness
> is used, while for public keys evenness is used. Originally both used
> squaredness, but it was changed[2] for public keys after observing this
> results in additional complexity for compatibility with existing systems.
>
> The reason for choosing squaredness as tiebreaker was performance: in
> non-batch signature validation, the recomputed R point must be verified to
> have the correct sign, to guarantee consistency with batch validation.
> Whether the Y coordinate is square can be computed directly in Jacobian
> coordinates, while determining evenness requires a conversion to affine
> coordinates first.
>
> This argument of course relies on the assumption that determining whether
> the Y coordinate is square can be done more efficiently than a conversion
> to affine coordinates. It appears now that this assumption is incorrect,
> and the justification for picking the squaredness tiebreaking doesn't
> really exist. As it comes with other trade-offs (it slows down signing, and
> is a less conventional choice), it would seem that we should reconsider the
> option of having the R point use the evenness tiebreaker (like public keys).
>
> It is late in the process, but I feel I owe this explanation so that at
> least the possibility of changing can be discussed with all information. On
> the upside, this was discovered in the context of looking into a cool
> improvement to libsecp256k1[5], which makes things faster in general, but
> specifically benefits the evenness variant.
>
>
> # 1. What happened?
>
> Computing squaredness is done through the Jacobi symbol (same inventor,
> but unrelated to Jacobian coordinates). Computing evenness requires
> converting points to affine coordinates first, and that needs a modular
> inverse. The assumption that Jacobi symbols are faster to compute than
> inverses was based on:
>
> * A (possibly) mistaken belief about the theory: fast algorithms for both
> Jacobi symbols and inverses are internally based on variants of the same
> extended GCD algorithm[3]. Since an inverse needs to extract a full big
> integer out of the transition steps made in the extgcd algorithm, while the
> Jacobi symbol just extracts a single bit, it had seemed that any advances
> applicable to one would be applicable to the other, but inverses would
> always need additional work on top. It appears however that a class of
> extgcd algorithms exists (LSB based ones) that cannot be used for Jacobi
> calculations without losing efficiency. Recent developments[4] and a
> proposed implementation in libsecp256k1[5] by Peter Dettman show that using
> this, inverses in some cases can in fact be faster than Jacobi symbols.
>
> * A broken benchmark. This belief was incorrectly confirmed by a broken
> benchmark[6] in libsecp256k1 for the libgmp-based Jacobi symbol calculation
> and modular inverse. The benchmark was repeatedly testing the same constant
> input, which apparently was around 2.5x faster than the average speed. It
> is a variable-time algorithm, so a good variation of inputs matters. This
> mistake had me (and probably others) convinced for years that Jacobi
> symbols were amazingly fast, while in reality they were 

[bitcoin-dev] Time to lower minrelaytxfee ?

[Dan Bryant via bitcoin-dev]

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 parity with the last reduction, we would
need to reduce minrealytxfee to 22 sat/vKB, though an even more
conservative reduction to 100 or 50 sat/vKB would be welcome.

With the growing adoption of LN, there is a need for ultra-low-fee
on-chain TXNs.  Having these queue and confirm overnight, or even
waiting until the Sunday lull would still probably be welcome to many
users.  The fact that the mempool is going empty at least every week
indicates that miners have not reached the floor of what they are
willing to mine.

About 2 years ago there was a PR (#13922) to try to make a reduction
from 1000 to 200 sat/vkB.  It was widely accepted but the submitter
eventually closed it in favor of PR #13990.

If minrelaytxfee is already parameterized and configurable in
bitcoin.conf, how could it be detrimental to operation of a node to
change the default?

References:

* 
https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
* https://github.com/bitcoin/bitcoin/pull/13922
* https://github.com/bitcoin/bitcoin/pull/13990
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

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, Anthony Towns via bitcoin-dev 
>  wrote:
> 
> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev 
> wrote:
>> In thinking about the mechanism used there, I thought it would be helpful to
>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>> messages received before a VERACK.  A draft of my proposal is available here
>> [2].
> 
> Rather than allowing arbitrary messages, maybe it would make sense to
> have a specific feature negotiation message, eg:
> 
>  VERSION ...
>  FEATURE wtxidrelay
>  FEATURE packagerelay
>  VERACK
> 
> with the behaviour being that it's valid only between VERSION and VERACK,
> and it takes a length-prefixed-string giving the feature name, optional
> additional data, and if the feature name isn't recognised the message
> is ignored.
> 
> If we were to support a "polite disconnect" feature like Jeremy suggested,
> it might be easier to do that for a generic FEATURE message, than
> reimplement it for the message proposed by each new feature.
> 
> Cheers,
> aj
> 
> ___
> 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