> Is there a missing word. "by giving a person.."? Not actually sure what
> you're getting at here but I suspect it's again tangential to this BIP
> discussion.

Correct on both points. I meant to say "giving a (txid:vout:privkey)" to a 
person as means of payment.

> So I think the limiting factor is in fact creating a standard that a 
> reasonable number
> of people could agree with (and I like operational definitions, so
> subjective as it is, I like the goal of "good/clear enough that it could
> be incorporated into something like BtcPayServer")

The problem with BtcPayServer (and a lot of similar software), is that it's not 
very unsuitable for any sender/receiver coinjoin due to it not having its own 
wallet. As I understand the basic architecture is just a fancy wrapper around 
bip32 address generation and monitoring the payment to those addresses. This 
means that adding support is not only a large code change, but it also entails 
a substantial change for merchants (you can't just have your payments flow into 
your trezor, but need to run a hot wallet)

But I strongly believe that bustapay is good enough _right now_ for 
BtcPayServer integration (which I'd happily contribute myself, if it wasn't for 
my unfamiliarity of the project and c#)

> But this relates back to my first "generic" point that you haven't
> addressed here - protocol versioning and the possibility of more than
> one option. Perhaps more realistic (debatable): have the current version
> be non-PSBT but with a plan to have a version bump with PSBT in future.
> Stuff like that. It seems crazy to actually long term reject it.

Adding backwards-compatible versioning at a later stage would be pretty trivial 
through either the URL or HTTP header (e.g  version=2)  and if breaking 
backwards compatible is desirable it can also easily been done (e.g. bump the 
bip21 or send an incompatible request/response). I don't see this as a problem 
at all, and I'm not rejecting it long-term, I just don't think it's 
particularly helpful to bikeshed now, when adoption is pretty much zero.

> I don't want to be that guy, but this was a central part of the proposal
> that came of the meetup last summer and is in Haywood's blogpost. I mean
> if you came up it with separately, then cool :) But I was there, that
> was established immediately as the right way of doing this to avoid a
> trivial attack.

Oh wow. had no idea. I saw the part about the receiver spamming the sender with 
a bunch of transactions, where only 1 of them are real and thought "ewww" and 
"came up" with the idea of a "template transaction" instead. I was always 
wondering why no one came up it, but now it makes sense. The transaction-spam 
stage was just an _additional_ layer of protection.

Ok, now I feel like an idiot =)  Thanks for letting me know.

> The counterargument is Laurent's statistics which I previously linked,
> suggesting that maybe 30% of txs violate this anyway, today. I'm not
> sure about that, will need more analysis; Core's SRD algo may be one
> reason, but anyway ... better to make things look like payments.

I think it's interesting, but I don't think it particularly matters. Avoiding 
UIH1 I think is pretty much irrelevant, as it'll likely just confuse any 
analysis into thinking the payment is the reverse of what it actually is. And 
wallets already don't care about violating UIH2(as a way to do implicit 
consolidation). If 30% of tx's are violating it, you can be pretty sure it 
means the _vast majority_ of wallets run coin selection in such a way that can 
violation UIH2.  Most wallets use a coin selection algorithm that you can 
approximate with:

while !enoughMoney {
    inputs += getAnotherInput();

and don't run a final pass that would prune superfluous inputs.  Even coinsayer 
(shill alert) which I believe runs the most advanced coin selection algorithms, 
will routinely and intentionally violate UIH2 when it's ideal (e.g. most 
classic case: when `consolidationFeeRate >= minFeeRate`).

I'm not trying to dismiss your analysis, as I find it interesting. I'm just 
against increasing the cognitive burden on implementations by mentioning all 
this stuff, when the truth is it (barely) matters.  If wallets routinely 
avoided UIH2 and making a UIH2 payment would "out" the transaction as much more 
likely to be a bustapay, then I'd definitely reconsider and provide a basic 
suggestion into how to try avoid it.

And like I said, I also think there's much more important things that go into 
"picking a contributed input" than just this.

> A last point, you also don't see value in being more explicit about
> simple things like transaction version and locktime? Even if you think
> these things should not be controlled, e.g. the protocol should allow
> either transaction version, then it'd be better to explicitly say so.

My intention was that wallets create a transaction exactly like they normally 
would do, and use that as the template transaction. The only time I wanted to 
be prescriptive was when it would increase the implementation complexity (e.g. 
being non-segwit compatible is a pain in the ass. So I'd rather just be "pure 
segwit only" transactions). But something like locktime makes no difference as 
long as the transaction is mempool eligible, so I'd rather just wallets do what 
they do anyway.

Although I think there should be a separate discussion on improving the 
uniformity of bitcoin transactions in general. The current state of affairs is 
really atrocious.


P.S. I know I come across as obstinate, but it's not really so. If you can come 
up with an alternative to bustapay with some traction, I'd love to get behind 
it and deprecate bustapay in favor of it. I just am pretty happy with the state 
of bustapay and it's status a sort of "MVP of pay2endpoint", and unless the 
argument is in the form: "We'd love to support it, but in order to do so we'd 
need X" I'm probably going to disagree.
bitcoin-dev mailing list

Reply via email to