No duplicate addresses on different chains

[jamesray1]

No description provided.

[realcodywburns]

Addresses don't really matter that much. If you hold the private key to an address you have the same address on every chain. Same with contracts. contract addresses are derived from addresses so if you want to launch a contract on multiple chains that do the same function, you can. Similarly, if you do not want your contract address to accept coins on another chain you can deploy a blocking contract at that address. EIP-155 allows for replay protection so reusing addresses isn't really an issue

[jamesray1]

Hmm, what you say makes sense, but then it seems that the example in #867 is misleading.

[realcodywburns]

The example is poorly explained. In the example a company is releasing many contracts on main net from the same address(0xdeadbeef) so on main net the nonce of 0xdeadbeef(5) is higher than on testnet(3). So when the company put out the "testnet" contract address it was derived from sha3(0xdeadbeef+3). Since the mainnet address is at contract address sha3(0xdeadbeef+5) there is no way to publish the correct contract at the correct address. This is a responsibility that would fall squarely on the "company" and any real business should have insurance against.

The way to avoid this is to meticulously keep track of which contract is launched at which nonce. It isnt difficult and is easy to do if they are focused on producing good code rather than rushing something out the door to make a quick buck.

Example:
Contract 0xd975caab131d730d174ac445dfedf8fc3127dabc

Users send ether it is held for 5 blocks before they can withdraw. Didn't want users to lose coins if they sent to wrong chain so it is cross deployed on all chains one can reach on myetherwallet.

Deployed on:

Eth

Etc

Ellasim

[jamesray1]

Sorry for the delay in replying. I turned off notifications because I was getting many! It seems there is no option to get notifications for posts that you create and nothing else. I've turned notifications on now, set to "Not watching".

What you say is reasonable and the contract also is simple and looks functional, although I haven't tested it, and there is only one transaction, the contract creation.

[phiferd]

Yes, it could be the example was poorly constructed or poorly explained (or both). I will consider using a different example.

I intentionally tried to avoid making the example too similar to any known scenario because I didn't want people to think the proposal was about that particular issue. The example was supposed to show a situation where funds are provably stuck.

Again, maybe I'm wrong and I'm sure the explanation could be improved, but I do think the funds would be stuck in that scenario. In any case, maybe I can think of a better example.

[jamesray1]

I understand, but it may be difficult to find a novel example that is worthy of being considered recovering funds. So you may just want to give one of the existing examples or just provide the link, and simply state that these previous issues could all be considerable for recovering funds, for want of awareness of any other undiscovered or inconceivable bug, or until some other bug is proven.

As Cody pointed out and explained your example in more detail, it would be possible to create stuck funds, but this would be caused because of the contract developers.