So, the only new data you would need to gather is the block generation dates... don't the block themselves have timestamps?
Yes. Here are the timestamps if you want to try that: http://www.mediafire.com/?bqamkafj1lvqkbl |
|
|
|
|
It's pretty easy to do. Bitcoin already contains an alternate network with a different genesis block and different network parameters (the minimum difficulty is lower to make generating easier).
Competing with Bitcoin will be almost impossible, however. You'd have to offer something really good.
|
|
|
|
Will there be a default fee amount included in future clients, or will be have to guess/check what the average miner is charging to process transactions?
Bitcoin will look at network conditions and make a guess for you. |
|
|
|
|
It's possible, but not yet implemented.
|
|
|
|
When a block is rejected obviously the "mining" transaction for that block is also rejected (as you suggest here), so there is at least some loss, plus there is entropy in the system where from time to time (as people turn on and off clients) that over time transactions will be dropped.
Pre-0.3.9 clients are still trying to include the overflow transaction. Generation transactions can't be spent for 100 blocks, so a split would have to last longer than that for any problems to occur there. The chance of a transaction being accidentally reversed after 1 confirmation is nearly 0. It requires a real attack. |
|
|
|
Current copyright law allows for personal fair use, where you can use use your computer any way you see fit as long as what you do is for yourself. Reverse engineering, for example, is explicitly indemnified and mentioned in copyright code as legal... contrary to what some EULAs would have you think. What it doesn't permit is for you to take the hard work of others and give it to 3rd parties without permission.
That still allows you to control the property of people who have not dealt with you. Contracts can enforce non-distribution of works (and even prevent reverse engineering), but if someone breaks this contract, later users of the "leaked" work can't be held to the contract terms. If I have not agreed to give up some of my property rights with a contract, then under no circumstances can you control my use of my property. |
|
|
|
|
That's one of the Faucet's change addresses (probably -- I haven't traced it to the start). It's sending 0.05 to a Faucet visitor and the rest to a new change address owned by the Faucet.
|
|
|
|
|
Bottom line: intellectual property of any kind infringes on my real property rights. Your copyright prevents me from using my computer in the way that I choose, and is therefore immoral.
|
|
|
|
|
It's just the number of blocks that were generated by the network after the transaction. It goes up without limit.
|
|
|
|
What is the actual consequence of me moving that file? Or what is stored in that file?
It contains journaling information for the block database files (blkindex.dat and blk*.dat). It's possible that deleting that could damage the block database. I recommend deleting the other block database files, too. |
|
|
|
|
Try deleting your blkindex.dat and blk*.dat files.
|
|
|
|
|
It was Verisign (the COM registry) that did this, not ICANN. ICANN is always terrified of making controversial actions, and they would never do something like this, even with a court order.
You can see that the domain is redirected at Verisign's gtld-servers.net rather than ICANN's root-servers.net. I'm surprised so many news organizations made this mistake. I am not surprised that GoDaddy said this, since it is one of the most dishonest and incompetent companies ever.
|
|
|
|
Sorry, these users' disk and CPU were not at 100%. It is clear the bottleneck is not the database or indexing, for many users.
It seemed to me that it was some sort of disk problem or network condition on his end. Some selected quotes from my IRC log: <manveru> also, when i woke up, there were thousands of entries in the debug.log that look like: trying connection lastseen=-135.6hrs lasttry=-358582.4hrs
<theymos> How many connections do you have?
<manveru> 2 right now
<theymos> How many blocks do you have?
<manveru> blockcount and blocknumber are 29124
<theymos> How fast is that increasing?
<manveru> around 1 every 4 seconds
<jgarzik> manveru: 32-bit or 64-bit linux?
<manveru> 64
<manveru> now 'blkindex.dat flush' takes a few minutes :|
<manveru> still hangs on flush
<theymos> manveru: Are you on some network file system?
<manveru> no, just a normal harddisk
<manveru> it's only 5200 rpm though Also, replacing the blocks might have prevented him from noticing a transaction: <manveru> jgarzik: sent me the blocks, but it didn't change my balance
<MT`AwAy> manveru: in your getinfo you're at block 94236 ?
<manveru> yeah |
|
|
|
|
MyBitcoin probably considers a transaction confirmed after 1 block. The more confirmations, the more difficult it is for the sender to reverse a transaction. 6 is almost impossible (and never profitable), but 1 is still extremely difficult. Even 0 is quite difficult. The last few pages of the Bitcoin paper have probability calculations for this.
Maybe MyBitcoin requires more confirmations when you deposit larger amounts of BTC.
|
|
|
|
|
Data sizes are now shown for transactions and blocks.
|
|
|
|
To get block/tx size, you can add this to block processing: obj.push_back(Pair("size", (int)::GetSerializeSize(block, SER_NETWORK)));And add this to tx processing: txobj.push_back(Pair("size", (int)::GetSerializeSize(block.vtx[i], SER_NETWORK)));I don't know that this is the best way of doing this (I'm not really familiar with C++). That cast to integer is probably not necessary, but it works and I don't want to test another version (overflow is impossible for the foreseeable future). |
|
|
|
Google searches will find the From_Xenu wiki page without a problem...
The page isn't indexed by search engines because it contains the {{NOINDEX}} template. |
|
|
|
For those familiar with the network level protocols, what is the difference between getblocks and getdata? Both seem to be a list of hashes representing blocks which need to be sent to the requesting node.
One difference I can see is with the "getblocks" command/packet type will request a range of blocks, while getdata requests individual blocks. Is this the only difference or is there something more significant that I'm missing here? I'm trying to figure out when this particular packet type might be used instead or why there seems to be a duplication of block request methods seemingly doing the same thing.
Have you seen this? http://www.bitcoin.org/wiki/doku.php?id=networkGetdata requests a specific block or transaction by hash. You generally only send a getdata after you receive an inv listing a block/tx that you don't already have. Getblocks requests an inv containing the hashes of all blocks in a range (max 500 at a time). It's used for initial block download and re-syncing after some downtime. Getblocks (client) -> inv (server) -> getdata (client) -> block (server) Send one getblocks, get an inv with 500 entries, send 500 getdata messages, receive 500 block messages. This sounds inefficient, but the download is actually very fast (it's the verification that eats up most of the "download" time). |
|
|
|
|
The bounty should just be returned to the donators. They can individually distribute it when a suitable video is created.
|
|
|
|
|
Show Posts
