It might be a good idea to see what problem you are trying to solve. It's quite dangerous to have a command that nukes private keys from your wallet, because that is how people shoot their feet off.

Have you verified it understands *any* P2SH address? I had problems in the past with bc.info not understanding P2SH.

Unfortunately the wallet silently fails, so you lose any privacy benefits if it can not connect.

I think connecting to a Tor hidden node makes more sense for now, since it's already authenticated and encrypted. The wallet currently doesn't connect to those though.

Merge-mined sidechains require a fork too! 

I guess a federated sidechain could do it.

Have you discussed this scheme with hardware wallet makers?

It'd be great if there were any way possible to get this to work with Trezor/Ledger, but I'm unaware of their ability to do symmetric encryption schemes.

Otherwise, it seems quote well-thought out.

You're 100% right. bc.info is not a safe wallet. Javascript/password based wallets are dangerous, and bc.info doesn't have a great track record.

That's not clear at all. We need, at a minimum, a majority of *active* hashrate to not "attack" the network. 

Your economic theories aside, there is very little consensus on how we will achieve this.

I'm an optimist. I'd like to think that regardless of block size, a million people will donate a little bit of hashing on their USB sticks at a loss leading to an extremely hard to censor network. The other equilibrium aren't nearly so clean.

The key is all those fees will just be going towards non-hashing. Security of network will most likely die with an infinite blocksize unless a minimum fee is imposed by miners via soft-fork.

Check his claims history. Big waster of time, historically.

For clarification: Do you mean port the GUI/wallet parts into different languages?

Porting consensus code would defeat the whole purpose.

Using OP_RETURN for embedding data for a colored coin like system is called "embedded consensus systems". The data could just as well be junk.

You don't get to use miners to enforce validity of these "transactions", so you have to verify it yourself as a user of the system. 

https://bitcoin.org/en/developer-guide#consensus-rule-changes 

bitcoin.org documentation explains it quite nicely.

I am also writing up a blog post Soon^TM to rephrase and give some history.

I totally believe you. Dang it where's my sarcasm font?

This attack will probably always be viable in some sense once the rapid pace of ASIC development slows down to a (relative) crawl.

When dark hashpower is >> hashrate, anyone can buy and spin up hardware, with the marginal cost being electricity.

Groups will most likely hold onto miners even if they aren't being used in case the hashrate dips too much or they get invested in a block race.

Core dev work is *almost* orthogonal to making it go "mainstream".  

It's like arguing TCP/IP developers aren't doing enough to make Facebook go viral.

You want Core devs to make sure the core consensus mechanism is humming along. Almost nothing else. 

edit: The blockchain is to give a partial ordering off data published. Nothing else. It's not magic.

1) Send in your 2 weeks notice. 

2) Tell your family you love them. 

3) Turn yourself in for theft.

lmao this thread.

I'm guessing the pixel values were mutated until a collision occurred, right?

Some stuff: http://stackoverflow.com/questions/933497/create-your-own-md5-collisions

A large pool/ASIC group could grind blocks until they get blocks that steer it to something they like.  

Pool is good at hashing alg X. It's at Y, which is close to X, giving an advantage. They decide they will only release blocks if it moves it closer to X. Once X is achieved they own the dominant hashing power by manufacturing fiat.

But also, as mentioned before, you're going to get naturally bad PoW algorithms that don't scale correctly, or take too long to verify, etc. Even without "malicious" actors you're going to possibly get crazy behavior.

I might be wrong, but in the short term it's not as big a deal that regular nodes get these IBLT stuff. Full nodes care much less about ~15 seconds of latency.

Long term it might make sense.

There have been similar proposals before to do this, but it isn't immediately clear it's wanted, or that it provably will stop ASICs. 

Also it may lead to people trying to steer the next function into functions it can do better than competition.