What version are you using? Versions older than 0.3.13 will send bad transactions that most generators won't accept if you've ever received a similar bad transaction. Run Bitcoin with the -debug switch and double-click the transaction. Paste the hash here. The hash is located under the "transaction" header: CTransaction(hash= c3821b, ver=1, ... Maybe that transaction didn't propagate correctly and it took that long before it was rebroadcast?
That is possible. Bitcoin waits a long time before it rebroadcasts, and it might take an especially long time if you never leave Bitcoin open for longer than a few hours. Maybe somebody is simply messing with the network using a botnet or other large scale attack ?
I would like to hear Satoshi's opinion on what would exactly happen if (50% - 1) nodes of the network started to revoke the same transactions simultaneously. I mean there would be 50% - 1 "cheaters" working together, and the rest would be honest nodes.
Would the network still work properly in that case ? Or perhaps would some transactions be irreversably damaged ? Would the network figure out which hash calculations to trust and which not ?
An attacker with more than 50% of the network's CPU could prevent a specific transaction from gaining confirmations. See the wiki. There's pretty much no chance that this is happening here, though. You might be able to do this for a while with less than 50% of the network. It depends on how lucky you are. You need to create more than 50% of blocks. |
|
|
|
|
All of the data that Bitcoin hashes is too large and random to use rainbow tables with.
|
|
|
|
|
Generating is just like buying bitcoins, except you pay with electricity and time.
|
|
|
|
|
I think Mizerydearia is planning to release bitbot's source. That would allow a new bitbot to be set up on a more stable server, or at least a backup bot to be made.
|
|
|
|
so theymos is easily out by a factor of 100. I forgot to move the decimal over for the fee per KB.  |
|
|
|
Large blocks are a valid DoS attack against bitcoin, presently. Transaction fees kick in at higher block sizes, but it still remains quite inexpensive to flood the network, even if you are paying full TX fees right up to the 1MB (?) block limit. I dunno about lucrative, but...
Driving a block to 1MB costs 21 million BTC. I don't think attackers are going to pay... if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
return MAX_MONEY; Here's how much it would cost (estimates) to make the block size go to various levels: -50 KB: Free -250 KB: 2 BTC -300 KB: 127 BTC -350 KB: 293 BTC -400 KB: 543 BTC -450 KB: 1043 BTC -490 KB: 3543 BTC -495 KB: 8543 BTC -499 KB: 33543 BTC Attackers can feel free to pay 500 BTC every 10 minutes to make sending transactions expensive... |
|
|
|
True. Quoting Satoshi's white paper :
That's about transactions in blocks, which are further protected by transaction fees. I'm talking about transactions waiting to get into a block. |
|
|
|
Unless there is a scheme for forgetting transactions that have insufficient fee then it's still a big problem.
Transactions are forgotten over time, to prevent just this problem! Nodes delete transactions in their memory pool on shutdown, and they never rebroadcast transactions that they already know about. This causes most of the network to forget about a transaction in about a week. If your transaction isn't going through, you would restore from an old wallet backup, wait for the network to forget your transaction, and re-send. |
|
|
|
From a large corporation, a purely profit driven enterprise, faceless and cruel.
Most don't have unions, minimum wages and ignore the cries of employees.
The producer of the item being liberated is already payed in full.
This kind of incorrect thinking is caused mainly by ignorance of economics, I think. In a voluntary society such things would be punished more harshly than they are now imo.
In anarcho-capitalism, you'd probably have to pay your own defense agency a huge amount of money to convince them to keep such an idiot under their protection. |
|
|
|
Some anarchists (usually social anarchists) have advocated forms of direct democracy as an alternative to the centralized state and capitalism; however, others (such as individualist anarchists) have criticized direct democracy and democracy in general for ignoring the rights of the minority, and instead have advocated a form of consensus decision-making. Libertarian Marxists, however, fully support direct democracy in the form of the proletarian republic and see majority rule and citizen participation as virtues. The Young Communist League, USA in particular refers to representative democracy as "bourgeois democracy," implying that they see direct democracy as "true democracy."
Any kind of democracy, "consensus decision-making", or any type of government entails some group of people forcing their will on some other group of people. They all violate property rights and are therefore immoral. |
|
|
|
Using the same definition, "Balance sheets" is essentially done as well! The simplified payment verification system is already in place. The Merkle root required for its functioning is included in all blocks. Blocks do not include the hash of a balance sheet. The size difference would not be significant. SPV is ~80 bytes per block plus 32 bytes per transaction, whereas balance sheets would be 20 bytes per unique address. Currently there are 132415 unique addresses in the system and 134267 transactions. SPV: 11.29 MB; balances: 2.65 MB. This is assuming that balance sheets will not have any header-like overhead, which they almost certainly will. SPV looks through the Merkle tree to get the number of confirmations and prove that transactions and their prev_outs were not double-spent. This is the point of SPV. How would balance sheets solve this? If you're just going to download the most recent 5 blocks or whatever (an insecure method), why even have balance sheets? You can't generate with balance sheets, as you are unable to verify referenced signatures. Using balance sheets with the current system would require receiving and processing every transaction ever made, which will become difficult as the block chain grows. SPV requires no such processing, and the amount of data stored on disk is the amount received through the network. A balance sheet system written from scratch would not be any better than the current system. Generators need to know the contents of every non-spent transaction, so a parallel network similar to the current one would have to be kept. Clients would need to download every block header (as in the current system) because the current block with the balance hash can only be verified if you have every block in the chain. |
|
|
|
|
This is essentially already done. Bitcoin uses a hash tree structure for transactions that makes it possible for nodes to:
- Do everything except generation by downloading just the block headers and Merkle tree for each block, which is a tiny amount of data.
- Discard outputs that have been spent (referred to by a later transaction), even if you're a generator.
Neither of these are actually implemented yet, but the system of capable of doing it.
You could even generate while running in header-only mode (using getdata messages to get transactions you're missing), though the entire network could not do this.
|
|
|
|
Could he simply be automatically sending bitcoins from one wallet to another?
My old post (edited) was a mistake. I was looking at the wrong output index. Noagendamarket sent to those addresses, not bytemaster. |
|
|
|
I suppose you can check to see if the same coins were 'spent' by bytemaster, and to whom.
It was not spent. |
|
|
|
So the calulators that I see are just calculating odds then. I take it you could solve a block in your first 5 minutes if you were lucky enough. Or if unlucky then you might not solve one all month.
That's right. The calculators look at the current odds per hash (this changes from time to time), and from that calculate the average number of hashes it takes to solve a block. Then you can figure out the average time to solve a block based on your hash rate. |
|
|
|
|
There is no "progress", so there is no loss. For every hash that you calculate (you might calculate millions of these per second), there's a small chance of solving a block. Each hash is like an entry into a lottery. Each hash is independent of the others, so nothing needs to be saved.
|
|
|
|
He was generating invalid blocks at difficulty 1.0. He must have a corrupted txindex entry in his blkindex.dat file. He just needs to delete blk*.dat and let it redownload.
He already did that, and the same problem occurred right away. So it's probably an antivirus issue. |
|
|
|
What does it take for a client to reject an incoming block from the network? If we know this we can work backwards and find out why he wants to reject every new block. There must be a transaction in the main chain 1699 or prior that his client disagrees with.
He would have to disagree with 1699, but that is an empty block. There's no reason he should disagree with that one. My theory: His antivirus cuts off files after a certain size. This caused his block database to be limited at 1698 (and maybe he rejects blocks after that due to corruption). However, his block index was not cut off (because it's shorter), so he ignores incoming blocks as "already have", even though he doesn't really have them. Every time he generates a block, it is quickly destroyed by the antivirus, but its confirmations are preserved by the block index for some reason. |
|
|
|
Like grondilu said, encryption isn't possible. It's possible to modify Bitcoin to send messages. Just create transactions that start with something like this: BTCMESSAGEv1--This is a message OP_DROP The network will accept these, but I don't think your recipient will recognize them unless he is also using your modified Bitcoin. |
|
|
|
Satoshi, could you tell me of what revision is this version ?
I tried diff-ing the files (from SVN and from the binary package with sources), but there seems to be some kind of binary differences in the files, and they are marked as different when doing directory compare, but diff software cannot pinpoint what are the exact differences !!
That is the weirdest thing i have seen in a long time.
Perhaps the files from the package are encoded in UTF-8, UTF-16 or something ? In SVN, they are noticeably smaller.
SVN has Unix line endings, while the source in the packages has Windows line endings. The files are otherwise exactly the same. |
|
|
|
|
Show Posts
