Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:49
    Travis ethersocialcoin/go-esc (develop) still failing (745)
  • 16:07
    Travis firewicca/go-ethereum (master) errored (68)
  • 15:31
    stale[bot] unlabeled #18984
  • 15:30
    adamschmideg labeled #18984
  • 15:27
    stale[bot] unlabeled #18243
  • 15:27
    adamschmideg labeled #18243
  • 15:22
    stale[bot] unlabeled #18228
  • 15:22
    adamschmideg labeled #18228
  • 15:21
    adamschmideg closed #18209
  • 15:21
    adamschmideg commented #18209
  • 15:19
    adamschmideg closed #18198
  • 15:19
    adamschmideg commented #18198
  • 15:18
    adamschmideg labeled #20699
  • 15:18
    adamschmideg edited #20699
  • 15:15
    adamschmideg edited #20720
  • 15:15
    adamschmideg opened #20720
  • 14:44
    adamschmideg labeled #20719
  • 14:43
    adamschmideg opened #20719
  • 14:36
    adamschmideg edited #20718
  • 14:35
    adamschmideg edited #20718
Tim Coulter
@tcoulter
Does this error message represent an issue with my version of go-ethereum or simply bad data sent from a peer:
E0628 23:59:49.976830 core/blockchain.go:1128] Bad block #1789821 (0x32f861ad6119f74212ea75b9f3979d306792195d114c02a1857beb257c51a03d)
E0628 23:59:49.976864 core/blockchain.go:1129]     Transaction w/ invalid nonce. tx=357  state=358)
Another similar one:
E0628 23:49:42.059413 core/blockchain.go:1128] Bad block #1788997 (0x4b30a68d9fadc5e11cdb7ef38ab5871b211bce7ec66d81aa15b972955c78c0d4)
E0628 23:49:42.059439 core/blockchain.go:1129]     invalid receipt root hash. received=8d02eb49065de266dec43a0c279c6902db8c13c896d8a12c05bd0128229e3adf calculated=d28d156461295ada771c34b7c651e0bf4cc124a8436bb0b8f4564f658b746927
infamousrev
@infamousrev
Hello, thinking about it I think the best fix for the soft-fork ddos problem is: instead of filtering based on code analysis we should simply blacklist the wallet addresses of the known malicious actors in the darkdao's and whitehatDao, this will allow the whitehats to do a exploit-drain-split without the attackers being able to join the split
infamousrev
@infamousrev

Hello, thinking about it I think the best fix for the soft-fork ddos problem is: instead of filtering based on code analysis we should simply blacklist/censor the wallet addresses of the known malicious actors in the darkdao's and whitehatDao, this will allow the whitehats to do a exploit-drain-split without the attackers being able to join the split

This method will not create the ddos problem, is still a softfork and still allow us to secure the dao funds.

This a about it: miners already have to verify if a transaction is made by the real owner of the private key,
And only the people with the attackers private key can execute the blackhat attack
Why dont we interfere in that stage of the process, and say, attacker private key != valid, from the softforked miner point of view, it should not introduce additional ddos problems
infamousrev
@infamousrev
Sorry for double posting, my browser did not show the first post
infamousrev
@infamousrev

They can only execute a DAO operation from the address that currently holds their DAO tokens.

The whole reason the dao attacker can steal the funds, but not some random bystander, is because the Dao attacker has the privatekey to the wallet address controlling the dao tokens in the darkdao. If we make a softfork that temporarily ignores all transactions made by this wallet address it prevents them from doing the attack. And the whitehats can now use the same exploit against them to recover the funds (Because the whitehats also have dao tokens in those daos).

This will not introduce the same ddos attack vector because it does not require the validator to parse the code before rejecting the signature. It will have the same result as when a transaction with a genuinely invalid signature is broadcasted, such a transaction also removes no gas from any wallet.

infamousrev
@infamousrev
This solution assumes we can implement the softfork while the darkdao and whitehatdao is still in the creationfase, meaning they cannot move the tokens to a different address just before the softfork activates because they are frozen (that is my understanding)
infamousrev
@infamousrev
@/all Any idea when most ethereum devs wake up? It would be nice to receive a reply if this solution would be viable or if I should try and think of something else
Nick Johnson
@Arachnid
@infamousrev Please don't try and ping all in this channel.
We looked into that, but unfortunately the attacker's tokens are controlled by a contract, and the contract is configured such that it can be called from more than just a short whitelist of addresses.
infamousrev
@infamousrev
yes, but the attacker will need to send a call-transaction to the contract signed by the wallet owning the tokens to be able to use them right? So if that fails, then the attacker has just as much control over the darkdao as a random individual, which is none
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