Adam Gibson [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-02-15 to 2019-08-02
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:19:54

- reply

📅 Original date posted:2019-08-02
📝 Original message:reposted due to wrong email address:
I'd just like to repeat something I said years ago but is undoubtedly lost
now:
>
> ### Today's low cost for sybil attacks
>
> A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a
> Market for Anonymity.” (2016).] calculates the requirement of such a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
>
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
>
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
>
I criticised this point from the Moser paper at the time, in particular
because it was the headline grabbing result and in my opinion was only half
the truth, at best:
The $32K figure came from the assumption that swamping the bottom of the
order book (in other words, making lots of bots offering prices lower than
all the other bots) would lead to taking most of the join volume.
At the time, this was true and false to some extent: it was true that the
default order choosing algorithm was exponentially weighted to lower fees.
But it was also true even then that Takers could simply manually choose any
counterparty bots they liked (-P).
Also at the time I complained that it was trivial to implement other order
choosing algorithms, in particular I advocated (for its simplicity) "choose
randomly under a user specified maximum fee", and indeed since the paper we
have implemented that algorithm and it's now the default.
Note that this algorithm is the crudest variant of what was loosely called
"quantization" in this discussion between belcher and gmaxwell on the topic
some years ago:
https://github.com/JoinMarket-Org/joinmarket/issues/14#issuecomment-143509788
To me the crucial point is that the Taker's price sensitivity should not be
too large, although of course it cannot be zero!
So independent of changes in the makeup of the users of Joinmarket, that
analysis from 2016 was in my opinion a bit skewed at the time, and
completely wrong today.
None of this is a critique of the fidelity bonds idea, since the Sybil
threat is real in any case (see issue 693 as mentioned), but price-based
Sybilling is less effective than it seems based on that.
I'll continue my thoughts on fidelity bonds, for what they're worth, in the
active thread:
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/371
(for those not in the know, Joinmarket-Org/joinmarket-clientserver is the
active repo, not Joinmarket-Org/joinmarket).
Adam Gibson / waxwing / AdamISZ
On Thu, Jul 25, 2019 at 3:18 PM Chris Belcher via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> JoinMarket[1] can be sybil attacked today at relatively low cost which
> can destroy its privacy. Bitcoins can be sacrificed with burner outputs
> and time-locked addresses (also called fidelity bonds), and this can be
> used to greatly improve JoinMarket's resistance to sybil attacks.
>
> With real-world data and realistic assumptions we calculate that under
> such a fidelity bond system an adversary would need to lock up
> 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner
> addresses to have a good chance of sybil attacking the system if it were
> added to JoinMarket.
>
> This increased resistance to sybil attacks would most likely cause
> coinjoin fees to rise. I think the added cost is worth it for the
> greatly improved privacy, because today miner fees are the biggest cost
> to JoinMarket takers not coinjoin fees which are very low. Users should
> definitely share their opinion on fees after reading the document.
>
> ## Introduction
>
> JoinMarket creates a market for coinjoins, allowing anyone to create
> equal-amount coinjoins for any amount they want at any time they want.
> In return they pay a fee for the liquidity made available to them. The
> project has existed since 2015 and has probably created hundreds of
> thousands of coinjoins since then. Today there is available liquidity
> for creating coinjoins with amounts up to about 400 btc per coinjoin
> output.
>
> ### Sybil attacks
>
> JoinMarket, like many other schemes where participants are free to
> anonymously enter, can be targetted by sybil attacks. In JoinMarket this
> would work by an attacker running lots of maker bots which attempt to be
> all the makers in every coinjoin. If successful the attacker would have
> enough information unmix every coinjoin.
>
> One way to solve the problem of sybil attacks is centralization. For
> example coinjoins could be constructed on a centralized server. Then
> random anonymous participants cant sybil attack because they can't
> control the coinjoin construction, but this comes at the cost that the
> server can sybil attack very easily. So this solution is probably a bad
> tradeoff.
>
> In general, sybil attacks are solved by making them expensive. For
> example, bitcoin mining resists sybil attacks because it requires a
> provable sacrifice of electricity to mine. A bitcoin user can calculate
> the actual monetary value that an attacker must spend in order to
> reverse their transaction.
>
> Likewise in JoinMarket such a sybil attack is not free either as the
> attacker needs to own enough bitcoins to run enough maker bots for all
> the coinjoins.
>
> ### Today's low cost for sybil attacks
>
> A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a
> Market for Anonymity.” (2016).] calculates the requirement of such a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
>
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
>
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
>
> Apart from the cost to sybil attack being low, there is also the odd
> situation that smaller coinjoin amounts receive less sybil protection
> than large ones. It costs 100x less to sybil attack a transaction of 0.1
> btc than one of 10 btc. Why should smaller amounts receive less
> sybil-resistance and therefore less privacy?
>
> ### Liquidity
>
> When creating this project, it was expected that many more people would
> enter the market as makers and so the cost of a sybil attack would be
> very high. That has not happened. One reason is that everyone who wants
> to create a coinjoin is able to even for large amounts. The fundamental
> problem is that takers are paying-for and getting liquidity, but not
> necessarily sybil-resistance.
>
> Another smaller reason for the low cost of sybil attacks is that many
> people don't want to store too many bitcoins on an computer connected to
> the internet.
>
> What is needed is a way to increase the cost of running in a maker in a
> way that retains the anonymity and is attractive to long-term holders of
> bitcoin. This can be done using time-locked addresses.
>
> ## Fidelity bonds
>
> In bitcoin, a fidelity bond [3] is a mechanism where bitcoin value is
> deliberately sacrificed to make a cryptographic identity expensive to
> obtain. The sacrifice is done in a way that can be proven to a third party.
>
> A way to create a fidelity bond is to burn an amount of bitcoins by
> sending to a OP_RETURN output. Another kind is time-locked addresses
> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
> sacrificed is time rather than money, but the two are related because of
> the time-value-of-money.
>
> Under this system, makers would sacrifice an amount of bitcoins and
> publish a proof along with their coinjoin offers. Takers would choose
> maker offers based on the sacrificed amount (as well as other factors),
> knowing that a sybil attacker would also have to sacrifice a certain
> amount of coins in order to unmix the taker's coinjoins. The sacrifice
> would be an objective measurement that can't be faked and which can be
> verified by anybody (just like, for example PoW mining)
>
> Note that a long-term holder (or hodler) of bitcoins can buy time-locked
> fidelity bonds essentially for free, assuming they never intended to
> transact with their coins much anyway. A long-term holder probably won't
> want to attack a system like JoinMarket which makes his own investment
> coins more private and more fungible.
>
> ### Fidelity bonds in cold storage
>
> The private keys of fidelity bonds can be kept offline. Signatures
> potentially only need to be made when the timelock expires (every 6
> months for example), or only once in the case of OP_RETURN burned coins.
> This allows JoinMarket's sybil resistance to increase without the hot
> wallet risk.
>
> Burned coin signatures should still have a lifetime, in case the private
> key associated with the IRC nick (which is online) is stolen, so that
> the thief of that privkey can't impersonate the maker indefinitely. The
> signature linking the burned coins and IRC nick could expire after
> perhaps 6 months.
>
> ### Anonymity
>
> Under this scheme makers would need to publish the transactions of their
> fidelity bonds to the entire world. Those transactions could be subject
> to blockchain analysis. So before makers do this they should make sure
> their coins are anonymous (possibly by mixing with JoinMarket). Also if
> they ever want to use their coins for something else apart from fidelity
> bonds they should mix them.
>
> ### Value of a fidelity bond
>
> See the other document (Financial mathematics of joinmarket fidelity
> bonds)[4] for a formula expressing the value of a fidelity bond.
>
> The value of a fidelity bond made by sending V bitcoins to a burner
> address is:
>
> V^2
>
> The amount of bitcoins is squared to get the fidelity bond value. This
> has the effect that economic-rational makers have a strong incentive to
> lump up all their coin sacrifices together into one maker bot, not to
> split it up over several bots.
>
> The value of a fidelity bond made by locking up V bitcoins in a
> time-locked address for time period T is:
>
> V^2 (exp(rT) - 1)^2
>
> To get an idea of the numbers, if we burn 2 btc then the value of the
> fidelity bond is 4 BTC^2. If we lock up 100 BTC for one year, and have a
> bitcoin interest rate r = 0.001 (0.1%) per year, then the value of that
> fidelity bond is 0.01 BTC^2 which is the same as burning 0.1 BTC. That
> is a relatively small valued bond. It can be increased by locking up
> more bitcoins for longer (up to and including permanant locking via a
> burner transaction).
>
> ## Taker algorithm for choosing makers
>
> I suggest the following taker peer choosing algorithm: obtain the list
> of offers and discard offers which the taker's user deems are too
> expensive. One of the remaining offers is randomly chosen with weighting
> determined by the fidelity bond value. Once an offer is chosen it is
> removed from the list, and another offer is again randomly chosen, this
> is repeated until the taker has chosen the desired number of
> fidelity-bonded maker's offers.
>
> Some people run makers not for profit but for their own privacy.
> Therefore not all makers should be required to have bonds, because such
> privacy-makers are useful to include in coinjoins too. We could have
> taker allow say, an eighth (12.5%), of their coinjoin peers to be makers
> without bonds. They can be chosen randomly from the orderbook without
> any weighting based on fidelity bond values. Of course these are easy to
> fake by an adversary so they dont contribute much to sybil resistance.
>
> ### Cost of sybil attacks
>
> See the other document (Cost of sybil attacks) for discussion and
> calculations on the sybil resistance given by the above maker-choosing
> algorithm.
>
> It can be calculated that the fidelity bond system dramatically
> increases the cost of a sybil attack. With real-world data and realistic
> assumptions we can calculate that a sybil attacker would need to lock up
> 30,000-80,000 bitcoins for 6 months, or send 45-120 bitcoins to burner
> addresses to have a good chance of attacking the system by being all the
> counterparties in everyone's coinjoin.
>
> ## Effect of fidelity bonds on CoinJoin fees
>
> Someone might ask "why would anyone lock up coins for months or more,
> let alone burn coins forever, just to run a maker bot". The only way
> this would even happen is if makers can generate a higher income that
> justifies the fidelity bond sacrifice. That higher income can only come
> from taker's coinjoin fees (or possibly coinswap fees one day). We can
> expect that makers with higher valued fidelity bonds will demand higher
> coinjoin fees. So a big question is whether takers will accept paying
> higher coinjoin fees. I think they will, because right now coinjoin fees
> are only 10-1000 satoshi, and a far biggest cost of coinjoins is the
> miner fee not the coinjoin fee. I'm pretty sure takers will recognize
> that they get what they pay for, and that additional privacy is well
> worth the cost. Any other takers reading this should definitely let me
> know what they think.
>
> ## Technical ideas
>
> JoinMarket's wallet could also create time-locked addresses. Locktimes
> should be fixed to be midnight on the first day of each month, then each
> public key corresponds to 12 addresses per year (1200 addresses per
> century) which is very practical to all be monitored as watch-only
> addresses. These wallets can be created offline and could safely hold
> time-locked bitcoins.
>
> The timelocked addresses public key can be used to sign an IRC nickname
> proving that the nickname is the real owner of the TXO. OP_RETURN
> outputs used for burning coins can include a pubkey hash used for the
> same thing.
>
> We don't want the cold storage keypairs to be held online. We can design
> the system that the time-locked address keypair is held offline but it
> signs another key pair which is held online. Every time the IRC bot
> connects it can use this intermediate keypair to sign the IRC nickname
> proving ownership. The signature from the time-locked address to the
> intermediate keypair can be made to have an expiry date (for example 6
> months). This all means that the time-locked bitcoins can be held
> offline but still be used to prove ownership of an IRC nickname.
>
> The existance of the UTXO of a time-locked coin can be proved by
> revealing the TXID and vout, which full nodes can use to query the UTXO
> set to check that the coin exists. SPV clients would need a merkle proof
> as well. Burned coins and spent time-locked coins could have their
> existence proved by sharing the transaction which created them along
> with a block height and transaction position for an unpruned node, or a
> merkle proof for a pruned node or SPV client. Note that from the point
> of view of a pruned node, a merkle proof is a fully-verified proof of
> existance of a transaction. It is not a proof with just SPV-security.
>
> ## Links / References
> [1] https://github.com/JoinMarket-Org/joinmarket-clientserver
> [2] https://github.com/JoinMarket-Org/joinmarket/issues/693
> [3] https://en.bitcoin.it/wiki/Fidelity_bonds
> [4] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
> [5]
>
> https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybil-attacks
> [6] First ever mention of fidelity bonds I found. The idea is basically
> invented by Peter Todd: https://bitcointalk.org/index.php?topic=134827.0
> [7] Old idea for combining fidelity bonds with mixers:
> https://bitcointalk.org/index.php?topic=172047.0
> [8] Suggestion that is very close to the fidelity bonds idea. He talks
> about requiring a deposit from makers, but nobody is able to come up
> with a way to make such a deposit decentralized and trustless:
>
> https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=1
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190802/ccfbca83/attachment-0001.html>

2023-06-07 18:16:06

- reply

📅 Original date posted:2019-01-28
📝 Original message:ZmnSCPxj, thanks, responses inline.
On 28. 01. 19 5:14, ZmnSCPxj wrote:
> Good morning Ryan and Adam,
>
>> [UIH2 snipped]
>
> Perhaps I am being naive, but I seem, the B2EP and similar do not need to worry about UIH2.
>
> From the github discussion:
>
>> "UIH2": one input is larger than any output.
> .
> I.e. there exists an input, for all outputs, input > output
> To avoid this, we should ensure that, for all inputs, there exists an output, input < output.
>
> From the proposal BIP:
>
>> The receiver then adds one of his own inputs (known as the "contributed input") and increase the output that pays himself by the contributed input amount.
>
> Suppose the original transaction avoids the UIH2 (i.e. for all inputs, there exists an output, input < output).
> The single added input will also avoid the UIH2, since the contributed output value is added to the receiver output, thereby ensuring that contributed input < output.
>
Yes, I had noted this (see link below).
> Suppose the original transaction does not avoid the UIH2.
> The receiver adding their own contributed input would then have a chance that the addition on the output will now cause the final transaction to avoid the UIH2, since the sum of the receiver amount and the contributed input may now exceed the largest sender input.
(Just to note (see link below) what I'm sure you're aware of but a
reader might forget: if the change output that the sender provided is
larger than the payment amount, the above won't happen).
> But since there are more transactions that avoid the UIH2 than not avoid UIH2, the increased probability of now avoiding the UIH2 will lead to a greater anonymity set (especially for the sender, whose coin selection algorithm might have a consistent bias that makes it create transactions that trigger UIH2).
>
> So it seems to me that the simple solution, i.e. sender uses standard coin selection algorithms already in use today, and receiver does not do any UIH2 checks at all, would be an improvement in both privacy and implementation simplicity.
>
> Regards,
> ZmnSCPxj
>
Really good point, and I think your argument is reasonable, if not
watertight. (Just in case you missed it I tried to outline an algo to
let the receiver avoid UIH2 on best effort basis here:
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2799709).
Although I ~ sorta agree, there is a slight counterargument: receiver is
adding utxos, so in the absence of any transaction inspection you're
creating a different distribution than one gets from existing wallet
selection algos. For example:
Note that the most likely/desirable/considered use case may be a
merchant use case (after all, who receives coins most frequently? in
theory, people selling stuff), and it is highly plausible that they
might concentrate larger and larger sums into utxo(s) via use of
PayJoin. Completely mismatched input sizes could be a problem, it's
debatable, and it's also debatable whether it can be avoided, but what I
don't quite buy is that this issue can just be ignored.
And I'm reminded that a related point is made by belcher in the gist
comment thread iirc (after we discussed it on IRC): over time a
"PayJoin-only" merchant doing the simplest thing - using a single utxo
over and over again, will concentrate more and more funds into it, and
inevitably violating UIH2 in an increasingly dramatic fashion
(contributing a 100BTC utxo to a 0.1BTC payment etc.). Suggesting it's
better if there's a mix of payjoin/non-payjoin.

2023-06-07 18:16:03

- reply

📅 Original date posted:2019-01-27
📝 Original message:On 27. 01. 19 8:36, rhavar at protonmail.com wrote:
> Thanks Adam,
>
> I have fixed the mistakes you have pointed out: https://github.com/bitcoin/bips/pull/754
>
> Thanks for the detailed look!
>
>> but its virtue of steganographic hiding means only minimal uptake
>> is still enormously interesting and worth pursuing; that's my current feeling.
>
> I very much agree =) I really think anything that (silently) breaks the assumption of common ownership of transaction inputs offers outsized benefits for the whole ecosystem.
>
> One other idea I have is (way) better support for moving utxo's between wallets. The least controversial use case is moving funds between wallets you own. Like I might want to move *specific* utxo's from/to my joinmarket wallet, but not create a (privacy losing / expensive) transaction. Both core and joinmarket fail at this at a practical point of view.
(tangential, but yes coin control in JM is an obviously necessary
feature and will be done, I just don't have time).
>
> Like imho it'd be pretty cool having a standardized format for (txid:vout:privatekey) with wallets showing it as "External UTXO" and preferentially spending it (and wallet not automatically importing any other utxo from that address).
>
> Taken a bit further (this is the part which everyone hates) you could send someone money (or withdraw it from a service) by giving a person. It's not generally useful (for obvious reasons), but there's a lot of cases I think it's super cool.
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.
>
> ---
>
> Getting back on topic, without trying to do a point-by-point reply, I agree with pretty much everything you said but I am reluctant to make any changes.
>
> I don't meant to be obtuse or anything, but I strongly believe the limiting factor to adoption to all these protocols is actually just getting people to implement it. I made multiple implementations of bustapay from both the sending/receiving end, so I could try develop the easiest to implement system that is still practical.
You know, there's considerable evidence to the contrary, I'd argue: this
idea *has* been implemented already three times: by yourself, by myself
and by Samourai. And in fully incompatible ways :) 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")
>
> For instance I like PSBT and it's nice in theory. I actually had an original implementation using it, which is how I found some bugs in the core and golang version of PSBT). But in practice it's hugely overkill and significantly increases the implementation complexity complexity and is poorly supported. Switching to just a raw transaction actually made everything easier. (And that's not to criticise PSBT, I would definitely want to use it in other contexts).
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.
>
> Anyway, a big motivation for me even writing it as a BIP was to formalize my little anti-DOS trick of privately creating a "template transaction" which can just be dumped on the network as punishment. So if nothing else, hopefully I'll have demonstrated it's a pretty practical way of doing things.
>
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.
What might have confused you is all that stuff about multiple candidates
and even ZKP approaches - those were just extra ideas about making it
really secure at large scale; but those ideas don't quite meet the goal
(for various reasons); well, arguably. The basic anti-DOS of an initial
non-coinjoin was sorta central.
(Also I'm noting you didn't respond to my critique of your "always use
the same contributions" defence; I mean, probably that's fine, it was
only really saying it isn't perfect. Was just curious to hear
your/others thoughts on it).
> --
>
> Also your analysis on "Unnecessary Input Heuristic" is pretty cool, but I also don't like telling people to "avoid the UIH2" without providing the actual algo they should use. But really I think it's better off in a sort of article "how to pick contributed inputs" or something, as while it's nice it's not a huge deal and there's a lot of debatable tradeoffs that can/should be used. For instance the implementation I wrote for bustabit.com currently just heavily biases tainted inputs (e.g. ones associated with address reuse).
>
Good point about algo.
I wrote my best effort at a procedure here:
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2799709
I asked for comments on it but got none back so far (gists are terrible
for this unfortunately, perhaps I'll have more luck on the list).
I would argue that this issue *should* be mentioned on the BIP. A *huge*
part of what makes PayJoin/BustaPay of interest is the steganographic
feature, if you don't pay attention to this then it doesn't look like a
payment (caveat.-->).
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.
It doesn't hurt to prompt an implementer to do this; whether it's
feasible in that specific wallet situation or not is up to them; whether
they want to go hog wild and control percentages of UIH1 and UIH2 and
whatnot is there business, or they can totally ignore it - but without
it being mentioned in the BIP, they may not even think of it.
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.
>
>
> -Ryan
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, January 25, 2019 6:47 AM, Adam Gibson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Ryan and list,
>> I want to add some commentary to this (BIP79) to see if we can get
>> further in standardizing this idea.
>>
>> When I first mulled it over I thought it too impractical, but its virtue
>> of steganographic hiding means only minimal uptake is still enormously
>> interesting and worth pursuing; that's my current feeling. I've offered
>> more detailed thoughts in my blog post[1] (def not required reading here).
>>
>> Both Joinmarket and Samourai have started implementing this kind of
>> transaction. And while that's interesting experimentally, some kind of
>> cross-wallet standard would be helpful, albeit there some differences
>> between that and the merchant/centralized service use-case.
>>
>> We might imagine as a concrete goal for this BIP to create something
>> that would be acceptable for inclusion into a project like BTCPayServer,
>> so that it could be used in a realistic use case by smaller bitcoin
>> accepting merchants.
>>
>> Comments to the BIP[2] as follows, with generic comments first, and then
>> specific comments for existing points in the BIP:
>>
>> [1] https://joinmarket.me/blog/blog/payjoin
>> [2] https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki
>>
>> Generic comments
>>
>> ==================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
>>
>> - Protocol versioning. Since inevitably (even if only merchants), this
>> must be implemented by multiple wallets to be useful, the communication
>> protocol will need versioning (for example i have in my
>> simple/experimental Joinmarket PayJoin that sender sends min and max
>> supported version and receiver responds with a chosen protocol version
>> so we can update). I do understand that as a client-server model can
>> apply here, we can ditch a lot of the complexities around network/p2p
>> interaction, but this much at least seems necessary.
>>
>> - Although it has its logic, I don't think "Bustapay" is a good name for
>> this protocol. I prefer "PayJoin" which is neutral sounding and
>> self-descriptive. Needless to say this is not a hill I intend to die on.
>>
>> - PSBT/BIP174. I realise this has already been discussed, but this is a
>> good example of what this standardisation was designed for, so I'd be
>> against not including it, even given the reality that, as you correctly
>> observe, it is not yet implemented in the majority of wallets and
>> libraries. One way round that is to make it optional (possibly combined
>> with above point about versioning). Note that for example you were
>> observing the necessity to check the sequence number was unchanged; that
>> would be encapsulated by checking equality of PSBT Input objects/fields.
>> While one can make such software architecture arguments, the really
>> fundamental point is the need for standards for x-wallet compatibility.
>>
>> - Version, Locktime: Perhaps this is not needed; in a peer to peer
>> wallet scenario I think there might be logic in trying to get cover
>> traffic of (Core, Electrum, others), say, by using
>> last-block-locktime-mostly, as they do. Version should be 2 and sequence
>> is a function of your suggestion to use BIP125. Worth noting that BIP125
>> is not currently widely used on the network, though (see
>> https://p2sh.info/dashboard/db/replace-by-fee?orgId=1). For this reason
>> it should perhaps be explicitly only optional.
>>
>> - Avoidance of non-payment "Unnecessary Input Heuristic" (1, 2). For
>> reference, see the definition here
>> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539
>> and some data here
>> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2800791
>> (whole comment thread may be of interest) - note this UIH name is afaik
>> Chris Belcher's invention, it seems useful as a categorisation.
>> So, it seems that UIH2 is more important to avoid; while some more
>> sophisticated wallet coin selection algorithms may occasionally pick
>> an input set where one input is larger than any output, most won't, and
>> some in particular never will. So I think the text here should indicate
>> that *the receiver's contributed input(s) SHOULD be chosen to avoid
>> triggering the UIH2 heuristic where possible, so that the final payjoin
>> transaction is maximally plausible as an ordinary payment" or similar.
>> UIH1 is a nice-to-have (meaning the plausibility extends to two
>> different (both wrong) payment amounts, but it may not be necessary to
>> mention it in the BIP.
>>
>> Specific comments
>> =================
>>
>>
>>>> ====Step 4. Receiver validates, re-signs, and propagates on the
>>
>> bitcoin network====
>>
>> I believe this should say "Sender" not Receiver. Also for the next
>> sentence, s/receiver/sender/:
>>
>>>> The receiver MUST validate the ''partial transaction'' was changed
>>
>> correctly and non-maliciously (to allow using potentially untrusted
>> communication channels), re-sign its original inputs and propagate the
>> final transaction over the bitcoin network.
>>
>> Your very correct highlighting of the attack vector of "receiver gives
>> sender other inputs belonging to sender to unwittingly sign (described
>> below), should be highlighted here, perhaps with the phrase "re-sign its
>> ORIGINAL inputs" (only!)".
>>
>>>> When the sender is creating a "template transaction" it is done
>>
>> almost identically to creating a normal send, with the exception that
>> only segwit inputs may be used. The sender is also encouraged to use a
>> slightly more aggressive feerate than usual as well as BIP125 (Opt-in
>> Full Replace-by-Fee Signaling), but neither is strictly required.
>>
>> "slightly more aggressive feerate than usual" - this I understand is to
>> make up for receiver contributed utxo, OK.
>>
>> "only segwit inputs" - it certainly makes things simpler. One can work
>> with non-segwit inputs but especially considering (as mentioned below)
>> we really ought to "MUST" the part about matching input types, I tend to
>> agree that non-segwit should be disallowed.
>>
>>>> The receiver must add at least one input to the transaction (the
>>
>> "contributed inputs"). If the receiver has no inputs, it should use a
>> 500 internal server error, so the client can send the transaction as per
>> normal (or try again later).
>>
>> Would it not be much simpler for the server to return a different
>> (non-error) response indicating that it will broadcast the template tx
>> in this case?
>>
>>>> Its generally advised to only add a single contributed input, however
>>
>> they are circumstances where adding more than a single input can be useful.
>>
>> I don't see a good reason to advise the use of only 1 input? (but this
>> will also connect with the above generic comment about "UIH"). I guess
>> it's because of your approach to fees. I'd prefer not to create a
>> limitation here.
>>
>>>> To prevent an attack where a receiver is continually sent variations
>>
>> of the same transaction to enumerate the receivers utxo set, it is
>> essential that the receiver always returns the same contributed inputs
>> when it's seen the same inputs.
>>
>> This is an approach to avoiding this problem which has the virtue of
>> simplicity, but it seems a little problematic. (1) You must keep a
>> mapping of proposed payment utxos to one's proposed contributed input
>> utxos, but (2) how should this be updated if you need to spend the
>> contribution mentioned in (1)? Ironically use of payjoin exacerbates
>> this issue, because it results in a smaller number of utxos being held
>> by the receiver at any one time :) All this considered, I still see the
>> value in your approach, but it might end up with a re-attempted payment
>> being rejected. Certainly the more complex suggested solutions coming
>> out of the summer 2018 coinjoin workshop aren't as practical as this,
>> and may be overkill for small merchants/receivers.
>>
>>>> It is strongly preferable that the receiver makes an effort to pick a
>>
>> contributed input of the same type as the other transaction inputs if
>> possible.
>>
>> I have also thought about this and you could reasonably argue this
>> should be a MUST section in the BIP, that is, if the receiver cannot use
>> inputs of the same type, he should fall back to the template
>> transaction. A mixed-input payjoin/coinjoin is essentially
>> near-perfectly identifiable as such (there is almost zero other usage of
>> multi-type-input transactions), which is a very different thing than a
>> non-identifiable payjoin transaction. That may or may not be OK to the
>> sender. This is debatable though, for sure.
>>
>>>> After adding inputs to the transaction, the receiver generally will
>>
>> want to adjust the output that pays himself by increasing it by the sum
>> of the contributed input amounts (minus any fees he wants to
>> contribute). However the only strict requirement is that the receiver
>> must never add or remove inputs, and must not ever decrease any
>> output amount.
>>
>> "must never add or remove inputs" - did you mean "must never remove
>> inputs"? he surely has to add one! Or, perhaps you mean he must not
>> alter the list of inputs provided by the sender (in which case it should
>> be clarified).
>>
>> "must not decrease any output amount" - I initally disagreed with this
>> but it is a better option than the one I currently chose in Joinmarket
>> payjoin (sender pays all fee as long as receiver utxos are not too
>> much). So this means that the receiver either consciously chooses to not
>> increase the fee, meaning the fee rate may be a bit low (hence your
>> earlier comment about being generous, got it), or contributes via the
>> payout amount. I guess the latter might break merchant software
>> expecting to have amount output fixed and fees determined by change.
>>
>> Regards,
>> Adam Gibson/waxwing
>>
>> On 30. 08. 18 22:24, Ryan Havar via bitcoin-dev wrote:
>>
>>> I've just finished writing an implementing of this, and extremely happy
>>> with how it turned out. So I'd like to go and try go down the path of
>>> more formally describing it and getting some comments and ultimately
>>> encourage its wide-spread use.
>>> ==Abstract==
>>> The way bitcoin transactions are overwhelming used is known to leak more
>>> information than desirable. This has lead to fungibility concerns in bitcoin
>>> and a raise of unreasonably effective blockchain analysis.
>>> Bustapay proposes a simple, practical way to bust these assumptions to
>>> immediate
>>> benefit of the sender and recievers. Furthermore it does so in such a
>>> way that
>>> helps recievers avoid utxo bloat, a constant problem for bitcoin merchants.
>>> ==Copyright==
>>> This BIP is in the public domain.
>>> ==Motivation==
>>> One of the most powerful heuristic's employed by those whose goal is to
>>> undermine
>>> bitcoin's fungiblity has been to assume all inputs of a transaction are
>>> signed by
>>> a single party. In the few cases this assumption does not hold, it is
>>> generally
>>> readibly recognizable (e.g. traditional coinjoins have a very obvious
>>> structure,
>>> or multisig outputs are most frequently validated onchain).
>>> Bustapay requires no changes to bitcoin and creates bitcoin transactions
>>> that are
>>> indistinguishable from normal ones.
>>> It is worth noting that this specification has been intentionally kept
>>> as simple
>>> as possible to encourage adoption. There are almost an endless amount of
>>> extensions
>>> possible but the harder the implementation of clients/server the less
>>> likely it
>>> will ever be done. Should bustapay enjoy widespread adoption, a "v2"
>>> specification
>>> will be created with desired extensions.
>>> ==Specification==
>>> A bustapay payment is made from a sender to a receiver.
>>> Step 1. Sender creates a bitcoin transaction paying the receiver
>>> This transaction must be fully valid, signed and all inputs must use
>>> segwit. This transaction is known as the "template transaction". This
>>> transaction must not be propagated on the bitcoin network.
>>> Step 2. Sender gives the "template transaction" to the receiver
>>> This would generally be done as an HTTP POST. The exact URL to submit it
>>> to could be specified with a bip21 encoded address. Such as
>>> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit
>>> and the HTTP body should be the raw transaction hex encoded as text.
>>> Step 3. Receiver processes the transaction and returns a partially
>>> signed coinjoin
>>> The receiver validates the transaction is valid, pays himself and is
>>> eligible for propation. The receiver then adds one of his own inputs
>>> (known as the "contributed input") and increase the output that pays
>>> himself by the contributed input amount. Doing so will invalidate the
>>> "template transaction"'s original input signatures, so the sender needs
>>> to return this "partial transaction" back to the receiver to sign. This
>>> is returned as a hex-encoded raw transaction a response to the original
>>> HTTP POST request.
>>> Step 4. Receiver validates, re-signs, and propagates on the bitcoin network
>>> The receiver is responsible in making sure the "partial transaction"
>>> returned by the sender was changed correctly (it should assume the
>>> connection has been MITM'd and act accordingly), resign its original
>>> inputs and propagates this transaction over the bitcoin network. The
>>> client must be aware that the server can reorder inputs and outputs.
>>> Step 5. Receiver observes the finalized transaction on the bitcoin network
>>> Once the receiver has seen the finalized transactions on the network
>>> (and has enough confirmations) it can process it like a normal payment
>>> for the sent amount (as opposed to the amount that it looks like on the
>>> network). If the receiver does not see the finalized transaction after a
>>> timeout will propagate the original "template transaction" to ensure the
>>> payment happens and function a strong anti-DoS mechanism.
>>> === Implementation Notes ===
>>> For anyone wanting to implement bustapay payments, here are some notes
>>> for receivers:
>>>
>>> - A transaction can easily be checked if it's suitable for the mempool
>>> with testmempoolaccept in bitcoin core 0.17
>>>
>>> - Tracking transactions by txid is precarious. To keep your sanity make
>>> sure all inputs are segwit. But remember segwit does not prevent txid
>>> malleability unless you validate the transaction. So really make sure
>>> you're using testmempoolaccept at the very least
>>>
>>> - Bustapay could be abused by a malicious party to query if you own a
>>> deposit address or not. So never accept a bustapay transaction that pays
>>> an already used deposit address
>>>
>>> - You will need to keep a mapping of which utxos people have showed you
>>> and which you revealed. So if you see them again, you can reveal the
>>> same one of your own
>>>
>>> - Check if the transaction was already sorted according to BIP69, if so
>>> ensure the result stays that way. Otherwise probably just shuffle the
>>> inputs/outpus
>>>
>>>
>>> Notes for sending applications:
>>>
>>> - The HTTP response must not be trusted. It should be fully validated
>>> that no unexpected changes have been made to the transaction.
>>>
>>> - The sender should be aware the original "template transaction" may be
>>> propagated at any time, and in fact can intentionally be
>>> done so for the purpose of RBF as it should have a slightly higher fee
>>> rate.
>>>
>>>
>>> == Credits ==
>>> The idea is obviously based upon Dr. Maxwell's seminal CoinJoin
>>> proposal, and reduced scope inspired by a simplification of the "pay 2
>>> endpoint" (now offline) blog post by blockstream.
>>> -Ryan
>>>
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

2023-06-07 18:16:02

- reply

📅 Original date posted:2019-01-25
📝 Original message:Ryan and list,
I want to add some commentary to this (BIP79) to see if we can get
further in standardizing this idea.
When I first mulled it over I thought it too impractical, but its virtue
of steganographic hiding means only minimal uptake is still enormously
interesting and worth pursuing; that's my current feeling. I've offered
more detailed thoughts in my blog post[1] (def not required reading here).
Both Joinmarket and Samourai have started implementing this kind of
transaction. And while that's interesting experimentally, some kind of
cross-wallet standard would be helpful, albeit there some differences
between that and the merchant/centralized service use-case.
We might imagine as a concrete goal for this BIP to create something
that would be acceptable for inclusion into a project like BTCPayServer,
so that it could be used in a realistic use case by smaller bitcoin
accepting merchants.
Comments to the BIP[2] as follows, with generic comments first, and then
specific comments for existing points in the BIP:
[1] https://joinmarket.me/blog/blog/payjoin
[2] https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki
Generic comments
============
* Protocol versioning. Since inevitably (even if only merchants), this
must be implemented by multiple wallets to be useful, the communication
protocol will need versioning (for example i have in my
simple/experimental Joinmarket PayJoin that sender sends min and max
supported version and receiver responds with a chosen protocol version
so we can update). I do understand that as a client-server model can
apply here, we can ditch a lot of the complexities around network/p2p
interaction, but this much at least seems necessary.
* Although it has its logic, I don't think "Bustapay" is a good name for
this protocol. I prefer "PayJoin" which is neutral sounding and
self-descriptive. Needless to say this is not a hill I intend to die on.
* PSBT/BIP174. I realise this has already been discussed, but this is a
good example of what this standardisation was designed for, so I'd be
against not including it, even given the reality that, as you correctly
observe, it is not yet implemented in the majority of wallets and
libraries. One way round that is to make it optional (possibly combined
with above point about versioning). Note that for example you were
observing the necessity to check the sequence number was unchanged; that
would be encapsulated by checking equality of PSBT Input objects/fields.
While one can make such software architecture arguments, the really
fundamental point is the need for standards for x-wallet compatibility.
* Version, Locktime: Perhaps this is not needed; in a peer to peer
wallet scenario I think there might be logic in trying to get cover
traffic of (Core, Electrum, others), say, by using
last-block-locktime-mostly, as they do. Version should be 2 and sequence
is a function of your suggestion to use BIP125. Worth noting that BIP125
is *not* currently widely used on the network, though (see
https://p2sh.info/dashboard/db/replace-by-fee?orgId=1). For this reason
it should perhaps be explicitly only optional.
* Avoidance of non-payment "Unnecessary Input Heuristic" (1, 2). For
reference, see the definition here
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539
and some data here
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2800791
(whole comment thread may be of interest) - note this UIH name is afaik
Chris Belcher's invention, it seems useful as a categorisation.
So, it seems that UIH2 is more important to avoid; while some more
sophisticated wallet coin selection algorithms *may* occasionally pick
an input set where one input is larger than any output, most won't, and
some in particular never will. So I think the text here should indicate
that *the receiver's contributed input(s) SHOULD be chosen to avoid
triggering the UIH2 heuristic where possible, so that the final payjoin
transaction is maximally plausible as an ordinary payment" or similar.
UIH1 is a nice-to-have (meaning the plausibility extends to two
different (both wrong) payment amounts, but it may not be necessary to
mention it in the BIP.
Specific comments
=================
>> ====Step 4. Receiver validates, re-signs, and propagates on the
bitcoin network====
I believe this should say "Sender" not Receiver. Also for the next
sentence, s/receiver/sender/:
>> The receiver MUST validate the ''partial transaction'' was changed
correctly and non-maliciously (to allow using potentially untrusted
communication channels), re-sign its original inputs and propagate the
final transaction over the bitcoin network.
Your very correct highlighting of the attack vector of "receiver gives
sender other inputs belonging to sender to unwittingly sign (described
below), should be highlighted here, perhaps with the phrase "re-sign its
ORIGINAL inputs" (only!)".
>> When the sender is creating a "template transaction" it is done
almost identically to creating a normal send, with the exception that
*only* segwit inputs may be used. The sender is also encouraged to use a
slightly more aggressive feerate than usual as well as BIP125 (Opt-in
Full Replace-by-Fee Signaling), but neither is strictly required.
"slightly more aggressive feerate than usual" - this I understand is to
make up for receiver contributed utxo, OK.
"*only* segwit inputs" - it certainly makes things simpler. One can work
with non-segwit inputs but especially considering (as mentioned below)
we really ought to "MUST" the part about matching input types, I tend to
agree that non-segwit should be disallowed.
>> The receiver must add at least one input to the transaction (the
"contributed inputs"). If the receiver has no inputs, it should use a
500 internal server error, so the client can send the transaction as per
normal (or try again later).
Would it not be much simpler for the server to return a different
(non-error) response indicating that it will broadcast the template tx
in this case?
>> Its generally advised to only add a single contributed input, however
they are circumstances where adding more than a single input can be useful.
I don't see a good reason to advise the use of only 1 input? (but this
will also connect with the above generic comment about "UIH"). I guess
it's because of your approach to fees. I'd prefer not to create a
limitation here.
>> To prevent an attack where a receiver is continually sent variations
of the same transaction to enumerate the receivers utxo set, it is
essential that the receiver always returns the same contributed inputs
when it's seen the same inputs.
This is an approach to avoiding this problem which has the virtue of
simplicity, but it seems a little problematic. (1) You must keep a
mapping of proposed payment utxos to one's proposed contributed input
utxos, but (2) how should this be updated if you need to spend the
contribution mentioned in (1)? Ironically use of payjoin exacerbates
this issue, because it results in a smaller number of utxos being held
by the receiver at any one time :) All this considered, I still see the
value in your approach, but it might end up with a re-attempted payment
being rejected. Certainly the more complex suggested solutions coming
out of the summer 2018 coinjoin workshop aren't as practical as this,
and may be overkill for small merchants/receivers.
>> It is strongly preferable that the receiver makes an effort to pick a
contributed input of the same type as the other transaction inputs if
possible.
I have also thought about this and you could reasonably argue this
should be a MUST section in the BIP, that is, if the receiver cannot use
inputs of the same type, he should fall back to the template
transaction. A mixed-input payjoin/coinjoin is essentially
near-perfectly identifiable as such (there is almost zero other usage of
multi-type-input transactions), which is a very different thing than a
non-identifiable payjoin transaction. That may or may not be OK to the
sender. This is debatable though, for sure.
>> After adding inputs to the transaction, the receiver generally will
want to adjust the output that pays himself by increasing it by the sum
of the contributed input amounts (minus any fees he wants to
contribute). However the only strict requirement is that the receiver
*must never* add or remove inputs, and *must not* ever decrease any
output amount.
"*must never* add or remove inputs" - did you mean "must never remove
inputs"? he surely has to add one! Or, perhaps you mean he must not
alter the list of inputs provided by the sender (in which case it should
be clarified).
"must not decrease any output amount" - I initally disagreed with this
but it is a better option than the one I currently chose in Joinmarket
payjoin (sender pays all fee as long as receiver utxos are not too
much). So this means that the receiver either consciously chooses to not
increase the fee, meaning the fee rate may be a bit low (hence your
earlier comment about being generous, got it), or contributes via the
payout amount. I guess the latter might break merchant software
expecting to have amount output fixed and fees determined by change.
Regards,
Adam Gibson/waxwing
On 30. 08. 18 22:24, Ryan Havar via bitcoin-dev wrote:
> I've just finished writing an implementing of this, and extremely happy
> with how it turned out. So I'd like to go and try go down the path of
> more formally describing it and getting some comments and ultimately
> encourage its wide-spread use.
>
>
> ==Abstract==
>
> The way bitcoin transactions are overwhelming used is known to leak more
> information than desirable. This has lead to fungibility concerns in bitcoin
> and a raise of unreasonably effective blockchain analysis.
>
> Bustapay proposes a simple, practical way to bust these assumptions to
> immediate
> benefit of the sender and recievers. Furthermore it does so in such a
> way that
> helps recievers avoid utxo bloat, a constant problem for bitcoin merchants.
>
> ==Copyright==
>
> This BIP is in the public domain.
>
> ==Motivation==
>
> One of the most powerful heuristic's employed by those whose goal is to
> undermine
> bitcoin's fungiblity has been to assume all inputs of a transaction are
> signed by
> a single party. In the few cases this assumption does not hold, it is
> generally
> readibly recognizable (e.g. traditional coinjoins have a very obvious
> structure,
> or multisig outputs are most frequently validated onchain).
>
> Bustapay requires no changes to bitcoin and creates bitcoin transactions
> that are
> indistinguishable from normal ones.
>
> It is worth noting that this specification has been intentionally kept
> as simple
> as possible to encourage adoption. There are almost an endless amount of
> extensions
> possible but the harder the implementation of clients/server the less
> likely it
> will ever be done. Should bustapay enjoy widespread adoption, a "v2"
> specification
> will be created with desired extensions.
>
> ==Specification==
>
> A bustapay payment is made from a sender to a receiver.
>
> Step 1. Sender creates a bitcoin transaction paying the receiver
>
> This transaction must be fully valid, signed and all inputs must use
> segwit. This transaction is known as the "template transaction". This
> transaction must not be propagated on the bitcoin network.
>
> Step 2. Sender gives the "template transaction" to the receiver
>
> This would generally be done as an HTTP POST. The exact URL to submit it
> to could be specified with a bip21 encoded address. Such as
> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit
> and the HTTP body should be the raw transaction hex encoded as text.
>
> Step 3. Receiver processes the transaction and returns a partially
> signed coinjoin
>
> The receiver validates the transaction is valid, pays himself and is
> eligible for propation. The receiver then adds one of his own inputs
> (known as the "contributed input") and increase the output that pays
> himself by the contributed input amount. Doing so will invalidate the
> "template transaction"'s original input signatures, so the sender needs
> to return this "partial transaction" back to the receiver to sign. This
> is returned as a hex-encoded raw transaction a response to the original
> HTTP POST request.
>
> Step 4. Receiver validates, re-signs, and propagates on the bitcoin network
>
> The receiver is responsible in making sure the "partial transaction"
> returned by the sender was changed correctly (it should assume the
> connection has been MITM'd and act accordingly), resign its original
> inputs and propagates this transaction over the bitcoin network. The
> client must be aware that the server can reorder inputs and outputs.
>
> Step 5. Receiver observes the finalized transaction on the bitcoin network
>
> Once the receiver has seen the finalized transactions on the network
> (and has enough confirmations) it can process it like a normal payment
> for the sent amount (as opposed to the amount that it looks like on the
> network). If the receiver does not see the finalized transaction after a
> timeout will propagate the original "template transaction" to ensure the
> payment happens and function a strong anti-DoS mechanism.
>
>
> === Implementation Notes ===
> For anyone wanting to implement bustapay payments, here are some notes
> for receivers:
>
> * A transaction can easily be checked if it's suitable for the mempool
> with testmempoolaccept in bitcoin core 0.17
> * Tracking transactions by txid is precarious. To keep your sanity make
> sure all inputs are segwit. But remember segwit does not prevent txid
> malleability unless you validate the transaction. So really make sure
> you're using testmempoolaccept at the very least
> * Bustapay could be abused by a malicious party to query if you own a
> deposit address or not. So never accept a bustapay transaction that pays
> an already used deposit address
> * You will need to keep a mapping of which utxos people have showed you
> and which you revealed. So if you see them again, you can reveal the
> same one of your own
> * Check if the transaction was already sorted according to BIP69, if so
> ensure the result stays that way. Otherwise probably just shuffle the
> inputs/outpus
>
> Notes for sending applications:
>
> * The HTTP response must *not* be trusted. It should be fully validated
> that no unexpected changes have been made to the transaction.
> * The sender should be aware the original "template transaction" may be
> propagated at any time, and in fact can intentionally be
> done so for the purpose of RBF as it should have a slightly higher fee
> rate.
>
> == Credits ==
> The idea is obviously based upon Dr. Maxwell's seminal CoinJoin
> proposal, and reduced scope inspired by a simplification of the "pay 2
> endpoint" (now offline) blog post by blockstream.
>
>
> -Ryan
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:49:01

- reply

📅 Original date posted:2016-02-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In case it helps:
The elements alpha sidechain uses a different address format, which
includes an ECDH pubkey used for creating an ECDH shared secret.
That shared secret is used to seed a RFC6979 prng, which allows both
sides to generate the blinding factors used in the rangeproof.
So the situation is: both sides can generate the blinding factors, but
also the fake signatures used in the rangeproof (the basic idea there
is to have N signatures in a ring, but only one of them real; the rest
are forged and can be (must be) entirely random numbers. I say 'basic'
because the Borromean sig design is to link together several rings,
not just one). This allows the sender to embed the amount into one of
those fake signatures (usually the last one) using xor, with certain
formatting details.
It would be possible to not bother to embed the amount in this way;
the receiver, knowing the stream of fake/real signatures (again -
because he knows the seed for the prng), could simply observe which
ones are real and therefore know the digits of the amount. But if he
did it this way, it would not be possible to embed any other data into
the range proof (such as: auditing related information) using xor as
above.
I did some detailed explanation/investigation of this in sections 3.3
and 3.4 of
https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf
; with apologies for any errors, it was just an investigation I did
last summer.
On 02/10/2016 06:39 PM, Jeremy Papp via bitcoin-dev wrote:
> On 2/10/2016 5:53 AM, Henning Kopp wrote:
>> Hi Jeremy,
>>
>>> My understanding of the paper is that the blinding factor would
>>> be included in the extra data which is incorporated into the
>>> ring signatures used in the range proof.
>> Yep, that is a possibility. The blinding factor could be
>> encrypted with the public key of the receiver. Thus it is only
>> visible for the receiver who can then check that the correct
>> amount has been sent.
> ECC doesn't work like RSA; you can't encrypt directly with a
> public key. That's why you generate a shared secret between sender
> and receiver. See also, ECDH. (Basically, if (m, M = m*G) is your
> private/public key pair, and (n, N = n*G) is your recipient's
> private public key pair, you can both generate shared secret S =
> m*N = n*M = m*n*G without revealing your private keys to each
> other, and without revealing the secret to anyone else as long as
> they don't know either private key. You then use S as the basis for
> the key to some symmetric algorithm.)
>>> you'd transmit it then, though in any case, since using it
>>> will pretty much require segwit, adding extraneous data isn't
>>> much of a problem. In both cases, I imagine the blinding
>>> factor would be protected from outside examination via some
>>> form of shared secret generation... Although that would require
>>> the sender to know the recipient's unhashed public key; I don't
>>> know of any shared secret schemes that will work on hashed
>>> keys.
>> Here you lost me. Why do we need to create a shared secret? Is
>> this shared secret used as the blinding factor? Also I think the
>> sender knows the unhashed public key of the receiver. The only
>> reason not to include it in the transaction script is that an
>> external observer is unable to see the receiver directly in the
>> blockchain.
> Normal Bitcoin transactions are made to the hash of a public key
> because once the public key is known, it becomes easier to break it
> if we ever develop quantum computers. That's why it's recommended
> that you only spend from a particular address once (if possible)
> since its only in spending that you are required to reveal your
> public key. Since you can't do a shared secret with a public key
> hash, AFAIK, you'd have to know the public key of your recipient to
> be able to do ECDH.
>
> Jeremy Papp _______________________________________________
> bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWv1/8AAoJELOuCfHpoxl6dV8H/AvlEUebgKBAZdSdIEDKm0m0
pSXNWH62v327YdJ2wFqPCB2zG9HKXP76XhCGx39PEEvBmAFAoD6URAWPk8o03kTo
aJZUeRB7wLqIALuUub/0JzAJwcxZtTIhYu3ygfyZZuvpomG8yXlERwfjB+BcCXnm
D7TJ2qOyq3X3uaneb/OnUEvDxOrl9zAp9q7CUnFQB2xagCRnHyGNcrWaH43RmpHl
Eima6eonQUR4AAcIUu0CKSRjgM6q46bMbXTFt9I4XeqQxsMB5Gfe9Ggk15TNRoUm
ENVaJnPL4qlJqODSrO9R4xrurVCcp7HVeR9B5aztFQszVNxhMoZtFlyn5U3J0gY=
=+I00
-----END PGP SIGNATURE-----

2023-06-07 15:30:21

- reply

📅 Original date posted:2015-02-15
📝 Original message:On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
>
> Most money/payment systems include some method to reverse or undo
> payments made in error. In these systems, the longer settlement
> times you mention below are a feature, not a bug, and give more
> time for a human to react to errors and system failures.
>
Settlement has to be final somewhere. That is the whole point of it.
Transfer costs in current electronic payment systems are a direct
consequence of their non-finality. That's the point Satoshi was making
in the introduction to the whitepaper: "With the possibility of
reversal, the need for trust spreads".
There is nothing wrong with having reversible mechanisms built on top
of Bitcoin, and indeed it makes sense for most activity to happen at
those higher layers. It's easy to build things that way, but
impossible to build them the other way: you can't build a
non-reversible layer on top of a reversible layer.