Adam Ficsor [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-08-30 to 2019-03-06
💬 Posted a total of 9 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:16:41

- reply

📅 Original date posted:2019-03-06
📝 Original message:I would like to grab the opportunity to point out that I am doing the same,
but in the form of presentations. I started with a two part presentation,
but I decided to make it into a 6 part presentation series in the future.
Part 1: Concentrating on network level privacy -
https://vimeo.com/album/5765075/video/316635787
Part 2: Concentrating on blockchain level privacy -
https://www.youtube.com/watch?v=AmFC9dhtemo&t=358m0s
I think this work is very important and nothing comparable has been done
before, so thank you for taking the time for this Belcher!
On Wed, Mar 6, 2019 at 1:38 AM Chris Belcher via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello list,
>
> For the last few weeks I've been working on a literature review for
> bitcoin privacy:
>
> https://en.bitcoin.it/wiki/Privacy
>
> It aims to cover about all privacy issues in bitcoin, including
> Lightning network, and has a bunch of examples to help demonstrate how
> the concepts work in practice.
>
> There is also a new wiki category with smaller related articles:
>
> https://en.bitcoin.it/wiki/Category:Privacy
>
> Regards
> CB
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190306/8b2abaf8/attachment-0001.html>

2023-06-07 18:16:30

- reply

📅 Original date posted:2019-02-17
📝 Original message:In Wasabi wallet we are in the finishing line of an encryption manager.
I'll ask the OP to review your BIP and probably I'll do it myself, too
before I'd merge. Feel free to review/test our PR, too:
https://github.com/zkSNACKs/WalletWasabi/pull/1127
On Sun, Feb 17, 2019 at 6:01 PM Christopher Gilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have written up a proposed BIP. It has to do with Signature formats when
> using Bitcoin Private keys. It is here:
> https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github issue:
> https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps are
> with regards to getting a BIP number assigned or any other process steps
> required.
>
> Regards,
> Chris
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190217/00affeb6/attachment.html>

2023-06-07 18:16:17

- reply

📅 Original date posted:2019-02-04
📝 Original message:Unlike mouse movement it works in a CLI software, which is great. However,
isn't there something else you can use instead of cards? Something with
invariant culture and maybe more common.
On Sun, Feb 3, 2019 at 7:27 PM Ryan Havar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> More of a shower-thought than a BIP, but it's something I've long wish
> (hardware) wallets supported:
>
> ---
>
> Abstract: Bitcoin Wallets generally ask us to trust their seed generation
> is both correct and honest. Especially for hardware and air gapped wallets,
> this is both a big ask and more or less impossible to practically verify.
> So we propose a bring-your-own-entropy approach in which the wallet can
> function completely deterministically. Our method is based on shuffling
> physical deck of cards. There are 52! (2^219.88) different shuffle order,
> which is a big enough space to be secure against collision and brute force
> attacks. Conveniently a shuffled deck of cards also can serve as a physical
> backup which is easy to hide in plain sight with great plausible
> deniability.
>
>
> Representation:
>
> Each card has a suit which can be represented by one of SCHD (spades,
> clubs, hearts, diamonds) and a value of one of 23456789TJQKA where the
> numbers are obvious and (T=ten, J=jack, Q=queen, K=king, A=ace) so "7 of
> clubs" would be represented by "7C" and a "Ten of Hearts" would be
> represented with "TH".
>
> An deck of cards looks like:
>
>
> 2S,3S,4S,5S,6S,7S,8S,9S,TS,JS,QS,KS,AS,2C,3C,4C,5C,6C,7C,8C,9C,TC,JC,QC,KC,AC,2H,3H,4H,5H,6H,7H,8H,9H,TH,JH,QH,KH,AH,2D,3D,4D,5D,6D,7D,8D,9D,TD,JD,QD,KD,AD
>
> And can be verified by making sure that every one of the 52 cards appears
> exactly once.
>
>
> Step 1. Shuffle your deck of cards
>
> This is a lot harder than you'd imagine, so do it quite a few times, with
> quite a few different techniques. It is advised to do at *least* 7 good
> quality shuffles to achieve a true cryptographically secure shuffle. Do not
> look at the cards while shuffling (to avoid biasing) and don't be afraid to
> also shuffle them face down on the table. Err on the side over
> over-shuffling.
> See also:
> https://en.wikipedia.org/wiki/Shuffling#Sufficient_number_of_shuffles
>
> Step 2. Write out the order (comma separated)
>
> And example shuffle is:
>
>
> 5C,7C,4C,AS,3C,KC,AD,QS,7S,2S,5H,4D,AC,9C,3H,6H,9D,4S,8D,TD,2H,7H,JD,QD,2D,JC,KH,9S,9H,4H,6C,7D,3D,6S,2C,AH,QC,TH,TC,JS,6D,8H,8C,JH,8S,KD,QH,5D,5S,KS,TS,3S
>
> Step 3. Sha512 it to create a seed
>
> In the example above you should get:
>
> dc04e4c331b1bd347581d4361841335fe0b090d39dfe5e1c258c547255cd5cf1545e2387d8a7c4dc53e03cacca049a414a9269a2ac6954429955476c56038498
>
> Step 4. Interpret it
>
> e.g. For bip32 you would treat the first 32 bytes as the private key, and
> the second 32 bytes as as the extension code.
>
>
>
>
> -Ryan
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190204/0bc324ae/attachment.html>

2023-06-07 18:16:17

- reply

2023-06-07 18:15:25

- reply

📅 Original date posted:2018-12-01
📝 Original message:If this needs to be a BIP or not, that is up to this list to decide, I will
not be pushy abut it. We simply encountered a well defined and common issue
and we took the time to work out and specify our solution, so it may come
in handy for other developers encountering this same issue. We can argue
about the significance of it, but I suspect all arguments will come down to
how much an individual developer values UX or how much he does not.
On Sat, Dec 1, 2018 at 11:57 AM James MacWhyte <macwhyte at gmail.com> wrote:
> I liked the cheekiness of your summary, Adam ;)
>
> I'm not sure why this needs to be a BIP. It is a UX detail--not really
> related to bitcoin protocol or procedures. I wouldn't even call it a
> description of best practices, since every product's use case is going to
> be different.
>
> If you think there is a compelling reason for why this needs to be a
> documented standard, please elaborate!
>
> Thanks,
> James
>
>
> On Sun, Nov 11, 2018 at 7:41 PM Adam Ficsor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Thank you for all your comments. To sum up:
>>
>> - There were no comments related to the implementation details.
>> - There are concerns about this may incentivize users to use copypaste
>> functionality extensively.
>> - A counter argument was made that crypto hijackers use the clipboard,
>> because that is the most convenient thing to hijack, not because they can
>> only hijack that and, if Bitcoin users would move to other ways of
>> specifying destinations, that may end up being just as an issue, too.
>> - The rest of the conversation was about crypto hijackers, which I think
>> is off topic in this thread.
>>
>> Finally I'd like to note, there's already a work in progress
>> implementation in Wasabi:
>> https://github.com/zkSNACKs/WalletWasabi/pull/825
>>
>> On Fri, Nov 9, 2018 at 1:14 AM Dmitry Petukhov via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>>
>>> > > Do you know any reasonably convenient mechanism for end user to
>>> > > transfer an address from, say, a web page to the wallet address
>>> > > input field ?
>>> >
>>> > - QR code scanning of a Bitcoin URI
>>> > - On Android: A "bitcoin:" URI intent or a BIP70 payment message
>>> > intent
>>> > - On desktop OSes there are similar mechanisms to launch Apps from the
>>> > browser (e.g. for mailto: links)
>>>
>>> This works if the author of the web page thought about this, and
>>> created appropriate liks/qr codes. In many cases, addresses are
>>> just presented for users as text, to copy.
>>>
>>> People also send addresses in message apps and emails. Maybe if
>>> applications start to autodetect bitcoin addresses and convert them to
>>> bitcoin: links, there will be less need to copy-paste. But I suspect
>>> that this feature will not be quickly adopted by applications.
>>>
>>> > For cases where the payee is a well-known entity the BIP70 payment
>>> > protocol has authentication via certificates. That doesn't work for
>>> > the "the person in front of you is the only trust anchor you have"
>>> > usecase though.
>>>
>>> There are also BIP75 and BIP47 that may help, but the number of wallets
>>> that support these protocols is small (I think in part because of
>>> relative complexity of these protocols).
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Best,
>> Ádám
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181201/21b2a889/attachment.html>

2023-06-07 18:15:10

- reply

📅 Original date posted:2018-11-12
📝 Original message:Thank you for all your comments. To sum up:
- There were no comments related to the implementation details.
- There are concerns about this may incentivize users to use copypaste
functionality extensively.
- A counter argument was made that crypto hijackers use the clipboard,
because that is the most convenient thing to hijack, not because they can
only hijack that and, if Bitcoin users would move to other ways of
specifying destinations, that may end up being just as an issue, too.
- The rest of the conversation was about crypto hijackers, which I think is
off topic in this thread.
Finally I'd like to note, there's already a work in progress implementation
in Wasabi: https://github.com/zkSNACKs/WalletWasabi/pull/825
On Fri, Nov 9, 2018 at 1:14 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > > Do you know any reasonably convenient mechanism for end user to
> > > transfer an address from, say, a web page to the wallet address
> > > input field ?
> >
> > - QR code scanning of a Bitcoin URI
> > - On Android: A "bitcoin:" URI intent or a BIP70 payment message
> > intent
> > - On desktop OSes there are similar mechanisms to launch Apps from the
> > browser (e.g. for mailto: links)
>
> This works if the author of the web page thought about this, and
> created appropriate liks/qr codes. In many cases, addresses are
> just presented for users as text, to copy.
>
> People also send addresses in message apps and emails. Maybe if
> applications start to autodetect bitcoin addresses and convert them to
> bitcoin: links, there will be less need to copy-paste. But I suspect
> that this feature will not be quickly adopted by applications.
>
> > For cases where the payee is a well-known entity the BIP70 payment
> > protocol has authentication via certificates. That doesn't work for
> > the "the person in front of you is the only trust anchor you have"
> > usecase though.
>
> There are also BIP75 and BIP47 that may help, but the number of wallets
> that support these protocols is small (I think in part because of
> relative complexity of these protocols).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181112/2c148c33/attachment.html>

2023-06-07 18:15:09

- reply

📅 Original date posted:2018-11-07
📝 Original message:BIP: ?
Layer: Applications
Title: Address Paste Improvement
Author: nopara73 <adam.ficsor73 at gmail.com>, David Molnar <
molnardavid84 at gmail.com>
Type: Standard Track
Created: 2018-11-07
Abstract. End-users often copy-paste addresses. This BIP aims to facilitate
the user experience regarding this process.
Motivation. Some services already implemented autopaste functions, which is
done as follows: the user clicks to the address box and a Bitcoin address
automatically gets pasted from the clipboard. Depending on the
implementation, this could be either annoying or not permissive enough if
it completely replaces the possibility of manually entering a Bitcoin
address.
The BIP Proposal can be found here:
https://gist.github.com/nopara73/322dbd263a5c45267da87cffc36de6f6
An implementation will soon follow in Wasabi Wallet.
Regards,
nopara73
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181107/65afea63/attachment.html>

2023-06-07 18:10:50

- reply

📅 Original date posted:2018-02-13
📝 Original message:I agree with the opposition on changing the license, because of the
branding attacks.
However having two coins with the same Proof Of Work is a zero sum game
from a security point of view. It may not be a bad idea to consider
changing the license in a way that only limits cryptocurrencies with the
same Proof Of Work, since they directly affect the stability and security
of Bitcoin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180213/df2de265/attachment.html>

2023-06-07 18:10:02

- reply

📅 Original date posted:2018-01-23
📝 Original message:> It's quite easy to get no change with a not-dumb algorithm selecting
coins if you have a decent number of outputs well under the value
you're paying.
I have been playing around quite a lot these lines, too and created some
content that is worth to look at:
https://github.com/nopara73/ZeroLink/#coin-selection
Also, you can try a simpler privacy oriented coin control implementation
with HiddenWallet:
https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2
--
Best,
Ádám
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/7ad7b524/attachment.html>

2023-06-07 18:05:10

- reply

📅 Original date posted:2017-08-30
📝 Original message:I've been long working on Bitcoin privacy, mainly on TumbleBit
<https://github.com/NTumbleBit/NTumbleBit>, HiddenWallet
<https://github.com/nopara73/HiddenWallet/> and BreezeWallet
<https://github.com/stratisproject/Breeze/>. ZeroLink is my latest
effort to gather all the privacy reasearch I'm familiar with,
combine/organize them in a coherent and practical way. The main point
of ZeroLink is that "nothing is out of its scope", it is intended to
provide complete anonymity on-chain.
Amongst its many topics, ZeroLink defines mixing technique, coin
selection, private transaction and balance retrieval, transaction
input and output indexing and broadcasting and even includes UX
recommendations.
Users' privacy should not be breached neither on blockchain level, nor
on network level.
Proposal:https://github.com/nopara73/ZeroLink/
In a nutshell ZeroLink defines a pre-mix wallet, which can be
incorporated to any Bitcoin wallet without much implementation
overhead. Post-mix wallets on the other hand have strong privacy
requirements, so the mixed out coins will not lose their uniformity.
The requirements and recommendations for pre and post-mix wallets
together define the Wallet Privacy Framework.
Coins from pre-mix wallets to post-mix wallets are moved by mixing.
Most on-chain mixing techniques, like CoinShuffle, CoinShuffle++ or
TumbleBit's Classic Tumbler mode can be used. However ZeroLink defines
its own mixing technique: Chaumian CoinJoin, which is based on Gregory
Maxwell's 2013 CoinJoin recommendations and ideas
<https://bitcointalk.org/index.php?topic=279249.0>. I found this
technique to be the most performant, fastest and cheapest one.
Regarding adoption SamouraiWallet <https://github.com/Samourai-Wallet>
and HiddenWallet <https://github.com/nopara73/HiddenWallet> are going
to implement and comply with ZeroLink and BreezeWallet
<https://github.com/stratisproject/Breeze> also shows significant
interest.
Regards,
nopara73
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/7706a7dc/attachment-0001.html>