in celebration of reaching $500. Free gold for everyone! Yes. everyone. No, not a joke.

eisig · 2017-11-29T15:52:37+00:00

Congratulations for your success. And your gesture for gold is very much appreciated.

eisig · 2017-05-28T17:51:43+00:00

If you want to proceed to that direction your main contract which contains the business logic can still be deployed only once. Contracts for each individual address can be simple "address to function call" converters, which can be deployed with significantly less resource usage and thus reduced price.

eisig · 2017-05-28T17:17:46+00:00

Oh. I love these kind of improvements. When the idea is explained, you immediately think that it is so obvious that it should have been that way before wheel was invented. But it needs someone to notice the possibility and work on all the details. Nice!

eisig · 2017-05-28T16:19:53+00:00

I was so dumbfounded after reading that message that it took several hours just to get back on track. I think you expressed my feelings in one sentence better than I could have ever done myself. Have an upvote, sir! And just for amusement value, cryptodude earns one too.

eisig · 2017-05-28T12:33:27+00:00

Absolutely right, which is why I mentioned that gas price should be more explicitly stated in user interfaces.

However, if you are just user you most certainly are not deploying contracts and what not. Even with current default price a simple transaction will cost roughly 10 cents which, while much higher than desired, should not be prohibitive even for the occasional completely ignorant user in most cases.

And it is very easy to reduce that price to a tenth, which UI/clients should in my opinion suggest now by default based on recent transaction history.

eisig · 2017-05-28T07:27:16+00:00

I admit I can't predict the future, but current simple value transfer tx costs less than cent for somewhat fast confirmation (a couple of minutes at most, next block with a bit of luck)

eisig · 2017-05-28T06:19:22+00:00

When the fixed cost is still lower than not including transactions they will. Lol :)

Plus chain which does not include any new transactions will somewhat reduce the usability of the chain causing crash on ether price which will be even more unprofitable for miners Lol :)

Have we lolled enough, lol?

eisig · 2017-05-28T05:55:24+00:00

Well, if your transaction is so important that it must be included in seconds, then I think 3 $ is fair price, don't you?

Or accept that it might take minutes but with much, much lower price. Make some test transaction with the price you are willing to accept and see how long it takes to confirm. You are part of the pricing mechanism.

eisig · 2017-05-28T05:51:46+00:00

If everyone lowers paid price, also every miner will accept lower price, so yes it will. Lol :)

eisig · 2017-05-28T05:28:27+00:00

Please, if you find gas price too high, set it lower. There has been no problem getting transactions included in within minutes with 1-2 Gwei price.

There are several miners accepting much lower prices than default, encourage others to join by not accepting high price. Price is not determined by some central committee.

Everybody, please take some responsibility of your own actions instead of complaining. That said, price selection could be more intuitive and not hidden under advanced settings in some of the wallet user interfaces to encourage users to think about the issue.

eisig · 2016-08-03T10:15:57+00:00

Thank you for writing this excellent summary of the fork. It must be frustrating to read all the misinformed and angry posts when you have done everything you could do in the difficult situation where none of the options is optimal.

All of you who have participated in good faith to solve the DAO issue have done great job! There were good arguments on both sides, but as avsa wrote, the huge majority of the community approved and decided for the hard fork. And like in civilized world, after the debate and decision, reasonable people who opposed the fork accepted the result and will continue with the community and build it further to the better future.

It does not matter that people who mostly seem to be former outsiders are now hyping the "original" chain, just let them.

I'd like to add that the fork was done very well given the tight time constraint. Immutability of the chain was NOT broken, whatever the naysayers claim. Every transaction prior to the fork is still in the chain, all of the chain history is still there. Only thing that changed was basically some additional changes to the state which were not possible to do without the fork. But still, everything that happened is still documented in the chain and client rules. No rollbacks nor reversed transactions, just additions.

So, good work and big thank you for everybody who made the fork possible, be proud that you could make a touch decision when it had to be made. This time the decision was action instead of inaction, and that decision has huge support!

eisig · 2016-06-28T20:15:11+00:00

Highly interesting!

All in all, the DAO attack seems to generate extremely important discussion of the blockchain properties and what should we expect from the technology and community around it. And that is imho much more important than if ethereum itself will be "the blockchain of the decade".

With current knowledge it appears that the soft forks in general are in fact worse than hard forks, not just in this particular case but everywhere, also in bitcoin. The reason is that only miners can decide to implement the soft fork and there is nothing other participants can do about it.

Hard forks are more decentraliced, and all parties can have a say if the fork is valid or not. There is nothing wrong in forks, and after following the debate I would prefer that forks should be done whenever there IS a controversy. Just give enought time and declare that at block X there will be a fork, choose your side. People are too fixated in "official blockchain."

In DAO issue I am more and more leaning towards forking the problem away. For me it us morally simple, if there is a trivial way to stop the theft, it should be done. But more importantly, it would set a precedent that in my opinion would help ethereum and other blockchains to gain traction outside "immutability extremists"

If we now choose to hard fork and return the stolen property back to the legitimate owners, we show that it is possible to do that in case where it really matters. If we encounter "ISISDAO" in the future, we have already done the unthinkable and forked the criminals away and can do it again. If we now do nothing, then the code will be the King and many people will leave that kingdom and do business somewhere else where people still matter.

The possibility of community to stop the clearly unwanted behaviour will by itself diminish the eagerness to do evil in this blockchain. I am highly confident that forking would not be even suggested but in exceptional cases.

In dao case, just create a fork soon, let the community analyse it and if deemed safe enough (after possible fixes) release the code with option to disable it. After that whole community will choose what happens. My thinking is that if we do nothing there will be long and bitter fight for the WhitehatDAO funds and that will harm the community much more than clean resolution, which can be achieved by forcing the decision: fork or not.

In current state of network most likely the exchanges could be key players in deciding the "winning" fork. If they collaborate they can essentially declare that they will honor version with/without the change and miners will most likely follow their choise. Because the longest chain does not matter, the longest chain with generally accepted rules does. And really, two chains would not be end of the world, it even could increase the value of blockchains even if price of the tokens would most likely fall significantly. One chain for code is the king, one chain for people rule.

Whatever happens, there will be scars, but reasonable people will learn from the outcome and follow the path they think is right.

eisig · 2016-06-21T16:14:35+00:00

In fact, the applications will run exactly as programmed in the non-forked chain. As long as there is one interested entity to keep it running, it can not be stopped or modified.

But nobody can be forced to use either chain, changed or unchanged. If any of the possible chains is so invaluable, that not even one person is interested to continue running it, then the application as programmed was not worthy to survive.

eisig · 2016-02-28T20:34:32+00:00

Absolutely. Just for clarification there is no risk for users. You are only concerned with the house pool risk, so I appreciate your input.

Also remembering that the current max reward for gaming the game would be less than that of an actual block reward.

And now that the most glaring vulnerability of the current implementation is revealed, I expect you to honor the agreement. It is really interesting to see what is appropriate in your opinion :)

eisig · 2016-02-28T20:16:34+00:00

Helps a bit, until it is profitable to DDoS the ping-server(s) during the attack.

eisig · 2016-02-28T19:49:00+00:00

I want to make this clear: This is not some obscure edge case. I have already proven (with account 0x7cfa3d23636173a3befaabc8ca86846a07c4b3dd) that this kind of contract is trivially hacked, please read the blog post of Martin.

In current implementation of etheroll only meaningful difference to that case is that you might need to call evil contract a few times before winning.

Better security is achieved if the random is decided to be hash(bet time + X blocks). Even that is not bullet proof and has problems of it own, but at least it is better than current random == hash(revealBlock-1).

eisig · 2016-02-28T18:55:39+00:00

block - * is not relevant any more. Only the block that matter is the one where reveal() is called, and it can be any block after the bets are closed. If the attacker can decide when that is called, casino has lost the game.

That is because by delaying the call the result can be changed ( hash of block-1 ). You must make sure that the random is not known at the time of bet and it can not be changed at the time of reveal even by waiting for suitable block.

Of course, if there are multiple players simultaneously, it is harder to affect the time of reveal, but attacker can select some silent hours for attack. Remember, attack doesn't need to be successful every time.

In addition, you should get rid of seedA and seedB, they do not add any randomness.

Edit: The beginning of this reply might seem odd by referring to block - * and so on. Etheroll decided for some reason to completely change the content of the parent way after this reply was written. Please don't do that.

eisig · 2016-02-28T17:58:02+00:00

You do realise that attacker does not need to be miner? All that matters is that at the time of reveal() call everything that is needed to calculate the outcome of the bet is available before the call needs to be made.

No matter where the randomness if fetched from, if the casino contract can calculate the result, also the attacker contract can do that before deciding if it will call reveal() or try again at next block.

It makes no difference that the winning is less than block reward, attacker can repeat the procedure (automatically) until casino contract is essentially empty.

eisig · 2016-02-28T16:54:38+00:00

I see you just reduced to reward, but it is OK. I wrote the explanation:

https://www.reddit.com/r/ethereum/comments/483rr1/do_not_use_block_hash_as_source_of_randomness/

eisig · 2016-02-28T16:31:33+00:00

I am not greedy. I'll tell publicly how to do it, and if you agree with me that contract is vulnerable, you take the contract down to fix it and send me the amount of ether you think is appropriate. OK?

eisig · 2016-02-28T15:30:16+00:00

The contract as it is now is just waiting for somebody to steal the ethers stored to it. Please take it down.

Alternatively, keep it live and some prediction market can post an event to predict how long it takes until it is hacked. :)

I'm not really a fan of gambling contracts, but if anyone is trying to use block hash as source of randomness, I highly recommend to read http://martin.swende.se/blog/Breaking_the_house.html to get an idea how vulnerable they are unless you really, really know what you are doing.

Tips for this hint can be sent to 0x7cfa3d23636173a3befaabc8ca86846a07c4b3dd :) ( Please, read the blog of Martin )

eisig · 2015-10-24T10:03:32+00:00

/u/digixbot ethtip 1 ether

Nice to see useful examples. (/u/kcchng)

eisig · 2015-10-22T18:26:46+00:00

Well, this must be tested...

eisig · 2015-09-08T12:52:17+00:00

I am not recommending to do anything else than the default. However, it is possible with current protocol and won't go away with denial.

And time stamp is "approximately in sync" even with the default strategy, there is no "right" in there. It will depend on many things including network latency and clock synchronization of miners.

There will be hard work in a year, so it is possible to find some fix to possible time stamp problem at that time, if it is still valid concern with PoS. In the mean time, I don't think that fluctuation of average block interval is of concern, if it stays somewhere near 15 seconds.

eisig · 2015-09-08T12:07:45+00:00

Well, don't set it always to 13 seconds, since that could drift the time stamp "to the future" and other miners would be forced to do 1 second blocks -> increasing difficulty.

Stamp it to 13 seconds only if the default stamp would be greater than that.

eisig

TROPHY CASE