If you can isolate a node from the network you could trivially double spend against them, all you'd have to do is generate blocks faster than they can.
You still need to work against main-network difficulty, so it takes a very long time to accumulate confirmations on your double-spend. The target is likely to notice. A future version of Bitcoin will probably detect this.
|
|
|
The generated coins go to a newly-generated address. The generation won't be viewable with listtransactions, and the address won't be listed in listreceivedbyaddress. The generation will only be reflected in your balance.
|
|
|
Resources would be wasted working on that, since in the future there will be backbone nodes that everyone connects to. By always connecting to a few of the same backbone nodes, the problem is solved.
|
|
|
I'd just use bitcoind remotely. If you don't want to set up Bitcoin's own remote RPC ability, you could pretty easily create a PHP server that does what you want using GET parameters.
MyBitcoin is used on a lot of sites. I like the customer-side experience, though I've never used it on the server side.
|
|
|
I already understood that with the current bitcoind client you can't send messages with your transactions because otherwise people would be using it but what it sounds like you're saying is that someone could create a patch for the bitcoin sourcecode which would add this functionality to bitcoin even though there are no plans from the developers to include a messaging feature. In the case where Gaven modified the source to include a vanity feature, someone else in the next half hour could modify the source to allow a PGP public signature to pass with the transaction and then anyone with that modified source would be able to see it or the intended recipient would also be able to see the PGP public key. And finally; this could be done without disrupting the Bitcoin network because you're using something that's already in the protocol?
It is possible. Each output can contain about 9kB of arbitrary data. Bitcoin won't relay/include non-standard transactions any more, though, so you'd have to create a block to get the transaction included in the block chain. You could also include a substantial fee with the transactions, which would encourage miners to change their rules.
|
|
|
No, but I use f.lux for nighttime computer use. My eyelids thank me every night. I also use this. It takes a while to get used to, but I now feel like my monitor is a portal into the center of the Sun whenever I turn it off.
|
|
|
If that isn't down to earth enough, this weekend I ordered firewood in liters to be put in a space measured in meters. Easy, one cubic meter is 1000 liters. If the firewood had been sold in gallons and the storage space measured in feet, I would have had to bring out a conversion factor and a calculator.
Firewood is never sold in gallons, so you wouldn't have had to worry about it. Firewood is sold by the cord, which is defined in terms of feet.
|
|
|
That looks too "commercial" to me. People will probably think that Bitcoin is run by a business from looking at that. I prefer the simple layout.
|
|
|
So as far as markets are concerned I'm a libertarian, but I have enough expertise in politics and history to understand that a free market ends up as monopoly unless you force them to be free. Would the creator of Bitcoin say something like that?
|
|
|
if im currently mining, and another person got a block, does that "reset" my work?
You have to change what you're working on, but this costs you almost nothing to do. The work doesn't accumulate, so there's no work to throw away.
|
|
|
That was my initial thought, but it won't help the fact that the tx and block itself are hashed with SHA-256...
Yeah, I suppose. I was thinking some transactions wouldn't need to be re-signed, but transactions use SHA-256 in inputs.
|
|
|
It's possible. The service will be able to send you transactions that don't really exist, though it is safer than using MyBitcoin.
In most cases I think it would be better to use a headers-only Bitcoin client, and then rely on some third party to pass you transactions that you have received. Then the service can only neglect to give you transactions, and not trick you into accepting double-spent transactions.
|
|
|
You must generate a new address for each transaction. Track accounts by seeing which address you receive money at. Using Bitcoin Block Explorer is not necessary for this. Forget about seeing where money came from: instead look at where the money went to.
IP address transactions are insecure because any man-in-the-middle can intercept funds. There's also no way to send/receive IP transactions using RPC.
|
|
|
The old clients will still accept these sendmany transactions if they get into a block. They just won't relay them. I suppose accepting 0-confirmation sendmany transactions might be more risky, but confirmed transactions are just as secure.
|
|
|
It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.
|
|
|
My top feature request is the ability to choose which coins to send in a transaction.
|
|
|
It's not in the UI because someone might try to actually use it for something, which is wrong. It could belong to some random MyBitcoin user.
|
|
|
SHA-256 will not be broken suddenly. Even SHA-1 has not yet been completely broken, but has gradually become considered less secure. We'll have plenty of time to switch to a newer hash. Maybe we'll do it at the same time we lift the 32-bit timestamp limit...
The SHA-3 candidates are more likely to be completely broken than SHA-256, since they are new.
|
|
|
The block finder provides the timestamp? I remember hearing about some rough restrictions on acceptable times relative to other blocks. Is there enough play to allow exploitation by a miner who preferred difficulty to be a little lower.
They could modify it somewhat. The timestamp must be greater than the median of the last 11 blocks and not more than two hours in the future (according to network-adjusted node time).
|
|
|
|