AntonyMint.

I come from a more technical background, but I do believe I understand the economic implications of the Bitcoin technology and I do also clearly see the point you are trying to make with your attack.

I do however believe that your attack is not viable in the long run...or rather, it's negligible.

There are, I think, two possible scenarios of how the cartel could withhold the transactions from the rest of the network, and a hybrid approach using both depending on whether the transaction is internal to the cartel network or not.


1) The cartel wallet would only connect to nodes that use the same wallet. The only part of this segregated cartel part of the network that would connect to the complete Bitcoin network would be the mining servers. They would be configured to farm all attractive transactions, while not forwarding any to the rest of the network, effectively keeping the transactions from their cartel nodes for themselves.

I suppose this is a rather unrealistic scenario on the technical front, as only a single ill-behaved node in the cartel section of the network sending transactions to a single member of the non-cartel part of the network would propagate most of the transactions from the cartel network onto the non-cartel network before being mined. A few of these nodes - and I don't doubt someone in the Bitcoin community would make it happen - and the networks would effectively be joined again. So let's move on.


2) I would assume that the scenario you have in mind would involve a custom cartel wallet, that directly sends the transactions to one or several cartel mining servers. At the same time, the cartel mining servers would exchange transactions. In this case, the only connection that allows the cartel part of the network to siphon revenue of the non-cartel part of the network are the mining servers of the cartel, and they are effectively the only part of the cartel network that is actually operating as Bitcoin nodes.

Effectively, this would stop the cartel wallet software from enabling transactions to the rest of the network. In this case, I would argue that the cartel would basically implement an off-chain payment system, which additionally records transactions on the blockchain with a delay. This comes down to nothing but blockchain bloat.


The real issue with your attack is, though, that, as long as any one node of the cartel network is running the Bitcoin protocol on some level, the transactions can be funneled back into the non-cartel network quite easily. As soon as the cartel tries to control its own part of the network to an extent where the nodes are no longer part of the Bitcoin network, they will de facto implement their own payment network with their own hybrid Bitcoin/cartel wallet. Personally, I would then consider the fees to be cartel fees, not Bitcoin fees. As they will also require proportionally more hashing power to verify their own transactions, their take from the Bitcoin network would not really create an imbalance in my view.

The question then is, at what point do you still consider fees attached to such a transaction as revenue of the Bitcoin network. Basically, on a basic level, what you are saying is that somebody who makes additional profit (in any way) can use those profits to increase their share of the mining power in the network. This is already possible nowadays, in much simpler ways than through your attack scenario.

Basically, your attack falls apart the moment other factors than just the revenue from mining play a role. As Bitcoin miners are likely to find other applications, such as heating, or - as mentioned by posters before - can be paid by some other company to keep mining while prioritizing their transactions, they will generate extra revenue, too, which, in turn, they can also use to increase their share of the mining power in the network. In fact, every big mining player will strive to diversify his income streams. I would even say that a lot of big mining operations will not solely be mining businesses anymore. For many, it might not even be their main activity.

In the end, the imbalance created by your attack will just play a small role in the overall economic balance of the mining market and will just be one extra revenue stream next to many others. The mining part of business might become secondary and the profits derived thereof might no longer be relevant to the economic balance of the market, which will be dominated by the same economic forces as the more traditional markets. The only consequence of such an attack would be to starve off businesses based solely on mining - something I think is a natural development even without your attack scenario.

In the end, I can come up with many technical ways to reduce the impact of your attack, but in a way you are right. I don't think it's realistic to remove this attack vector completely without modifying the core Bitcoin protocol. I do however believe it will simply not matter enough and the implications will be significantly less drastic than you imagine.

Did you try turning it off and on again?

It's also far more thoughtful, less of a dirty quick fix and less arbitrary.

I don't understand how a self-respecting developer can seriously consider implementing such a horrible hack as a temporary solution.

You are being paid to develop Bitcoin, right? Then come up with a real solution, and not some half-baked, dirty quick fix that has such a potential to harm Bitcoin.

This is bullshit.

If you do this, you kill any credibility Bitcoin has.

It's not Gavin's place to DICTATE what transactions should be allowed and what transactions should not be allowed.

The beautiful mathematical design of Bitcoin just makes sense. This does NOT make sense in the same theoretical, effortless way. This is arbitrary.

Gavin, if you can't come up with an actual decent, good system for transaction fees that makes sense and solves this problems as a mere CONSEQUENCE, instead of enforcing it in a ridiculous, absolutely not thoughtful way, then you don't deserve to be the main developer behind Bitcoin and you should GET THE FUCK OUT of the way.

I'm so unbelievably angry right now that the main person responsible for the progress of the Bitcoin software is even considering this. If there ever was a time where we needed Satoshi, this is it.

Mark my words, if you implement this, it's the beginning of the end, the end of something beautiful. You do NOT have the right to make such a decision!

No.

No.

Hello.

I'm currently working on a piece of software that needs 2-of-2 signing of Bitcoin transactions.

It's really hard, though, to find information about the workings of multi-signing. I would be grateful for any kind of pointer on:

• which Bitcoin clients provide multi-signature support
• how those clients implement multi-signature support
• which files of these clients contain the relevant code
• how an advanced user can use the multi-signature support
• how an end-user can use the multi-signature support

Ideally, I would like to find a daemon-like Bitcoin client to do the work of creating multi-signature addresses, signing the transactions and broadcasting the transactions for me. I would however also consider implementing multi-signature support into one of the existing Bitcoin clients if their code base as far as signing transactions are concerned is very clean & isolated from the other program logic and I find the necessary information about the exact workings of creating and using multi-signature transactions.

When that happens, it could *actually* be the result of a real DDoS for once.

To explain:

When bitcoinity shows lag, this is an API request made to the Mt.Gox API, which will return the trade engine lag. This means that network-wise, the API server is reachable, but the trading engine is falling behind - so the problem is the Mt.Gox system, nothing else.

When bitcoinity does not show lag, it means that the API request made to the Mt.Gox API doesn't return lag, or it doesn't return anything because the server is not reachable. In that case, it's a likely scenario that Mt.Gox is under DDoS attack and that the server is simply unreachable.

I would guess that "the Last change: X seconds ago" would then display the amount of time that the servers haven't been reachable.

Why do you care? You shouldn't be trading there anymore.

I would also attribute it to incompetence. It's quite simple, actually.

If it was DDoS and the problem was with the network, the API would return ZERO as the API lag value, as the API should be unaware of any network issues.

As soon as their API returns a lag value, it's the trading engine itself that can't handle it, irrespective of the network connectivity.

That's the reason why even the best DDoS protection company in the world won't change a thing.

That's exactly what I was thinking the whole time. I just missed my exit point, because I predicted it at 400-600. Now, all I can do is hold .

I haven't lost anything as long as I still hold, right?

So much truth in this thread.

*

This is not stock markets. Bitcoin doesn't do weekends, doesn't close and doesn't give a shit about traditional economic conventions. Deal with it.

Use punctuation and proper English or get the fuck out of my club.

That, plus it only ever lags big time when it goes down.

Draw your conclusions.

Everyone sell. Please.

proudhon spoke, it's time to buy!