Lucas Ontivero [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-30 to 2023-05-23
💬 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-09-11 21:42:42

- reply

📅 Original date posted:2023-09-08
🗒️ Summary of this message: The post discusses the BIP21 URI scheme for Bitcoin payments and the potential confusion and exploitation that can arise from allowing multiple parameter specifications.
📝 Original message:
Kiminuo, this was discussed here: https://github.com/bitcoin/bips/pull/49
On Fri, Sep 8, 2023 at 2:39 PM kiminuo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> [Formatted version of this post is here:
> https://gist.github.com/kiminuo/cc2f19a4c5319e439fc7be8cbe5a39f9]
>
> Hi all,
>
> BIP 21 [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki]
> defines a URI scheme for making Bitcoin payments and the purpose of the URI
> scheme is to enable users to easily make payments by simply clicking links
> on webpages or scanning QR Codes. An example of a BIP21 URI is:
>
>
> bitcoin:bc1qd4fxq8y8c7qh76gfnvl7amuhag3z27uw0w9f8p?amount=0.004&label=Kiminuo&message=Donation
>
> Now to make it easier, these URIs are typically clickable. Bitcoin wallets
> register the "bitcoin" URI scheme so that a BIP21 URI is parsed and data
> are pre-filled in a form to send your bitcoin to a recipient. Notably,
> wallets do not send your bitcoin once you click a BIP21 URI, there is still
> a confirmation step that requires user's attention. Very similar experience
> is with a QR code that encodes a BIP21 URI where one just scans a QR code
> and data is, again, pre-filled in a wallet's UI for your convenience.
>
> While working on Wasabi's BIP21 implementation I noticed that based on the
> BIP21 grammar [
> https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#abnf-grammar],
> it is actually allowed to specify URI parameters multiple times. This means
> that the following URI is actually valid:
>
> bitcoin:bc1qd4fxq8y8c7qh76gfnvl7amuhag3z27uw0w9f8p?amount=0.004&label=Kiminuo&message=Donation&amount=1.004
> (note that the 'amount' parameter is specified twice)
>
> Bitcoin Core implements "the last value wins" behavior[^3] so amount=1.004
> will be taken into account and not "amount=0.004"[^4]. However, in general,
> the fact that the same parameter can be specified multiple times can lead
> to a confusion for users and developers[^1][^2]. In the worst case, it
> might be exploited by some social engineering attempts by attempting to
> craft a 'clever' BIP21 URI and exploting behavior of a particular wallet
> software. For the record, I'm not aware that it actually happens, so this
> is rather a concern.
>
> The main question of this post is: Is it useful to allow specifying BIP21
> parameters multiple times or is it rather harmful?
>
> Regards,
> K.
>
> [^1]: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1510
> [^2]:
> https://github.com/MetacoSA/NBitcoin/blob/93ef4532b9f2ea52b2c910266eeb6684f3bd25de/NBitcoin/Payment/BitcoinUrlBuilder.cs#L74-L78
> [^3]: I added a test to that effect in
> https://github.com/bitcoin/bitcoin/pull/27928/files, see
> https://github.com/bitcoin/bitcoin/blob/83719146047947e588aa0c7b5eee02f44884553d/src/qt/test/uritests.cpp#L68-L73
> .
> [^4]: You can test your wallet's behavior by scanning the last image here
> https://github.com/zkSNACKs/WalletWasabi/pull/10578#issue-1687564404 (or
> directly
> https://user-images.githubusercontent.com/58662979/265389405-16893ce8-7c19-4262-bb60-5fd711336685.png
> ).
> _______________________________________________
> 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/20230908/0e44a479/attachment-0001.html>

2023-06-07 23:21:58

- reply

📅 Original date posted:2023-05-23
🗒️ Summary of this message: A proposal to use ALL|ANYONECANPAY sighash flag to reduce steps in coinjoin, but concerns about DoS attacks and input verification remain.
📝 Original message:Hi all,
In some coinjoin implementations inputs are registered first because in
that way, if the user fails or refuses to sign the transaction the input is
banned and denial of service is made a bit more expensive, in the sense
that an attacker needs more and more utxos to keep the attack going.
Your proposal can work if you find an alternative mechanism for mitigating
the DoS attacks or when DoS attacks are not a problem (I can imagine there
are scenarios where it is not really important).
Best
- Lucas
On Mon, May 22, 2023 at 7:53 PM Ben Carman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The problem with using ALL|ANYONECANPAY is that you cannot verify
> beforehand that the other inputs are the inputs you want added to the
> transaction.
>
> Some examples of bad things that could happen:
>
>
> - Coordinator adds its own inputs, you still get your outputs but
> effectively paid fees for no privacy gain
> - The inputs added could be paying at a lower fee rate than expected,
> causing the tx to take longer than what you paid for
> - Different input types or amount are added so you no longer have the
> same uniformity across the inputs
> - (if you care) An input from a sanctioned address is added, causing
> you to get "tainted" coins.
>
> This is the code in ln-vortex that verifies the psbt on the client side if
> you are curious
>
>
> https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616
>
>
> Best,
>
> benthecarman
>
> ------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Monday, May 22, 2023 7:51 AM
> *To:* Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
>
> Hi Bitcoin Developers,
>
> I recently experimented with different sighash flags, PSBTs and realized
> ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
>
> Steps:
>
> - Register outputs.
> - One user creates a signed PSBT with 1 input, all registered outputs and
> ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs
> to PSBT.
> - Finalize and broadcast the transaction.
>
> Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297
>
> Tx:
> https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492
>
> I plan to use this in joinstr if there are no major drawbacks and it can
> even be implemented by other coinjoin implementations.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230523/4bc0294c/attachment-0001.html>

2023-06-07 23:17:43

- reply

📅 Original date posted:2022-12-13
📝 Original message:Some wallets like Electrum would be affected by that because they use RBF
to batch transactions so, outputs cannot be exactly the same as before.
On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I dont think there was anything technical with the implementation and as
> far as I can tell this is well developed and ready.
>
> The reasons I can find for not being adopted are listed here -
> https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe
> Replace-by-fee
>
> Those reasons do not seem pertinent here - given OptinRBF already exists
> as an option and the added benefit of continuing to be able to support
> 0-conf.
>
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
> Phone: +44 113 4900 117
> Skype: daniellipshitz123
> Twitter: @daniellipshitz
>
>
> On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john at synonym.to> wrote:
>
>> Why wasn't this solution put in place back then? Are there problems with
>> the design?
>>
>> While I still think there are unhealthy side-effects of Full-RBF (like
>> more doublespending at unknowing merchants, after years of FSS protection)
>> I think discussion of this FSS-RBF feature is worth considering.
>>
>> --
>> John Carvalho
>> CEO, Synonym.to <http://synonym.to/>
>>
>>
>> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel at gap600.com>
>> wrote:
>>
>>> Thank you for bringing that to my attention, apologies for not being
>>> aware of it.
>>>
>>> First-seen-safe replace-by-fee as detailed here
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>> by Peter Todd seems to be a very suitable option and route
>>> which balances FullRBF while retaining the significant 0-conf use case.
>>>
>>> This would seem like a good way forward.
>>>
>>>
>>>
>>> ________________________________
>>>
>>>
>>>
>>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch at woobling.org>
>>> wrote:
>>>
>>>>
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>>>
>>> _______________________________________________
> 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/20221213/22889b45/attachment.html>

2023-06-07 18:28:16

- reply

📅 Original date posted:2021-01-18
📝 Original message:Hi
Before all, thanks for the wiki page tracking the payjoin adoption, it is a
good idea.
-----
Even when there is a reasonable economical incentive to use segwit
transactions to save fees a big percentage of the transactions are not
using segwit yet. In the case of payjoins the economic incentives are not
so big while the privacy benefits are not so clear for the payer as they
are for the global transactions graph as a whole. This means that payjoins
requires some level of altruist attitude from the payers. The payjoins UX
is also not good because I think most users are not familiar with bip21
uris (users still request support because they pay a bech32 address in an
exchange and the exchange tells them that's not a valid bitcoin address).
All this is relative and subjective but in general terms I would say it is
more or less true for many people.
Anyway, imagine wallets' developers agree on making payjoins payment by
default because it is the right thing to do (fight against surveillance to
spy on bitcoin users and improve bitcoin's fungibility). In that case it
should be completely transparent to the users and at not cost, it shouldn't
require the user to do anything different, it shouldn't be noticeable
slower, etc. In fact, users should have to know they are payjoining at all.
The only way I see to achieve something like that is by moving to schemes
where wallets can communicate and interact. I should be able to know
something about you that allows me to select your name from my contact list
and select "Pay to Chris" and if my wallet knows how to find yours then it
can request a new address and pays, or generate a new one for you (probably
using a output descriptor you created to share with me).
Sorry for the long semi-random rant.
El vie, 15 ene 2021 a las 21:07, Chris Belcher via bitcoin-dev (<
bitcoin-dev at lists.linuxfoundation.org>) escribió:
> PayJoin is an exciting bitcoin privacy technology which has the
> potential to damage the ability of blockchain surveillance to spy on
> bitcoin users and destroy bitcoin's fungibility. A protocol standard has
> already been defined and implemented by a couple of projects such as
> BTCPayServer, Wasabi Wallet, JoinMarket and BlueWallet.
>
> I've made a wiki page tracking adoption:
> https://en.bitcoin.it/wiki/PayJoin_adoption
>
> It is similar to the Bech32 adoption page.
>
>
> Recently a UK bitcoin exchange shut down due to new regulations, with
> the owner writing a very interesting and relevant blog post that I'll
> quote here:
>
> > you’re considered suspicious if you used a marketplace and not an
> exchange. Coinjoin counts as high risk. Gambling is high risk. As you
> use entities that are paranoid about keeping their coins clean and
> adhering to all the regulations, your risk scores will continue to
> increase and without you even knowing why, your deposits will become
> rejected, you may be asked to supply documents or lose the coins, your
> account may become suspended without you having any clue what you did
> wrong. And quite possibly you didn’t do anything wrong. But that won’t
> matter.
> >
> > The goal post, the risk score threshold will keep moving along this
> trend until the point where you will be afraid of using your personal
> wallet, donating to someone online, receiving bitcoins from anywhere
> except for regulated exchanges. At that point, crypto will be akin to a
> regular bank account. You won’t have a bitcoin wallet, you will have
> accounts to websites.
>
> https://blog.bitbargain.com/post/638504004285054976/goodbye
>
> If we want bitcoin to fulfill its dream of a permissionless money for
> the internet then we'll have to work on this. What can we do to increase
> adoption of PayJoin?
> _______________________________________________
> 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/20210118/d900c8f8/attachment.html>

2023-06-07 18:22:12

- reply

📅 Original date posted:2019-12-29
📝 Original message:This idea is not similar to the one in the knapsack paper because this one
is based only in the computational complexity of finding partitions that
match the outputs. However, and except in rare cases, there is only one
valid partition (solution) for each output, it doesn't introduce any
ambiguity. Knapsack, on the other hand, splits the original outputs in such
a way that there are many partitions (solutions) that match the a selected
group of outputs. For example, imagine 7 people decide to participate in a
coinjoin transaction with an arbitrary number of inputs (no more than 7
inputs each), imagine this is not a pay to yourself cj tx but a pay to
someone else cjtx instead such that there are at most 2 outputs for
participants (payment output and change output) in this case, configuring
the partitions search algorithm to restrict the search space to sets of 7
inputs maximum and 4 outputs maximum it found 14,599 valid transactions in
42mins 18secs
https://raw.githubusercontent.com/lontivero/Knapsack/master/data/knapsack-7-participants.txt
The same simulation with 8 participants under the same conditions found
35,781 valid transactions in about 4 hours. Finally, with 9 participants I
let it running all the day and it didn't finished. The point is that the
number of valid transactions grows so incredible fast that with 100
participants even if you find a way to find all the partitions that matches
a set of outputs (something near to impossible), there are no way to know
which of those are the real ones.
Also, the attacks on this mechanism look so simple that generate doubts.
Finally, I think the numbers in this proposal look weird because the
example is using 10 inputs and the amounts are in the "neighborhood of
~0.1btc" (what the heck does that mean?) and the sum of those are around
1btc. That means that it could work in a very specific scenario. Knapsack
is a general solution with good math behind and backtested against
historical data extracted from the bitcoin's blockchain.
In summary, in unequal inputs/outputs coinjoins knapsack is the best we
have at the moment (btw, it is not as effective as equal-outputs
transactions). This proposal is imo inferior and it is not supported by
good math.
El vie., 27 dic. 2019 a las 22:29, nopara73 via bitcoin-dev (<
bitcoin-dev at lists.linuxfoundation.org>) escribió:
> The CashFusion research came out of the Bitcoin Cash camp, thus this
> probably went under the radar of many of you. I would like to ask your
> opinions on the research's claim that, if non-equal value coinjoins can be
> really relied on for privacy or not.
>
> (Btw, there were also similar ideas in the Knapsack paper in 2017:
> https://www.comsys.rwth-aachen.de/fileadmin/papers/2017/2017-maurer-trustcom-coinjoin.pdf
> )
>
>
> https://github.com/cashshuffle/spec/blob/master/CASHFUSION.md#avoiding-amount-linkages-through-combinatorics
>
>
> I copy the most relevant paragraphs here:
>
> ---------BEGIN QUOTE ---------
>
>
> Consider a transaction where 10 people have each brought 10 inputs of
> arbitary amounts in the neighborhood of ~0.1 BCH. One input might be
> 0.03771049 BCH; the next might be 0.24881232 BCH, etc. All parties have
> chosen to consolidate their coins, so the transaction has 10 outputs of
> around 1 BCH. So the transaction has 100 inputs, and 10 outputs. The first
> output might be 0.91128495, the next could be 1.79783710, etc.
>
> Now, there are 100!/(10!)^10 ~= 10^92 ways to partition the inputs into a
> list of 10 sets of 10 inputs, but only a tiny fraction of these partitions
> will produce the precise output list. So, how many ways produce this exact
> output list? We can estimate with some napkin math. First, recognize that
> for each partitioning, each output will typically land in a range of ~10^8
> discrete possibilities (around 1 BCH wide, with a 0.00000001 BCH
> resolution). The first 9 outputs all have this range of possibilities, and
> the last will be constrained by the others. So, the 10^92 possibilies will
> land somewhere within a 9-dimensional grid that cointains (10^8)^9=10^72
> possible distinct sites, one site which is our actual output list. Since we
> are stuffing 10^92 possibilties into a grid that contains only 10^72 sites,
> then this means on average, each site will have 10^20 possibilities.
>
> Based on the example above, we can see that not only are there a huge
> number of partitions, but that even with a fast algorithm that could find
> matching partitions, it would produce around 10^20 possible valid
> configurations. With 10^20 possibilities, there is essentially no linkage.
> The Cash Fusion scheme actually extends this obfuscation even further. Not
> only can players bring many inputs, they can also have multiple outputs.
> ---------END QUOTE ---------
> --
> Best,
> Ádám
> _______________________________________________
> 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/20191229/87d4973c/attachment.html>

2023-06-07 18:12:30

- reply

📅 Original date posted:2018-05-30
📝 Original message:Hi Jim,
Yes please, could you share CSV? We are developing a Wallet that uses
Golomb-Rice filters it would help a lot for determine the best P value
depending on the estimated number of elements the client needs to watch.
2018-05-29 19:38 GMT-03:00 Jim Posen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> This is a really cool finding, thanks Pieter!
>
> I did some more analysis on selecting a good P value to reduce total data
> downloaded considering both filters themselves and blocks in the case of
> false positive matches, using data from mainnet. The quantity it minimizes
> is:
>
> filter_size(N, B) + block_size * false_positive_probability(C, N, B)
>
> N is the number of filter elements per block
> B is the Golomb-Rice coding parameter
> C is the number of filter elements watched by the client
>
> The main result is that:
>
> For C = 10, B = 13 is optimal
> For C = 100, B = 16 is optimal
> For C = 1,000, B = 20 is optimal
> For C = 10,000, B = 23 is optimal
>
> So any value of B in the range 16 to 20 seems reasonable, with M = 1.4971
> * 2^B for optimal compression, as Pieter derived. The selection of the
> parameter depends on the target number of elements that a client may watch.
>
> I attached some of the results, and would be happy to share the CSV and
> raw notebook if people are interested.
>
>
> On Fri, May 25, 2018 at 2:14 PM Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Fri, May 25, 2018 at 6:42 PM, Gregory Maxwell <greg at xiph.org> wrote:
>> > configuration is roughly right, then M=1569861 and rice parameter 19
>> > should be used.
>>
>> That should have been M=784931 B=19 ... paste error.
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180530/e1679c4d/attachment.html>

2023-06-07 17:57:38

- reply

📅 Original date posted:2017-03-30
📝 Original message:I don't know if i should response to this mail list or make a comment in
commit file (
https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e
)
* Motivation:
Here I think it could worth to mention that 58 requires mathematical
operations over big numbers. This is not very fast and most of the
programming languages don't provide support for big numbers OOB.
* Why not make an address format that is generic for all scriptPubKeys?:
I understand that if a new generic encoding format is introduced that could
lead to some confusions but what if in the future there is a new type of
address that can also be encoded with bech32? Don't we need a address type
anyway?
thx
2017-03-29 7:07 GMT-03:00 Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via
> bitcoin-dev wrote:
> >> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
> >> In Bitcoin Wallet, I use Base 43 (alphabet:
> >> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
> >> code encoding. I only leave out the space character because it gets
> >> replaced by "+" in URLs.
> >
> > Doing that only makes addresses a few % shorter, at the cost of
> significant
> > downsides. For example, not everyone knows what those additional
> characters
> > are called, particularly for non-English-speaking users. Non-alphanumeric
> > characters also complicate using the addresses in a variety of contexts
> ('/'
> > in particularly isn't valid in filenames).
>
> I'm not convinced that transmitting addresses via voice should be a
> usecase to target at. I don't understand your comment about non-english
> speaking users. Obviously they cannot voice-communicate at all with
> only-english-speaking users, so there is no need to communicate
> voice-communicate addresses between them.
>
> Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
> messages are the three most used forms.
>
> Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes
> *bigger* because due to the characters used for URL parameters (?&=)
> those QR codes are locked to binary mode. To make them shorter, we'd
> need to use something like "Base 64url" (or ideally Base 94 -- all
> printable ASCII characters).
>
>
> _______________________________________________
> 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/20170330/7daa6736/attachment-0001.html>