Not quite. At least today miners who have mempool accepted a transaction will not accept a conflicting one with higher fees, even if they're not attempting to mine the lower fee one yet.

You can pull off doublespends against no-confirm acceptors today, but it's a heck of a lot easier to do it reliably if you have some friendly hashpower.

Do you often kill flys with hammers?  Bitcoin git was changed so that sendrawtransaction wouldn't emit txn with insane fees without an explicit override flag more than a month ago. This requires nothing about changing relay rules and avoids adversely impacting other parties.

I wonder if transactionfee seconds is more interesting that transactionseconds?

You would be able to spend an uncertain amount between zero and all of coins that had been sent to addresses which were generated before you encrypted, depending on how many of your coins had been moved to new change addresses subsequently.

If you've ever used any addresses generated by the encrypted wallet, it's best to make a new backup after you restart with encryption, and then send your coins to a newly generated address.

Mistakes can be avoided totally locally, and its preferable to do things locally because it doesn't constrain what other people can do.

Malware doesn't care about non-standard. For the malware author to profit from tricking a dumb client to pay away their coins to fees they'll need to privately sell the high fee transaction to a miner, thus bypassing the standardness rules.

Uh. No. Thats absolutely not true. If you provide the required information (including scriptpubkeys for the inputs) you can sign transactions without a blockchain at all.

I think the no replacement version is at least not terribly worse. Replacement requires miners cooperate in a very specific way, which is costly to them, but can't be enforced, even if someone is offering higher fees if they break the rules.  Somehow, I suspect any protocol that really counted on that wouldn't be very trustworthy.  The best thing that I really can say about the sequence numbers is that you can build protocols where a sequence violation creates proof that your counterparty cheated which could be showed to other people.

n4ru, you can use 'delayed transactions' fine, they're valid on the network once their lock expires. This is adequate for many uses.

The number has gone up quite a bit since then since the hashrate is rapidly growing.

At the moment, it's $80,000,000, though it will step down again when I can fairly make the claim $3/gh 28nm parts, instead of $8000 for 400GH/s bitfury parts. ($3/gh would be $12m at current hashrate, though once those parts are actually available the hashrate will go up some large amount).

To elaborate on Maaku's comment.  Bitcoin is foremost an autonomous zero trust system, all full nodes validate everything. A majority of mining ruins the security assumptions, but it still doesn't give the majority completely free reign over the system. Dishonestly using your majority hashpower would likely just make the resulting coins worthless.

No, but sometimes even high power pools will get massively unlucky. ... but if the miners were still paid, then yea, that supports the original hypothesis or (2).

Users of bitcoind / bitcoin-qt can fight back against this by using Peter Todd's (retep on BCT) dust-b-gone script which will CoinJoin away the dust in your wallet, both cleaning up the blockchain and thwarting any tainting efforts.

Forget selfish, try double-spending: https://bitcointalk.org/index.php?topic=327767.0

Thats describing a block withholding attack. The idea is that you mine normally but happen to throw out any block solutions. Because this pool is PPS you get almost exactly your normal pay anyways since block solutions are rare, but the pool goes bankrupt.

It's basically undetectable if performed in a sufficiently advanced way, but it's only a cheap attack to perform if you're attacking a PPS pool. On any kind of pool where the miners take the risk of low luck the attacker also loses a lot of coin this way. Any pool is vulnerable to this if the attacker is willing to pay to put a pool out of business, though some (like p2pool for example) give the finder of a block a slight bonus which further disincentives it (because you can't get your full income without sometimes getting those bonuses).

The only absolute defense against it is solo-mining.

Unconfirmed double spends are also perfectly possible without any hashpower at all... though you can certainly do them more consistently with some.

Especially with these stupid gambling services: you only need to change the txid so the actual better can have plausible deny-ability in the doublespending, and being successful only a small percentage of the time is enough to shift the odds in favor from the house to the player.

Might be worth offering two alternative hypothesizes that the data also works for:

(1) attacker spent a whole lot of BTC to frame ghash.io by paying it to a well known address of theirs unsolicited.
(2) ghash.io sold their hashpower to a third party, who used it to perform the attack and the payments were payments for more hashpower.

(IMO, (2) should be regarded as the community as even _worse_ than attacking themselves, ... but I know that the community doesn't regard blindly selling hashpower as treacherous.)

Creates big incentives to screw with the subsecond accuracy of the network times. Has the anti-convergence property where if a first block is announced with a bad time you can keep trying instead of moving forward and you'll be sure to replace it unless you end up with a race with a child of it.

I can't comment on the KnC I know there have been an assortment of firmware issues there, but a significant fraction of the total p2pool hashrate is asicminer blades. The asicminer blades are getwork only and violate the getwork protocol by always returning diff 1 shares no matter what you ask for, this doesn't goof up most centralized pools since they only return diff1 getwork.  On p2pool you can tell p2pool to fix the pseudoshare diff to 1 (add +1 to the miner username) or you can run the asicminer blades through a proxy (e.g. bfgminer) that actually fixes the protocol.

[Also: you dweebs have totally taken this thread off-topic, shame on you.  I posted about some decenteralization improvements that you can do _other_ than P2pool and you flood it with complaints about P2pool]

If you want to encourage P2Pool use you can make it in more people's interest by making bursty donations to the recent p2pool miners: https://en.bitcoin.it/wiki/P2Pool#Donating_to_P2Pool_miners  (Of course if you do this, you should publicize it in order to have an effect.)  Many miners don't fully understand the issues, prize money is one way to get their attention. Switching to P2Pool also has a cost, and some tips can help bridge that gap.

(Disclosure: I mine on p2pool, but I'm under 1% of its hashrate now. Regardless, any funds I get via these sorts of payments to my p2pool addresses I'll just recycle back into other pro-decentralization uses)

Fungability. Do you speak it??

AWS nodes, especially smaller ones have horrific IO that is slower than a 4200 rpm laptop drive.  You may be better off looking for other options.

Reducing the blockchain storage will not change the ongoing IO load which you seem to be expressing problems with.  At least from what you're telling me here the size is actually not a problem for you. Am I misunderstanding?

Can you explain better what limitations you're facing. In other words, "Please explain the problem you're having / trying to solve, and not what you think the solution is".

The current blockchain size is a fraction of a modern commercial _game_ and it stores the whole bitcoin economy. Better understanding the nature and origins of your limitations you're facing avoids thinking we have a solution for you which isn't a solution.

Please also be sure to explain what you expect to do with a node. For example, if you need to be able to add new keys at will and go find their transactions ... there is no way thats going to happen with reduced storage.