Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Nick Johnson
@Arachnid
No, because it's not just a wallet. He can potentially send it instructions from any address.
infamousrev
@infamousrev

so your basically saying that anyone can control the darkdao, no matter if they have access to his private key or not?

That does not sound right,

My proposal is to patch the code, so that the validly signed transaction is rejected IF is one of the known attacker wallets public-key hash

Nick Johnson
@Arachnid
No, only the attacker can control the dark DAO
But he can do it from any source address he likes.
I haven't examined the attacker's code myself, but I imagine it verifies signed instructions against an embedded public key. Which means that the origin address does not have to be the attacker's known wallet address.
(There are other schemes that would provide similar functionality to the attacker, allowing him to send instructions but nobody else, without forcing him to use a particular account)
infamousrev
@infamousrev
but the darkdao will only accept the split instructions from an address that contains darkdao-tokens right?
Nick Johnson
@Arachnid
Yes, but the address that contains the tokens is a contract, not an external account.
guillv
@guillv
Hi all,
I have a problem mining transactions on a private blockchain. I posted details here : http://ethereum.stackexchange.com/questions/6577/how-to-send-transactions-to-a-private-network
But apparently I'm doing things right. Does someone have any idea where the problem might be ?
infamousrev
@infamousrev
Hmm, I understand what you mean now
Péter Szilágyi
@karalabe
@chfast I know. 1.4.6 was the big sync release which included among other the tx blocking until a sync cycle completes. We need to block transactions to prevent constantly executing them when the node joins the network as during initial sync a node can pile up thousands of transactions, all trying to constantly validate but not possible due to having a too old state. The initial sync cycle completes either when you get at least 1 new block from the network. If you run a private network with no miner, then transactions won't propagate, that's true, but it'a a corner case we figured can be lived with, given that there's not much point in running such a scenario.
@guillv Hmmm, I have a hunch what might be the problem. Let me look into it
IT might be an unexpected corner case in the above mentioned sync cycle logic. If you have a single miner, that node will never get new blocks from the outside, so it might never consider itself completing the initial sync cycle.
I'll check, but possible we need to add an extra clause to force the cycle complete after mining a block locally.
infamousrev
@infamousrev
@Arachnid Do you have a link to the contract that controls the darkdao tokens?
Nick Johnson
@Arachnid
Not offhand, but it should be easy to dig up
The source isn't available, of course.
infamousrev
@infamousrev
yes but I should be able to read the op-code if its not too large
guillv
@guillv
@karalabe ok so if I try to mine with another node (in a virtual machine bc i can't mine on android) it will unlock the transactions ?
or should i downgrade my client to a version < 1.4.6 ?
shenfeizi
@shenfeizi
one short question which has puzzled me for sometime. There are two 'gas limit' in Ethereum, right? one is for single smart contract and another is for the whole block. Gas limit for the whole block sets the upper limit of all transactions inside that block. My question is how to find those two parameters in geth?
trial2try
@trial2try

the recent version of geth has depreciated the use of --genesis genesis.json.. And it is prompting me to use init path/file name.. In my genesis.json i have allocated money for my account.. It worked when i used --genesis.. using init my balance is not getting set to the balance specified in the genesis.json file..

Can anyone help me out with this?

HelixiR
@HelixiR
E0629 11:55:46.617669 core/blockchain.go:1128] Bad block #1788997 (0x4b30a68d9fadc5e11cdb7ef38ab5871b211bce7ec66d81aa15b972955c78c0d4)
E0629 11:55:46.617689 core/blockchain.go:1129] invalid receipt root hash. received=8d02eb49065de266dec43a0c279c6902db8c13c896d8a12c05bd0128229e3adf calculated=d28d156461295ada771c34b7c651e0bf4cc124a8436bb0b8f4564f658b746927
oO wtf?)))
Péter Szilágyi
@karalabe
Seems some miner made a bad block, propagated it and was rejected by your node
If you check etherchain, that block number has a different hash
HelixiR
@HelixiR
and node stopped? why just not marked "orphan"?
Péter Szilágyi
@karalabe
Stopped? It shouldn't stop
HelixiR
@HelixiR
Not crashed, but in cycle send me this in console (and dont sync any blocks)
i restart node manually
Péter Szilágyi
@karalabe
if it does something like this again
please in a console do
debug.vmodule("downloader=6")
the downloader should drop malicious nodes who try to feed junk
curious why it didn't drop this peer in your case
HelixiR
@HelixiR
Don't know why. I have two nodes on pool, and two down --
geth 1.4.8 with softwork enabled.
Paweł Bylica
@chfast
@karalabe that's actually the case I have. Thanks for fucking it up with a minor release.
Péter Szilágyi
@karalabe
it's a feature, and you're very welcome
guillv
@guillv
@karalabe Thanks for your help earlier. You were right the problem was I only had a single miner so I added a second and now both miners can mine transactions from other nodes.
Paweł Bylica
@chfast
@karalabe Working around features is my hobby. One last question, does the new block has any requirements? E.g must be not older than 1 min?
Péter Szilágyi
@karalabe
Geth is usually designed to handle the Ethereum mainnet requirements. This sometimes can lead to some unfortunate breakages in scenarios we didn't consider (e.g. a blockchain with no blocks being mined, or @guillv 's reported issue with a single miner). People relying on non-canonical behavior report it and we fix it. Simple as that. No need to get angry because we broke an unusual corner case.
The requirements are either to complete a sync cycle with a remote node (i.e. the other node has to have a heavyer chain), or to receive a new block that's relatively close to the current chain head (e.g. -7 or perhaps -32 is the limit, not sure)
Péter Szilágyi
@karalabe
Btw, I do agree that it should be fixed so that we can do something meaningful for this cornercase too, looking into it now
Henning Diedrich
@hdiedrich
Maybe setting up a small private net with one miner is not a corner case but how many people will be developing to not have to use ether for it. It's unlikely that a network with zero blocks or one miner is something in production.
Péter Szilágyi
@karalabe
The one miner issue is easy-ish to fix, already done it (just assume sync completed if mining is started)
The scenario where a network is live but no blocks are being minted is a bit unorthodox
will need to think about that one
infamousrev
@infamousrev
From what Ive understood the Dao attacker controls the dao-tokens using a proxy contract like pointed out to me earlier today, that sort of invalidates my earlier idea of censoring based on wallet address/private address, however I can still see the feasability if combined with my earlier idea. so basically blacklisting for 24-hours tx.origin JUST in case of a successful call to the DarkDao by the attacker wallet address. This will limit the attack surface of the ddos attack from every dao-holder to just the dao-attacker. It will also cause the attacker to have to spend about 200.000 gas to be able to burden the miner with GASLIMIT amount of gas of extra load, because he will have to whitelist an new address in his proxy contract (as to my understanding), and then try to ddos with this new address, and repeat this every time he wants to put ddos pressure on the network. This will allow the attacker to put CPU load on the network about 20x cheaper then normal, but not for free. If we were to lower the gas limit to 2.000.000 his multiplier would be reduced to only 10x. This will force the attacker to spend resources to be able to sustain the attack (which he might not have a lot of), and if the miners prioritize low gas transactions it might be possible for the network to operate normal even while under attack. We could also limit the duration of the censoring to just the time needed for the whitehats to use the same exploit to drain the darkdao without the attacker being able to join the split