That also closes the door to potential (not unsolvable) DoS attacks like the one Carol does in the previous example: she does it once, but she could had done it ad nauseam as well.
First of all, let's note that the problem is actually not with fake exchange proposals, but with fake offers: we could simplify the protocol and require Alice to include her txins with the offer. In this case Carol would post a partially signed transaction, and will be left at mercy of Alice who can either make a fully-signed transaction, or ignore it.
Well, who can attack depends on the exact protocol. I was assuming
that Alice published the offer and also sent the partial transaction
to Carol for her to confirm.
If in your protocol is the counterparty and not the publisher of the
offer who sends the partial transaction, then the publisher is the
attacker: Alice would publish an offer and then collect a ton of
partial transactions that she never completes.
And by the way, including the txins with the non-binding offer
doesn't help.
You may need reputation, external PoW or something else to solve this DoS.
Freimarkets kind of eliminate the problem with fake offers, as offers are sub-transactions and are already signed.
But Alice can still disrupt the exchange with double-spending: when she sees that somebody made a complete transaction out of her sub-transaction, she will double-spend her inputs, thus making exchange impossible. The effect is the same as with fake offers DoS attack described above: offers are seen, but cannot be executed. (I assume that Alice can perform this double-spending attack with high probability of success via network-level shenanigans.)
Thus if you want an exchange which has more stable behavior, you still might want some kind of reputation system or double-spend-prevention service even if you have sub-transactions.
Double-spending the order is at all lights equivalent to a cancel
order button on a centralized exchange.
Are centralized exchanges that allow users to cancel their opened
orders flawed? I wouldn't say so.
Are centralized exchange that allow to place fake orders which produce
many fails when another user tries to fill them flawed?
Yes, I would say so.
If my fulfillment of Alice's order gets into the chain before Alice's
cancel, she cannot do anything. For some reason you're assuming that
Alice has greater capacity than me to broadcast her transaction to
miners.
Even if that's the case, you're not halting me from trading, that's
just how this system works: it takes some time to confirm
transactions.
I could even fulfill Alice's offer and another similar offer at the
same time with the same inputs. I would broadcast it and I know only
one of them can get into the chain, but maybe I don't care.
In that case, if Alice cancels her order and it arrives to miners
earlier (or with a higher fee) than my fulfillment would become
invalid and only my other fulfillment can get into the chain.
Similarly, Alice's order cancellation becomes invalid if my
fulfillment gets into the chain earlier, as she probably was
re-claiming all the funds in the input and now it only has what I
haven't buy.
If you donate to 2 different nonprofits with the same funds, only one
of them will get into the chain: that's not an attack to yourself, is
just how the system works.
But maybe being online all the time stops being the inconvenience we predict and people also start to run their own mail servers.
So my point is, offline execution is a useful feature, but not critical.
That's what I'm saying maybe we're not predicting accurately. Maybe
we're wrong.
But you missed my analogy. Why do you think people don't run their
own mail servers on their smartphones despite "having them online all
the time"?
Not having to be online was, in any case, the main advantage of ripplecoin over 2PC distributed Ripple (at least for "IOU-trade-chain" use cases). Maybe that's why I give it that importance.
I see, it might be really important for some use cases.
2PC Ripple is almost equivalent to Freimarket's private server in
which Ripple IOUs users can:
1) Run their own private server, like their own mail server, and have
it always online.
2) Trust another private server.
Much of the value of doing the IOU accounting in-chain is precisely
to be able to go off-line without trusting anyone.
That's my main point rather than it being critical for
old-Ripple-like uses.
But as said sub-tx have many other uses.
Where can I read more about this?
Is chromawallet opting for this approach or order-based coloring?
We haven't decided yet, I'll post more information about these two approaches on the bitcoinX mailing list in a couple of days.
Cool, thanks. Having binding orders, even with some limitations, is
my eyes a big improvement.
If the trade were AAA/BBB, anyone could get the AAA for uncolored
satoshis instead of the wanted BBB.
So what you really want to say is that "it is limited to offers in
which colored coins are offered in exchange of the host currency (BTC)".
Yes. I guess making Bitcoin a special kind of an asset is good for people who invested in Bitcoin, so this limitation might be seen as a feature.
I will assume this is a joke.
So I correct my answer to the first question: without considering off-chain interoperability, options or any of the other use cases, if we only consider only the most basic p2p trade, the main advantage of sub-txs is granularity in the orders.
Hmm, interesting... Well, you can partially address granularity problem by publishing many offers of different size which use same inputs, e.g. 100, 50, 25, 10, etc. This will reduce blockchain bloat, but isn't same thing as proper granularity, I guess.
[/quote]
Then if someone buys 10 out of the 100, you need to publish another
offer with 90, after another trade you publish another offer, etc.
This introduces sequencing in the execution.
To prevent this, you would prefer to publish 10 offers of 10 each,
just because is more convenient for you.
But someone who wants to buy 50 will complete 5 of those similar
orders instead of a single one with nQuantity=5
It is a minor optimization, so we would probably remove sub-txs if we
didn't need them for the rest of the cases.
By the way, did you consider the fact that extra complexity brought by advanced features like sub-transactions and such might lead to higher chances of having critical bugs in code? Many feature in Freimarkets proposal are far from trivial, so it is a serious concern, in my opinion.
We've tried hard to find new vulnerabilities in the protocol
introduces by our changes and we encourage everyone else to do the
same.
We haven't found fundamental flaws, but of course concrete
implementations could have their own flaws.
Should we sacrifice, for example, BIP32 because some people could
implement it wrong? I don't think so.
Stupid programmers can also have their user's bitcoins stolen by
using a flawed random number generation function in their clients,
but that's not a fundamental design flaw of the bitcoin protocol,
just a flawed implementation.
