
DDoSCoin: Cryptocurrency with a Malicious Proof-Of-Work [pdf] - gwern
https://www.usenix.org/system/files/conference/woot16/woot16-paper-wustrow.pdf
======
Uptrenda
I'm currently working on something similar. It's a blockchain for verifiable
exploits against open source software. The idea is that you can represent bug
bounties as a series of smart contracts and have exploits run
deterministically against a test case within a virtual machine. That way
researchers are always guaranteed payment for working exploits and vendors can
be forced to release patches on time.

I wrote more about the protocol and rational here if anyone is interested:
[http://roberts.pm/exploit_markets](http://roberts.pm/exploit_markets) It's
still very much in the brain storming phase so any feedback at all is
appreciated.

~~~
Taek
Every full node would need to the full VM, which has nightmare security
implications, not to mention scalability issues.

You are far better off just doing multisig + escrow here.

~~~
Uptrenda
That's true. The problem would be if you get attackers who have exploits to
break out of virtual machines. What I can say in those regards is you might be
able to design that out by creating a DSL for specific kinds of exploits and
then using that for the first version.

You could always have a panel of humans that approve or deny exploits on the
network but that kind of thing defeats the point of using the service. What
I'm trying to accomplish is to build something without the need for human
intervention. Because with a human-run service you open yourself up to
politics and bureaucracy and suddenly its the same as with a regular bug
program.

You've given me something important to think about.

------
CapacitorSet
Tldr on page 4:

* The miner generates a random nonce

* It initiates a TLS 1.2 connection to the victim server, and uses the nonce as `client_random`

* The server generates an ephemeral public key (eg. using ephemeral DH or ephemeral ECDH), and responds with a 32-byte `server_random`

* The server sends its certificate chain as well as its public key, and signs the DH key exchange parameters along with `client-random` and `server-random`. _This is the proof of work_

* The client computes the SHA256 hash of the DH params, the signature and the nonce, and does the usual difficulty check; if it passes, it is used to make a block

------
sheerun
I'm not sure this currency will take off but how about the following: Instead
of network paying for DDoSing TLS connection let it pay for relaying TLS
connections.

The principle of would the same as in DDoSCount, but miners relay connections
of certain users until it results in signature of given difficulty. After
obtaining such signature, miner would be able to withdraw from user's account
certain amount of coins. The probability dictates miners would withdraw
randomly from all users.

~~~
CapacitorSet
A bit like Torcoin, basically.

~~~
chatmasta
Hey, I wrote that :)

The big challenge for any kind of decentralized "proof of bandwidth" scheme is
verifiability. How do you know two actors are not colluding to say they are
producing bandwidth? Or how do you resolve conflicts when a client thinks he
transferred 1gb but the host thinks he transferred 10gb?

Our solution was to use a verifiable shuffle, where all relays and clients
submit their public keys into a matrix, which the shuffle then transforms into
routing paths. The result is that the client gets a "path" (e.g. A tor
circuit, but it could be any routing path) that is privately addressable but
publicly verifiable. So each node on the path only knows the IP address of its
neighbor node, but all nodes on the path can sign bandwidth calculations with
a group signature.

That said it was two years ago for my senior thesis... hardly a work of art :P
I'm still pursuing the ideas in one form or another.

------
libeclipse
Off topic but I'm interested, what software is used to create these papers?
Almost all research papers have the same, very aesthetically pleasing, layout
that is hard to recreate.

~~~
hrrsn
LaTeX - [https://www.latex-project.org](https://www.latex-project.org)

------
pul
Can anyone think of defences not listed in the paper?

~~~
CapacitorSet
I can't think of more defences, but they briefly mention the possibility for
websites to mine DDoS coins against themselves and I think it's an interesting
perspective. I don't know the algorithms involved in the key exchange well
enough, but if they support bulk optimizations like RSA does (it's faster to
do thousands of signatures in a single operation, rather than one operation at
a time) then the server has a noticeable advantage on clients - to the point
where it could drive the difficulty insanely high and make it unprofitable to
mine DDoS coins.

~~~
pul
Making it unprofitable would be the best defense against for-profit ddos
attacks IMO. If using a botnet to mine regular coins yields more than
ddoscoins the insentive is gone.

