Natanael [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-12 📝 Original message:Den 12 feb 2015 14:44 ...

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 14:44 skrev "Mike Hearn" <mike at plan99.net>:
>>
>> You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
>
> There have been lots of e-cash schemes proposed in the academic
literature that work like this, or variants of it. Schemes where
participants are anonymous until they double spend are popular.
>
> Let's re-write your proposal but substituting the word notary for miner:
>
>> To profit, the miner would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
>
> That's the exact argument we're having. The assertion is that a
"rational" notary would kill his own business to increase his profits in
the next few hours. So you're just arguing that a notary is different to a
miner, without spelling out exactly why.
>
> Does the notary have to make a big up front investment? If so, why is
that different to mining investment?

Miners are transient. You don't depend on any given subset of them.
Centralized e-currency give you no choice but to trust one set of notaries.

The notary don't have any large maintenance costs. The initial investment
is small, they don't need more than a few servers and maybe a HSM and some
office. In the non-collateral version, they're a centralized entity. Note
that in the fully centralized model, if the notary goes bad you're screwed.
Your tokens are useless or maybe gone.

Essentially you can't know if you're up for the long con or not.

Anybody can set up a miner with capital investments. No individual miner
has a large impact on the system as a whole.

In Bitcoin, you aren't dependent on any one multisignature notary. One
going gown only represents a small loss and done temporarily locked funds.
Anybody can set up a multisignature notary, but people won't trust you
unless you show you're trustable - you need to market yourself to get to
the point where a malicious doublespend can be profitable.

You can't really replicate the collateralized multisignature notary model
in centralized systems. Because having the e-currency bank be the notary
means they have the same powers a 51% miner would have - they can block the
transaction claiming the collateral, they can censor any other transactions
at will, and all your funds depend on them and the market's trust in them.

> Is the notary non-anonymous and afraid of being charged with payment
fraud? If so, note that big miners do lots of non-anonymous things too,
like renting warehouses and importing specialised equipment.

As notaries can be small operations, they can perform the doublespend as
they escape across the border.

> Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?

With collateralized multisignature notaries, my assumption is that
organizations that are related to Bitcoin transactions that has sufficient
sums of unallocated funds would use them for collateral in a scheme like
this (almost every large organization in the world have some unallocated
funds somewhere).

As sellers have almost no risk of losing money to them, any notary backed
by somebody they know and trust would be good enough

As buyers also have no risk, they'd use them when they want to make quick
payments.

-----

You seem to be making a lot of arguments from the status quo. I don't care
what people have been doing, preserving every habit isn't a sacred goal. I
care about stable incentives and long term predictability regarding what
behavior is safe. Behavior that becomes unsafe if incentives change is bad
and shouldn't be relied on.

Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a
guarantee for what will end up in the blocks without servers involved is to
reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you
like! What you consider an attack is irrelevant. You assume a certain
behavior is desired without first making sure it is reliable.

Depending on that which isn't guaranteed is baaaad, and breaking other
people's assumptions is by itself NOT an attack if there never was a
guarantee or even as little as an implicit understanding it is safe.

Your also assume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.

Besides, zero-conf will never be secure if you don't add external
contextual information as a requirement when validating blocks. Otherwise
defecting miners will frequently doublespend against you. And adding such
information is messy and probably not secure in itself, as it opens up for
gaming the system through network level attacks.

And your remarks against game theory seems unwarranted.

The game theorists that are wrong are typically wrong for one of the
following reasons;

* Their model is wrong. The system, the actors and/or the options available
are misunderstood.
* The actors don't understand the avaliable incentives and go for trial and
error (the most optimal choices for attack and defense are found at random
or not at all, and not always adopted until it has stood the test of time).
* That option is on the to-do list, just wait.
* There's easier and/or more profitable attacks (a variant of #1 if the
game theorist said it is certain to happen).

You should NOT EVER rely on security-through-opportunity-cost for the
attacker or assume you can always keep doing what you always did. Once the
bigger targets are gone, you're next.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/2ad0cc1c/attachment.html>;