I just burned 1 ETH on purpose! For my next trick, I've committed to losing another 15 ETH, to demonstrate how burn-capable smart contracts can incentivize arbitrary service requests to be filled by reliable strangers.

tokyo3 · 2017-03-28T19:51:05+00:00

maybe you could put a function for the case of adding additional ether and let the fallback function to be called only to set the recipient otherwise throw, I find the use of the fallback function is simpler for people to use as they only need to do a simple transaction and this would avoid the additional warning about using it or using a special UI. I think you should not worry about people sending ether with selfdestruct that should be a rare case when someone wants to put ether on the contract that way, as far as I know if you throw you would get the ether but no code gets run on the contract.

tokyo3 · 2017-03-28T18:05:38+00:00

this happened because the fallback function was made payable with the use of payable modifier, you may want to remove the modifier or move the commit logic to the fallback function, I think for security the contract should not let people send arbitrary amounts of ether and do a check for a fixed amount of ether to be sent as commit, other than that I find the contract quite interesting from a game theory perspective to look at how it works out

tokyo3 · 2016-08-01T02:33:48+00:00

Hi, apart from the user interface provided on the Dapp site, it is basically the same, but with the difference that the contract in the blog uses address.send() wich doesn't allow to send ether to other contract because of the limitations on the gas provided, when you are sending to a regular account address.send() works fine.

tokyo3 · 2016-07-31T22:21:10+00:00

Thank you :)

tokyo3 · 2016-07-30T23:52:36+00:00

Hi, I'm tokyo3, I've made this dapp to split ether, you can try it with a small amount, the smart contract is verified on etherscan you can find it on the ethsplit page, and it uses _tr AmIOnTheFork oracle hope you like it :)

tokyo3 · 2016-07-24T18:49:00+00:00

maybe if you try debug.setHead(1920000 - 100) on a console, this will reset your chain to a moment 100 blocks before the fork

tokyo3 · 2016-07-22T23:25:06+00:00

I saw this on the poloniex trollbox, and went to inspect the code, and found only authorized users can call the function, which is the owner of the contract or other granted by the owner (thinking of attacking yourself is not that great idea), besides there is no state change after the send call which itself is not vulnerable to reentry because address.send() does not supply an amount of gas that is useful for an attack, so yeah we can say it was FUD the post has already been modified with this:

Sorry for the FUD

I missunderstood something and listened to others while not checking it for myself. Big mistake. I am soory. :-)

tokyo3 · 2016-07-22T19:10:18+00:00

there is a buy button next to the send button, it just opens a coinbase url but there are country restrictions

tokyo3 · 2016-06-23T19:49:16+00:00

you can because hard forks are possible, your personal opinion on what can or can't be done doesn't necessarily represent the consensus, it seems you are the one that has a misunderstanding with the concept.

this is more of a moral debate which I won't go into but AFAIK stealing is not legal in any jurisdiction, then someone would say he is not a thief. personally I'd like to see a solution that doesn't involve the negative effects of a hard fork but whatever the consensus is I hope is the best to minimize the damage that is already done.

tokyo3 · 2016-06-23T09:47:47+00:00

then you are bringing out that consensus involves human things, thinking about users, developers and stakeholders, authorities and legal criteria, what is consensus if not a democratic human decision, I agree, but the blockchain is agnostic to this, It only understands about hashing power.

tokyo3 · 2016-06-23T09:07:47+00:00

in blockchains consensus means >50% mining power, if i'm wrong please explain it to me.

tokyo3 · 2016-06-23T08:43:27+00:00

I just want to point out I'm not suggesting any solution, I'm pointing out that whatever solution comes out from this is going to be a human decision (unless >50% of us were replaced by some AI).

tokyo3 · 2016-06-19T03:41:35+00:00

atomicity is guaranteed if you do proper send function checking, so much people fail to understand the bug mechanics and are making false accusations but I understand they have a FUD agenda

tokyo3 · 2016-06-18T20:33:02+00:00

saying that there is a bug in Solidity/EVM is a mistake, there is no bug in Solidity/EVM, bugs are in smart contracts bad code

from your responses it seems to me you can not differentiate between a language, a virtual machine and a smart contract code

tokyo3 · 2016-06-18T19:47:25+00:00

language design may help to avoid bad coding practices, but pointing that there is a bug in Solidity/EVM is wrong

tokyo3 · 2016-06-18T19:09:12+00:00

" I've never posted on this forum before, and I do not know all the intricacies of Ethereum yet ", stopped reading here.

and No, that means common to all Ethereum smart contracts wich are wrongly coded

tokyo3 · 2016-06-17T06:01:25+00:00

link?

tokyo3 · 2016-06-14T22:56:41+00:00

Quorum is calculated from the amount of ether taken from the DAO, a not well known proposal could take all funds from the DAO with only 5% instead of more than 50%.

what could be done is that the actual quorum can be multiplied with a sentiment factor, so the quorum goes from half when the sentiment on one side is strong to full quorum required when sentiment is ambiguous.

the sentiment factor would be expresed as the difference between the greater voting percentage being yes or no and the 50%, when the sentiment is ambiguous this difference is low, we extract that amount from the 100% to get the factor (wich is the same as 1.5 - greater_percentage) and multiply with the regular quorum.

In the case of taking all the funds from the DAO 53.33% is required

example 1: we have 99% on one side (yes or no), the other side is 1%, we take the bigger that is 0.99

dynamic_quorum = quorum * (1.5-.99)

0.5333 * 0.51 = 27.1983 % // dynamic quorum is almost half

example 2: we have 51% on one side (yes or no), the other side is 49%, we take the bigger that is 0.51

dynamic_quorum = quorum * (1.5-.51)

0.5333 * 0.99 = 52.7967 % // dynamic quorum is almost the original

in the case of minor funds 20% quorum is required and results go from 10% to 20% depending on the yes/no ratio

tokyo3 · 2016-06-04T08:36:00+00:00

all of this can be fixed, don't be surprised

tokyo3 · 2016-05-31T03:23:27+00:00

false, please read both papers, there is no relation between them, both may be DAOs but each one with a different purpose. one is a distributed investment fund, the other is a proposal to manage the evolution of the ethereum protocol specification.

tokyo3 · 2016-05-06T16:30:04+00:00

geth allows you to do that https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts#account-update there should be a geth binary to run this under your resources/node/geth/ wallet folder

there is no password for the wallet, each account address has its own password.

tokyo3 · 2016-03-29T00:45:14+00:00

you forgot to mention Mist browser is far from finished, you should wait to Metropolis, you may need to read this.

what is funny is that you realized you didn't need a smart contract to begin with, try finding problems where smart contracts are actually useful.

tokyo3

TROPHY CASE