Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Miners Aren’t Friends

blog.keep.network

Post reply on HN
Print view View original

41–50 of 256 posts

Re: Miners Aren’t Friends

#41

Post by RoboTeddy »

barbegal wrote: post #37
nspassov wrote: post #2

To my limited understanding of Ethereum and Bitcoin, the network already has rules in place to punish nodes that misbehave or cheat. In the case of Bitcoin, that is part of layer 1 so it is independent of any application layers and thus it should always be at the core of the network. With PoS cheating is likely to become a bigger issue [1], since with PoW the miners who get punished will have wasted their time and el…

Proof of stake doesn't work in practice unless we can find a source of randomness that is globally available, non-influencable and everyone can agree on [1]. At the moment, that source of randomness is completely elusive. It might be possible to create a random source from some form of binary astronomical event which can be widely verified but it would have an incredibly low bit rate of new randomness. One possible c…

Can imagine a protocol for generating randomness to some arbitrary security level (at the expense of locking up security deposits):

(1) Anyone can decide to become a 'randomness provider' by putting up a large security depsoit

(2) Every epoch (some number of blocks), each provider chooses a private random number and commits to it by publishing its hash

(3) During the next epoch but, each provider publishes the random they committed to earlier.

(4) xor together all the random values. The result is a pseudorandom number everyone can agree on, and which should be sufficiently good for many applications include PoS selection

If any provider fails to publish the random number they committed to, they lose their security deposit and there is no random value provided for the associated epoch. The process starts over.

If you're worried about bribing attacks over all providers, recognize that all we need is a single altruistic provider to keep the system safe. Altruistic behavior may be rare compared to selfish behavior, but I think we can usually rely on its nonzero presence.

If you're still really worried that collusion could be going on amongst ALL randomness providers, just become a provider yourself.

It's possible for a provider to wait for all other providers to reveal their values, and then privately determine whether or not the final random value would be favorable to them; they then have the option of canceling the epoch by keeping their private value hidden and losing their security deposit. This option (in combination with a particular application, and the size of the security deposit of providers) puts a bound on what the random value can be safely used for (e.g., if it's for a lottery, the expected value of another truly random swing at the jackpot has to be lower than the value of a security deposit).

Re: Miners Aren’t Friends

#42

Post by cjbprime »

Nice article! Here's another type of failure with its solution:

* You want to register a domain name on the blockchain and associate it with your address, so you submit "register foo".

* The miner sees it, and inserts an earlier transaction registering foo to them instead.

Solution:

* You register the hash of foo, which registers the plaintext encoded by that hash, then wait until the transaction is accepted publicly and submit a second transaction that reveals to everyone the plaintext of the hash that you registered.

The miner could still try to guess at which name you're registering based on the hash (by having a long list of potential names to hash just in time), but I can't think of a way to do better than that. Anyone else?

Re: Miners Aren’t Friends

#43

Post by prestwich »

runeks wrote: post #11

> Again, let’s design a simple smart contract. This time Alice wants to play a guessing game. Alice puts 5 Ether in her contract. That ETH goes to the person that guesses closest to the number she’s thinking of. Alice calls commit with the hash of the number, so she can’t change her mind. Anyone else can call guess to submit a guess. After 2 blocks Alice calls reveal to tell everyone what the number is. This scheme i…

Hey, author here. Yeah, several of the example contracts are insecure in other ways. Or just plain bad ideas. I decided against providing implementations because I was worried people wouldn't understand that.

Re: Miners Aren’t Friends

#44

Post by bdr »

cjbprime wrote: post #42

Nice article! Here's another type of failure with its solution: * You want to register a domain name on the blockchain and associate it with your address, so you submit "register foo". * The miner sees it, and inserts an earlier transaction registering foo to them instead. Solution: * You register the hash of foo, which registers the plaintext encoded by that hash, then wait until the transaction is accepted publicly…

You register the hash of domain+seed. Second transaction reveals both.

Re: Miners Aren’t Friends

#45

Post by barbegal »

RoboTeddy wrote: post #41
barbegal wrote: post #37

Earlier quoted context omitted.

Proof of stake doesn't work in practice unless we can find a source of randomness that is globally available, non-influencable and everyone can agree on [1]. At the moment, that source of randomness is completely elusive. It might be possible to create a random source from some form of binary astronomical event which can be widely verified but it would have an incredibly low bit rate of new randomness. One possible c…

Can imagine a protocol for generating randomness to some arbitrary security level (at the expense of locking up security deposits): (1) Anyone can decide to become a 'randomness provider' by putting up a large security depsoit (2) Every epoch (some number of blocks), each provider chooses a private random number and commits to it by publishing its hash (3) During the next epoch but, each provider publishes the random…

That's all well and good but who manages the security deposit?

Re: Miners Aren’t Friends

#46

Post by RoboTeddy »

barbegal wrote: post #45
RoboTeddy wrote: post #41

Earlier quoted context omitted.

Can imagine a protocol for generating randomness to some arbitrary security level (at the expense of locking up security deposits): (1) Anyone can decide to become a 'randomness provider' by putting up a large security depsoit (2) Every epoch (some number of blocks), each provider chooses a private random number and commits to it by publishing its hash (3) During the next epoch but, each provider publishes the random…

That's all well and good but who manages the security deposit?

The system itself, e.g. the code of a smart contract. Example implementation: https://github.com/randao/randao

Re: Miners Aren’t Friends

#47

Post by corford »

alexktz wrote: post #38
corford wrote: post #32

Earlier quoted context omitted.

That's fine and makes sense to me. It's more the people that cram 8 cards in to their machine and mine 24/7 that I have a hard time understanding.

£6 per card per day (1080ti) is quite appealing. 60p electricity costs. £48 per day minus £4.80 costs. Every day? For just leaving something switched on? It is quite appealing. I got my 1080ti's for £650 a pop. ROI is 108 days. That's why people, myself included, are doing it.

I still don't get it :( That's 108 days before you _start_ to make a profit and future returns are guaranteed to diminish as difficulty goes up.

Versus £5,200 capital to invest immediately in a basket of safe (as much as crypto currencies can be), liquid coins that will likely x3 to x8 over a 12 month period.

To each their own I guess but it's not the bet for me.

Re: Miners Aren’t Friends

#48

Post by SimonPStevens »

bdr wrote: post #44
cjbprime wrote: post #42

Nice article! Here's another type of failure with its solution: * You want to register a domain name on the blockchain and associate it with your address, so you submit "register foo". * The miner sees it, and inserts an earlier transaction registering foo to them instead. Solution: * You register the hash of foo, which registers the plaintext encoded by that hash, then wait until the transaction is accepted publicly…

You register the hash of domain+seed. Second transaction reveals both.

Couldn't someone else then simultaneously register the hash of the same domain with a different seed? Neither of you would know of the duplicate until you revealed your seeds.

Re: Miners Aren’t Friends

#49

Post by prestwich »

blunte wrote: post #7

Some of these issues do seem concerning, but most wouldn't be profitable unless every miner was doing it (because the impact on one of these malicious behaviors will be felt in a later block). Unless you're lucky enough to mine two blocks in a row, I don't see how you can gain directly from malicious transaction reordering. You'll consume the first retrieve fee, but the second retrieve will be in a later block (which…

Hi, author here. Look for part two for examples of how these attacks can siphon value from deployed contracts :)

Re: Miners Aren’t Friends

#50

Post by theoh »

cjbprime wrote: post #42

Nice article! Here's another type of failure with its solution: * You want to register a domain name on the blockchain and associate it with your address, so you submit "register foo". * The miner sees it, and inserts an earlier transaction registering foo to them instead. Solution: * You register the hash of foo, which registers the plaintext encoded by that hash, then wait until the transaction is accepted publicly…

This is similar to the rainbow table attack on password hashes. The defense against that is to use a (public) salt when computing the hash. Maybe something similar will work here, though I'm not clear about the details of your notion of "just in time" hashing. The salt just prevents precomputation of hashes.
Post reply on HN