Should core bitcoin developers freeze stolen Mt.Gox bitcoins?

[jonald_fyookball]

Bitcoin need to be more user friendly. It is true that mostly those who are tech-savy use Bitcoin and cryptocurrencies. We need to introduce Bitcoin in a way that even someone who knows nothing about technology etc can use it.

I agree Joshuar!  I think the atmosphere is good for market-driven entrepreneurs to deliver solutions that are user-friendly for the masses.

[Dr.Zaius]

If a coin freezing mechanism exists, or if a certain group holds some type of black listing rights, the value of a bitcoin will go to zero.

Bitcoin has no value outside of exchange. If you modify its fungibility it becomes worthless.

[tvbcof]

Bitcoin need to be more user friendly. It is true that mostly those who are tech-savy use Bitcoin and cryptocurrencies. We need to introduce Bitcoin in a way that even someone who knows nothing about technology etc can use it.

Sure.  The same can be said for a manned submersible capable of diving to 1000 feet.  The bad news is that it is not ever going to be a good idea to give a retard a submersible.  The good news is that it is really not necessary for such a device to be 'successful.'

I agree Joshuar!  I think the atmosphere is good for market-driven entrepreneurs to deliver solutions that are user-friendly for the masses.

There really is no solution to ignorance, and the deck is stacked against the average Joe successfully keeping his data private (specifically, his secret keys.)  Sad news:  It's not getting any better.

'Market-driven entrepreneurs' have been hard at work for a long while coming up with 'user-friendly solutions for the masses.'  Inevitably they have, and probably always will, involve handing one's BTC over to the proprietor for 'safe keeping'.  The results have been as expected.

There is a huge market segment for 'market-driven entrepreneurs' to interact with one another in a reliable manner.  The thing which differentiates this class of users from 'the masses' is that they are perfectly capable of watching out for their own asses and not getting ripped off.  For this reason Bitcoin would be a perfectly suitable solution to fill this segment.  Bitcoin has a natural edge should it target this segment and still has the chance to be successful here.  If it neglects or fails to do so, something other crypto-currency will end up filling this void.

[ArticMine]

No.

[bryant.coleman]

Bitcoin need to be more user friendly. It is true that mostly those who are tech-savy use Bitcoin and cryptocurrencies. We need to introduce Bitcoin in a way that even someone who knows nothing about technology etc can use it.

+1.

There should be a simple and secure way to store the coins, without the risk of robbery. We should advertise the benefits of Bitcoin to common people, such as low fees and protection from inflation among other things. If we really want Bitcoins to go mainstream, then we should aim for at least 20% of the world population by 2025.

[drawingthesun]

OP, what you're suggesting isn't possible in Bitcoin by design. The blockchain can't just be altered by the dev team in the manner that this scenario would require.

The block which contains the MtGox transfers also contain numerous other legitimate transactions that occurred around the same time period before that block was solved.

The hash of a block is a long string of characters representing the entire hash of the previous block, a time stamp of when the current block was created, and all of the transaction data contained within the current block. If a single transaction is changed, the resulting block hash will be completely different. When a block is solved, a new block is instantly created and the cycle is repeated.

All of the blocks solved from then up until now rely on the hash of the block containing those MtGox transactions. Every block is dependent on the data contained within the previous block remaining concurrent. Changing something in a past block would cause a cascading failure event. The change would be rejected.

Each and every block uses the hash of the previous block in its algorithm. If you change the content of a block, the hash changes with it. If the hash of the next block does not check-out against the hash of the previous block it will be discarded. The blockchain from that moment forward and every transaction that occurred from that block onward would need to be reverted as if it never happened for such a change to be accepted...

The protocol will not allow the coins to be "frozen" since the act of freezing them would destroy the concurrency of a known good chain where the inputs and outputs are proven. The alteration would be discarded the same as a "double-spend" attempt.

Bitcoin can't do what you're asking it to do regardless of what the core devs think about the Gox situation... Bitcoin has no conventional "core" in that unilateral "source-code" alterations are not possible. If the community wishes to implement an improvement they must do it by consent. Community consent has limits in that it still doesn't mean they can change the content of a previous block. Improvements can only be implemented from an unsolved block onward. The only way to go back would be to discard all transactions that took place in the chain between the block in question and the current unsolved block.

Bitcoin isn't about Anarchy, it's governed by the most absolutely infallible system of law on the planet; math... The problem with math is that it cares nothing for emotion. If you have unspent outputs and the private keys to control them; nobody can stop you from spending them. That's not Anarchy, that's equality and neutrality...

Not that I agree with the idea of the OP, but technically it is possible no?

The updated patch in the main client will have code that checks for the stolen addresses and does not verify any block that allows them to move after a certain date in the future (perhaps next week). This will force the miners to either fork or accept the patch and choose not to allow the funds to flow.

The code would simply not accept a block that has a transaction from the known stolen funds addresses after a certain date.

I don't agree with that, but it's still possible, no need to go back in time and fudge the chain up.

[Nagle]

Freeze, no. Alarm, maybe.

It might be useful to have a program watching the block chain and posting widely (Twitter, perhaps) when there's a transaction involving stolen coins. And sites which want to check the stolen coin list should be able to do so. 

[tvbcof]

Freeze, no. Alarm, maybe.

It might be useful to have a program watching the block chain and posting widely (Twitter, perhaps) when there's a transaction involving stolen coins. And sites which want to check the stolen coin list should be able to do so. 

It is almost certain that checking with such a tainting authority as you describe will be mandatory to obtain a 'Bitcoin License' and it won't matter a whole lot how bogus the tainting authorities analysis happens to be.  At least the legislators will be able to claim than they are doing something about the 'problem'.  Call it what you like, but this is a direct attack on fundamental fungibility of the Bitcoin monetary solution.

Tainting is potentially an entirely separate system to the actual Bitcoin protocol and it's probably the biggest failure mode risk for the Bitcoin solution.  To the extent that the 'core developers' will have much to do vis-a-vis 'tainting', it would likely be along the lines of adapting the protocol to make tainting more of a challenge as a matter of self-preservation.

[BurtW]

It is almost certain that checking with such a tainting authority as you describe will be mandatory to obtain a 'Bitcoin License' and it won't matter a whole lot how bogus the tainting authorities analysis happens to be.  At least the legislators will be able to claim than they are doing something about the 'problem'.  Call it what you like, but this is a direct attack on fundamental fungibility of the Bitcoin monetary solution.

Tainting is potentially an entirely separate system to the actual Bitcoin protocol and it's probably the biggest failure mode risk for the Bitcoin solution.  To the extent that the 'core developers' will have much to do vis-a-vis 'tainting', it would likely be along the lines of adapting the protocol to make tainting more of a challenge as a matter of self-preservation.

Well said.  Hear, hear!  I coinjoin all my transactions now.  So should you - and by you I mean everyone that is reading this and everyone that uses Bitcoin.

Ideally we can get coinjoin or some variant of it into the code and coinjoin all transactions automatically.  This would make taint analysis pretty much impossible for all practical purposes.

I wish that the protocol was designed to join all transaction at the blocks from the get go but here we are.

[BurtW]

If you want to see Bitcoin succeed and wish to support it here is what you can do:

1) Run a full node
2) Coinjoin all your transactions.  Multiple rounds even better.
3) Stop reusing addresses.  Use a different address every single time!
4) USE BTC to buy things when you can.
5) Mention them to vendors.  Every time I buy something I ask if they take Bitcoins as a payment method.  You don't have to explain the whole thing to them just ask.  If enough people ask that in itself will get them to wonder about it.  If they ask you about it then you have an opening to chat with them about it.

[drawingthesun]

Have they solved the problem with CoinJoin where the accumulator could leak who wanted what to go where?

[pungopete468]

OP, what you're suggesting isn't possible in Bitcoin by design. The blockchain can't just be altered by the dev team in the manner that this scenario would require.

The block which contains the MtGox transfers also contain numerous other legitimate transactions that occurred around the same time period before that block was solved.

The hash of a block is a long string of characters representing the entire hash of the previous block, a time stamp of when the current block was created, and all of the transaction data contained within the current block. If a single transaction is changed, the resulting block hash will be completely different. When a block is solved, a new block is instantly created and the cycle is repeated.

All of the blocks solved from then up until now rely on the hash of the block containing those MtGox transactions. Every block is dependent on the data contained within the previous block remaining concurrent. Changing something in a past block would cause a cascading failure event. The change would be rejected.

Each and every block uses the hash of the previous block in its algorithm. If you change the content of a block, the hash changes with it. If the hash of the next block does not check-out against the hash of the previous block it will be discarded. The blockchain from that moment forward and every transaction that occurred from that block onward would need to be reverted as if it never happened for such a change to be accepted...

The protocol will not allow the coins to be "frozen" since the act of freezing them would destroy the concurrency of a known good chain where the inputs and outputs are proven. The alteration would be discarded the same as a "double-spend" attempt.

Bitcoin can't do what you're asking it to do regardless of what the core devs think about the Gox situation... Bitcoin has no conventional "core" in that unilateral "source-code" alterations are not possible. If the community wishes to implement an improvement they must do it by consent. Community consent has limits in that it still doesn't mean they can change the content of a previous block. Improvements can only be implemented from an unsolved block onward. The only way to go back would be to discard all transactions that took place in the chain between the block in question and the current unsolved block.

Bitcoin isn't about Anarchy, it's governed by the most absolutely infallible system of law on the planet; math... The problem with math is that it cares nothing for emotion. If you have unspent outputs and the private keys to control them; nobody can stop you from spending them. That's not Anarchy, that's equality and neutrality...

Not that I agree with the idea of the OP, but technically it is possible no?

The updated patch in the main client will have code that checks for the stolen addresses and does not verify any block that allows them to move after a certain date in the future (perhaps next week). This will force the miners to either fork or accept the patch and choose not to allow the funds to flow.

The code would simply not accept a block that has a transaction from the known stolen funds addresses after a certain date.

I don't agree with that, but it's still possible, no need to go back in time and fudge the chain up.

I can understand why one might think this is a reasonable method of stopping the transfer of these coins.

There is a major flaw here though... The coins are identified by the outputs of every single Satoshi. The velocity of Bitcoin is high enough that there will likely be outputs in every future Bitcoin transaction that can link back to one of those addresses.

You would be blocking nearly every block from that moment forward. Since you can't just reject the outputs of a single Satoshi from being included in a block the entire block would need to be rejected...

For instance; if you own Bitcoin today, then the chance of owning the output of at least 1 Satoshi from the Laszlo Pizza purchase is close to 100%.