Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-19 Thread nopara73 via bitcoin-dev
Wouldn't this enable a passive adversary listening the mempool to associate
unrelated TXO clusters to the same user?

On Sat, Sep 19, 2020, 15:38 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> > I'd like to share with you a draft proposal for a mechanism to replace
> > CPFP and RBF for increasing fees on transactions in the mempool that
> > should be more robust against attacks.
>
> Interesting idea!  This is going to take a while to think about, but I
> have one immediate question:
>
> > To prevent garbage sponsors, we also require that:
> >
> > 1. The Sponsor's feerate must be greater than the Sponsored's ancestor
> fee rate
> >
> > We allow one Sponsor to replace another subject to normal replacement
> > policies, they are treated as conflicts.
>
> Is this in the reference implementation?  I don't see it and I'm
> confused by this text.  I think it could mean either:
>
> 1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least
>one input in common (which is part of the "normal replacement policies")
>
> 2. A can be replaced by B even if they don't have any inputs in common
>as long as they do have a Sponsor Vector in common (while otherwise
>using the "normal replacement policies").
>
> In the first case, I think Mallory can prevent Bob from
> sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
> sponsor before he does; since Bob has no control over Mallory's inputs,
> he can't replace Mallory's sponsor tx.
>
> In the second case, I think Mallory can use an existing pinning
> technique to make it expensive for Bob to fee bump.  The normal
> replacement policies require a replacement to pay an absolute higher fee
> than the original transaction, so Mallory can create a 100,000 vbyte
> transaction with a single-vector sponsor at the end pointing to Bob's
> transaction.  This sponsor transaction pays the same feerate as Bob's
> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee.  In order
> for Bob to replace Mallory's sponsor transaction with his own sponsor
> transaction, Bob needs to pay the incremental relay feerate (10
> nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).
>
> Thanks,
>
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

2020-06-11 Thread nopara73 via bitcoin-dev
Thank you all for your replies, I think everyone agrees here how it "should
be" and indeed I risked my post and my used terminology to further
legitimize the thinking of adversaries.
I'd have one clarification to my original post. It may not be clear why I
put PJ/CS to the same box. One way of thinking of CoinSwap is to swap coin
histories and PayJoin is to share coin histories. For the purposes of this
attack the consequences are roughly the same so that's why I think it's ok
to put them under the same umbrella in this discussion, but I wouldn't die
for it :)

And indeed I perhaps wrongly called this the "Taint Issue", maybe it should
be called "Coin Discrimination Issue" or something like that, not sure if
we have a term for this, but I'm sure we should have a term for this as
unlike some other, so far theoretical attacks on Bitcoin's fungibility, it
is currently being applied in practice.


On Thu, Jun 11, 2020 at 7:24 AM Mr. Lee Chiffre via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thought provoking. In my opinion bitcoin should be designed in a way to
> where there is no distinction between "clean" bitcoins and "dirty"
> bitcoins. If one bitcoin is considered dirty then all bitcoins should be
> considered dirty. Fungibility is important. And bitcoin or its users
> should not be concerned with pleasing governments. Bitcoin should be or
> remain neutral. The term "clean" or "dirty" is defined by whatever
> government is in power. Bitcoin is not to please government but to be
> independent of government control and reliance on government or any other
> centralized systems. To act as censorship resistant money to give people
> freedom from tyranny. I'm just saying that if anyone can determine if a
> bitcoin is clean or dirty then I think we are doing something wrong. What
> is great with certain protocols like coinjoin coinswap and payjoin there
> is that plausible deniability that hopefully would spread the entire
> "taint" of bitcoin collectively either for real or just as a possibility
> to any blockchain analysis entities (with no real way to tell or interpret
> with accuracy).
>
> Bitcoin should be designed in a way where the only way to stop "dirty"
> bitcoins is to reject all bitcoins.
>
> If "dirty" bitcoins is actually a real thing then I guess I could have fun
> by polluting random peoples bitcoin addresses with "dirty" coins right? No
> way to prove if it is a self transfer or an unsolicited "donation".  I
> just do not see how any bitcoin UTXO censorship could work because of
> plausible deniability.
>
> If any company actually used UTXO censorship then customers can just use
> services that are respecting of freedom and do not use censorship.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

2020-06-10 Thread nopara73 via bitcoin-dev
The problem with CoinJoins is that desire for privacy is explicitly
signalled by them, so adversaries can consider them "suspicious." PayJoin
and CoinSwap solve this problem, because they are unnoticeable. I think
this logic doesn't stand for scrutiny.

>From here on let's use the terminology of a typical adversary: there are 3
kinds of coin histories: "clean", "dirty" and "suspicious".
The aftermath of you using a "dirty" coin is knocks on your door. You using
a "suspicious" coin is uncomfortable questions and you using a "clean" coin
is seamless transfer.

In scenario 1, you start out with a "clean" history. By using CoinJoins you
make your new coin's history "suspicious" so you have no incentive to
CoinJoin. By using CoinSwap/PayJoin your new coin can be either "clean" or
"dirty". What would a "clean" coin owner prefer more? Take the risk of
knocking on the door or answering uncomfortable questions?

In scenario 2, you start out with a "dirty" history. By using CoinJoins you
make your new coin's history "suspicious" so you have an incentive to
CoinJoin. By using CoinSwap/PayJoin your new coin can either be "clean" or
"dirty". What would a "dirty" coin owner prefer more? And here's an
insight: you may get knocks on your door for a dirty coin that you have
nothing to do with. And you can prove this fact to the adversary, but by
doing so, you'll also expose that you started out with a "dirty" coin to
begin with and now the adversary becomes interested in you for a different
reason.

You can also examine things assuming full adoption of PJ/CS vs full
adoption of CJ, but you'll see that full adoption of any of these solves
the tainting issue.

So my current conclusion is that PJ/CS does not only not solve the taint
problem, it just alters it and ultimately very similar problems arise for
the users. Maybe the goal of unobservable privacy is a fallacy in this
context as it is based on the assumption that desiring privacy is
suspicious, so you want to hide the fact that you desire privacy. And the
solution to the taint issue is either protocol change or social change
(decent adoption.)

PS.: Please try to keep the conversation to the Taint Issue as this email
of mine isn't supposed to be discussing general pros and cons of various
privacy techniques.

Any thoughts?

-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Academic research regarding BIP0002

2020-04-22 Thread nopara73 via bitcoin-dev
Just a tip: if you'd like to get feedback on your work, then share your
work as well, since not many people are willing to commit to helping unless
they know how large the work is.

On Tue, Apr 21, 2020 at 10:51 PM Shiva Jairam via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
>
>
> I am doing a project trying to map out BIP002 (
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) into a
> bussiness process model using BPMN2.0.
>
> This is a project regarding an academic research for my studies.
>
> I am by no means an expert in Blockchain nor Bitcoin and have just
> recently began looking into the technologies.
>
>
>
> Is someone willing to review or discuss my model?
>
> If this is not the right place to discuss such a topic, pointing in the
> right direction is much appreciated.
>
>
>
>
>
> Kind regards,
>
> Shiva Jairam
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] [bitcin-dev] BIP157 Filter Type Extensibility Proposal for Combinations

2020-02-28 Thread nopara73 via bitcoin-dev
BIP157 defines a section called "Filter Types" (
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki#filter-types
 )

>  For the sake of future extensibility and reducing filter sizes, there
are multiple *filter types* that determine which data is included in a
block filter as well as the method of filter construction/querying. In this
model, full nodes generate one filter per block per filter type supported.

>  Each type is identified by a one byte code, and specifies the contents
and serialization format of the filter. A full node MAY signal support for
particular filter types using service bits. The initial filter types are
defined separately in BIP 158
, and one
service bit is allocated to signal support for them.

While it provides a way to extend to multiple filter types, it does not
provide a way to extend to filter type combinations. Such combinations are
possible if the filter types would have to be defined with the power of
two: 1, 2, 4, 8, 16..., so every octet of a byte array could denote a
specific filter type, this way we could be able to signal for any number of
combinations of those filter types.

Originally this idea is described in more details and with code here:
https://github.com/bitcoin/bitcoin/issues/18221

MarcoFalke suggested for me to submit it to the mailing list instead of a
GitHub issue then propose an update to the BIP if consensus is reached.

-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions.

2020-02-22 Thread nopara73 via bitcoin-dev
>  It seems to me that most users will not have nearly the same output of
"around 1 BTC"

While that would be true out of context, it depends on how you interpret it
and they interpret it really broadly: " One input might be 0.03771049 BCH;
the next might be 0.24881232 BCH, etc. "

> anyway if you deploy this on a real live mainnet, and if your math
requires that you have "around 1 BTC" outputs per user. you might as well
just use equal-valued CoinJoins, where the equal-valued outputs at least
are completely unlinked from the inputs.
>  e.g. if you have a CashFusion transaction with outputs 1.0, 1.1, 0.99,
you could transform that to a CoinJoin with 0.99, 0.99, 0.99, 0.01, 0.11
outputs.

Equal valued coinjoins (1) waste more blockspace as your example
illustrates and (2) prevent arbitrary amounts, so you cannot send in
coinjoins.

> Indeed, the change outputs of an equal-valued CoinJoin would have similar
analyses to CashFusion, since the same analysis "around 1 BTC" can be
performed with the CoinJoin change outputs "around 0 BTC".

I've been wondering about this too. I think it cannot be applied to
existing CoinJoin schemes, as coin selection heuristics are quite a help
and that could be a reason why the changes can be deanonymized (I assume.)
For example if I want to analyze a Wasabi CJ, then I assume every input
that have > 0.1 BTC value to be THE valid input partition and I will only
look for the valid matching partition on the output side. I won't try to
find all the partitions and look at all the possible subset sums. (
https://github.com/nopara73/Notes/blob/master/BellNumber.md,
https://github.com/nopara73/Notes/blob/master/SubSetSum.md)

At the very least coin selection for equal value coinjoins can be relaxed
to remove such assumptions and make the above math applicable for the
change. (If works.)



On Sun, Dec 29, 2019 at 12:25 AM ZmnSCPxj  wrote:

> Good morning Adam,
>
> > 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.0001
> 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 -
> > --
>
>
> It seems to me that most users will not have nearly the same output of
> "around 1 BTC" anyway if you deploy this on a real live mainnet, and if
> your math requires that you have "around 1 BTC" outputs per user. you might
> as well just use equal-valued CoinJoins, where the equal-valued outputs at
> least are completely unlinked from the inputs.
>
> Indeed, the change outputs of an equal-valued CoinJoin would have similar
> analyses to CashFusion, since the same analysis "around 1 BTC" can be
> performed with the CoinJoin change outputs "around 0 BTC".
>
> * You can 

[bitcoin-dev] Non-equal value CoinJoins. Opinions.

2019-12-27 Thread nopara73 via bitcoin-dev
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.0001 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev