Thanks for the donation and nice comments! I just noticed a bug, which I won't be able to fix today: the type of transaction listed after "Sent" or "Received" on address pages is wrong. A question. When you send coins and get change both addresses are listed, are they listed in the same order every time? Is it random, or alphabetical...
The order is randomized when sent. BBE shows them in an unspecified order on address and block pages (I might change this), but it preserves the block's ordering on transaction pages. |
|
|
|
I created a site that lets you view detailed information about Bitcoin blocks, addresses, and transactions. http://theymos.ath.cx:64150/bbe/This data is all gotten from the block chain. It has always been possible to get this data, but you had to patch Bitcoin with getblock or use the clunky -printblock switch in Bitcoin, and then you had to search through miles of data to get what you wanted. Now everything is available in a clickable and easily-searchable format. Some highlights: - The genesis block, which is included with every version of Bitcoin. If you click the only transaction in this block (the generation transaction), you will see that the "genesis coins" have not yet been spent ("not yet redeemed" in "outputs"). - 198.99 BTC has been donated to the EFF since a Bitcoin address was added to their site. (As of this writing. Hopefully more will be added.) - Bitcoin Faucet has sent and received a ton of transactions. Because of the way change works in Bitcoin, the total balance on this page is not the actual Faucet balance, and this page does not represent all Faucet transactions. - Surprisingly, the three transactions with unknown "to" addresses in this block are the only non-standard transactions in the block chain. The repeated OP_CHECKSIG commands cause everyone downloading the block chain to do extra cryptography -- the bug that allowed this transaction to be included is now fixed, but these old transactions still exist. - 50 BTC has already been donated to BBE, even though I hadn't officially announced it yet. Thanks! If you click on the transaction and follow it back one transaction, you can see that the coin used to donate to me was a generation from January 2010. - Following one of the addresses used by a scammer (according to BuyBitcoins), you can get all of the addresses that ever received coins from this address: 1PwQfGPUFfuqqsmqpg8GegKziMV5Y3qfyr 18oCRAYcQEFbgm7nUCnJ7CqfgYxrhj9Des 16Fdg74JrkWogNDLDM8FJS1k5QrKAouBts 12cPg8VXSL3R3GnphKbpabC14S1sZXbsmU 19w4JEHG2fjVkEeheLSQNTZmmj81KvSzK7 If you own one of these addresses, then maybe you can identify this scammer. This list is only going one level deep -- it's also possible to find a list of every address that received "stolen coins" from the original address, possibly through multiple levels. I hope BBE will be useful and informative. One of my main motivations for creating it was to inform people of the exact limitations of Bitcoin's anonymity -- it's possible to remain anonymous, but only if you're careful. |
|
|
|
I have not seen this actually used for IP networks ever, the only time I've seen it used is back in the UUCP days for routing mail along a specific path.
Does anyone know if this is actually used anymore, or indeed can actually be used anymore? I suspect it is entirely defunct.
Loose and strict source routing are part of the IP specification. The IP header only has room for nine source routing addresses, though, which limits its usefulness. My man page for traceroute says (-g does loose source routing - no option for strict in my version): -g gateway
Tells traceroute to add an IP source routing option to the out-going packet that tells the network to route the packet through the specified gateway. Not very useful, because most routers have disabled source routing for security reasons. IPv6 used to have a similar feature, but it was removed. |
|
|
|
I have used it a little and I think it's great. Minor observation: If I enter 111111111111111111111 it doesn't come up with anything but if I enter 000000000000000000000 it does. There seems to be a problem searching for addresses. I used this link http://theymos.ath.cx:64150/bbeFixed. Thanks. |
|
|
|
It would be enough to export the latest hash from the chain and compare it to the latest hash on theymos's block chain explorer site. A simple script to do this would be helpful .
Here's a text-only version of that information from Bitcoin Block Explorer, for anyone writing a script: http://theymos.ath.cx:64150/q/latesthashBBE is not "released" yet, so I certainly don't guarantee that this will be accurate all the time. |
|
|
|
If you had BTC, would you sell it for something that might be reversed later on? Like Liberty Reserve and Pecunix, bitcoins can only be sold safely using non-reversible methods such as wire transfer, Western Union, and cash. You could probably get someone to sell you small amounts of BTC for paypal on #bitcoin-otc. |
|
|
|
|
I would do it, but it's probably in violation of some law or other, and I don't want to take the risk.
|
|
|
|
|
I noticed a bug in getblock (and bitcointools). Block 67300 is missing several transactions when compared to the output of Bitcoin's printblock, and the hash is also wrong.
I ran into the bug while parsing the entire chain: transaction e7a995 is spent in 67301, but according to getblock data that transaction was never made.
|
|
|
|
http://www.bitcoin.org/wiki/doku.php?id=more_faqsIsn't the minting process a waste of resources?
All currencies need a method for regulating the money supply and creating circulation. To make Bitcoin secure, a large amount of computer work is required. The Bitcoin process for introducing new coins into circulation is designed to make the currency secure by encouraging users to perform the necessary computational work by awarding the role of introducing new coins into circulation in rough proportion the amount of computer power contributed to this goal. Why can't it be doing something useful for humanity instead?
SHA-256 hashing has very specific properties that we need. In particular, it generates (with predictable CPU required) numbers that are for all practical purposes purely random, but in a way that is easily verifiable. There are no known “beneficial” calculations that could replace this.
This CPU time and electricity is not entirely wasted, though: it helps protect the network from attack.
|
|
|
|
Even if you made non-generators aware of the current blocksize, by doing this you could force everyone to pay transaction fees.
There's no avoiding that. An attacker will always be able to create millions of transactions; the only defense is fees on every transaction. Bitcoin was never intended to remain free forever. |
|
|
|
|
The other files are journaling files used for database recovery after a computer/Bitcoin crash. You can delete them if you're sure the database is not in an inconsistent state.
|
|
|
|
In all reality, this is probably simply hosted on shared hosting for a minuscule dollar amount.
Bitcoin.org accepts Bitcoin connections, so it must be at least a VPS. |
|
|
|
Spent transactions can be forgotten (though they currently aren't). That would prevent your sending coins back and forth from having a big impact on block size. The transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster. I think this attack would be more difficult on the real network because of the differing fee schedules. You'll have half of the network including your transactions and half of the network not including them. Half of the network considers a block "filled" at 500KB, and half at the network-enforced maximum of 1MB. Or maybe the entire size exceeded the 1 MB limit. You're right. That message is produced if fees bring a transaction over your balance, and the fee when the blocksize is over 500 KB is 21 million BTC. You wouldn't have gotten that if you weren't generating, since you wouldn't have known the current blocksize. |
|
|
|
That's an interesting way to look at it, but that "currency analogy" will surely fall apart in the future when electricity/btc becomes enormous (as bundle sizes halve every 4 years) and eventually infinite (when the size of generated bundles reaches zero).
If the analogy didn't fall apart, all of us would become wealthier than Bill Gates, and our great-great-grandchildren would become infinitely wealthy around 2140 :-)
I don't see how it falls apart. You buy a certain amount of bitcoins with electricity (don't forget about transaction fees). The amount you're willing to pay depends on how much you desire BTC and how cheaply you can get electricity (and how efficiently you can use it). |
|
|
|
Difficulty adjustments should in theory have no effect on the exchange rate whatsoever because predictability approaches 100% the closer you get to the adjustment.
My thinking on this is: generation is a different currency pair. It's ELECTRICITY/BTC instead of USD/BTC. So there will often be a general correlation between difficulty and exchange rate. |
|
|
|
The transaction fees however, are a little more concerning. How active is the test network? I am thinking about hopping on there and testing this out. It seems a little troubling with how small of an amount it would take, to make the block size unacceptably large at even 0.01 transactions. You would only need 2 BTC to start really creating lots of file size on each block. It doesn't look like it would ruin the network, it just may become a serious inconvenience.
So, if the block size is over 40KB, ALL transactions in that block would require a transaction fee? So if someone sent out 500 tiny transactions with no fees to get the block over that limit... those would stay there until they are accepted by someone not requiring fees? Wouldn't that then also make all other transactions hang as well if they didn't include a fee? Or, require everyone else to pay a fee?
The first transactions in a block are "locked in" to whatever rate they were accepted at. Block sizes 40-50 KB allow free transactions under 3 KB. Most transactions are smaller than this. Above 50KB requires fees on all transactions. Any that don't have fees must wait until the next block. Transactions are included on a first-seen basis. The effect of spam would be the delaying of all transactions that don't pay a fee. ArtForz (30% of the network) is running without any fees, and old clients have much higher free limits. It'll be hard to fill up everything; creating transactions is not computationally free. Since there are so few people on the test network (4 right now), I would just do the test on the real network. The worst-case scenario is everyone's transactions are delayed for a little longer. This might interest you: http://bitcointalk.org/index.php?topic=567.0ArtForz might screen out spam transactions if they become a problem. It's probably pretty easy to detect: deprioritize all transactions that draw coins from a very recent transaction. This kind of manual handling is probably how this kind of thing will be dealt with a few years down the line, when all big generators are using custom clients. |
|
|
|
No. EVERYONE stores the block chain (at the moment). Why should a generator be able to inflict a large block on everyone just because he generates a hash?
That won't always be the case. When simple payment verification is implemented, it won't matter at all to most people how large blocks are. Generators are the ones running the network and bearing the cost of doing so, so they get to set the rules. I said that this only occurred if the block size was over 40k bytes (which I revised down from 50k)
You seemed to disagree.
Look at the code... "If the block size is under 40KB, transactions over 25KB are not free." Old clients have higher limits for free transactions, so they will send even 50KB transactions without fees, and these will be delayed because new clients will never include them. |
|
|
|
If some behaviour is "by design" it tends to imply that the result is either good or at least ok. I was making the case that this behaviour is bad, is a flaw and should be changed. I presume you disagree. Could you explain why? ArtForz is essentially enabling the adverse behaviour I outlined.
The generators are the ones who have to store the block chain and do the proof-of-work, so they should be the ones who set the price. In the "transaction fee" wiki article, I wrote: In the far future, different rules about transaction fees among generating nodes will probably create a clear choice between fees and transaction speed. For example, you might choose to spend 2% for a guaranteed spot in the next block or 0.01% for the transaction to be sent in a few hours. This is a desirable situation -- a true free-market payment processing system. Anything else would be equivalent to price fixing, which would cause the system to fail. It'll never go above 1MB/block, in any case, as above this limit blocks are rejected. I don't think you're right. I believe you can send a 25K byte transaction if the resulting block size is below 40k bytes for example. If I'm wrong, quote the code that forbids it.
In my previous post I should have replaced 50kb with 40kb to be correct.
// Transactions under 25K are free as long as block size is under 40K
// (about 11,000bc if made of 50bc inputs)
if (nBytes < 25000 && nNewBlockSize < 40000)
nMinFee = 0; |
|
|
|
I don't mind at all releasing whatever graphic I have done for Bitcoin in the public domain, it's just that I have no idea in which license is the original logo done by Satoshi, especially the symbol. Is that symbol in public domain? I know this may sounds dumb, but it has to be, right? If it is part of an open source project. I am no lawyer or programmer familiar with this sort of things, I am just a bum for god sake. So perhaps someone can enlighten us.
It's released under the MIT license. CC-A would be most appropriate for your logos, I think. They could then even be included with Bitcoin without any trouble. |
|
|
|
|
Show Posts
