I don't like that spring up cryptocurrencies everywhere.
I like them only if they have an improvement over bitcoin. I would like to see thousands of currencies with a wide range of features. Monetary policy is not easy to get right, and BTC is not the last word on it. The way to improvement lies through unfettered experiment. |
|
|
|
Hi, thanks for the report. Update: Fixed in latest. I've reproduced the error using the latest code. I don't have a good fix yet, but adding "store.commit()" after line 886 in DataStore.py gets me past this.diff --git a/DataStore.py b/DataStore.py
index 2bb250e..12eb096 100644
--- a/DataStore.py
+++ b/DataStore.py
@@ -884,6 +884,7 @@ store._ddl['txout_approx'],
"CREATE TABLE abe_test_1 ("
" abe_test_1_id NUMERIC(12) PRIMARY KEY,"
" foo VARCHAR(10))")
+ store.commit() # XXX
id1 = store.new_id('abe_test_1')
id2 = store.new_id('abe_test_1')
if int(id1) != int(id2):
|
|
|
|
|
I see two factors keeping the price down for the medium term: the MtGox fiasco (where the exchange-reported value reached $0.01 after a high above $30) and the newbie posting policy (discouraging new users).
High volatility has long been a BTC weakness, though not applicable to block-chain currencies in general. The MtGox fiasco has dramatically demonstrated this. High volatility is IMO due to an early adoption rate too slow for the simplistic, programmed inflation curve, and a resulting overhang of BTC concentration.
The price rise up to June could not have come without a steady influx of users, and this forum must have formed many users' first impressions. It certainly helped form mine. Now new users must post only in the Newbies section (as has been argued as nauseam, I won't repeat). This must put a wet blanket on their enthusiasm.
By the way, it's interesting that this thread is under Newbies. I'm not a newbie, but I look first to the Newbies section for interesting reading. I find the other sections something of a self-congratulatory echo chamber.
|
|
|
|
Ah, well, Abe tends to return "500 Server Error" rather than an incomplete page. This, too, fixes itself in a bit if you reload. Not sure which failure mode I prefer.
500 + handler explaining the most probable cause? Getting better. Throw in an automatic retry or two? |
|
|
|
This is a bug unique to the BBE mirror: pages sometimes appear before all of the necessary data is fully committed to the database. It fixes itself in ~30 seconds.
Ah, well, Abe tends to return "500 Server Error" rather than an incomplete page. This, too, fixes itself in a bit if you reload. Not sure which failure mode I prefer. |
|
|
|
Changes since July 4: * I've created the Version 0.4 branch, where I intend to backport fixes. * The chain summary page (the one listing several blocks in the same chain) loads much faster than before at high counts per page. * Address search accepts an initial substring, still without storing addresses in the database. * FastCGI support has matured. See README-FASTCGI.txt for setup. * Abe supports Weeds currency natively. * The datadir configuration directive can add a new currency without changes to Python code. * auto-agpl provides a link to download the source directory: a license compliance aid for those not wishing to use a Github fork. * /chain/Bitcoin/q/getblockcount: first of (I hope) many BBE-compatible APIs. * Several small fixes and speedups. |
|
|
|
It doesn't seem like a massively serious proposal  . I dunno, he's clearly put in some effort. What is definitely serious is the infrastructure to support more experimental currencies. I doubt that BTC is the last word on chain-of-work currencies. |
|
|
|
I feel safe keeping all of my coins in Mtgox... am I crazy?
Depends how many "all" is.  I consider MtGox a pretty good choice for most people with a few tens or hundreds of BTC. More than that, and I'd consider it a good component of a diversification strategy. |
|
|
|
So I know it's nothing to lose sleep over, but it does kind of suck to be stolen from and just sit back and do nothing about it. So I'll at least give this a go. This morning I had 12.88 bitcoins stolen from my eWallet. I understand my options are probably limited, but please help... Here's the blockexplorer.com log: http://blockexplorer.com/address/1EAz3M77ZC4SbG8ACLa62whWAm8FKu3d6WI definitely did not authorize this withdrawl... any help greatly appreciated. My sympathies. First of all, whoever executed the transaction into that address had access to the wallet that previously held the coins. You should create a secure wallet to hold any other bitcoins you may have or expect to acquire. If you have given out addresses from the wallet, tell everyone not to send to them. You can find guidelines on wallet security. It is really hard to do right. For starters, it involves securing your operating system from malware. A stolen coin tracker would be a nice application and not terribly hard to implement. Perhaps one day we'll have one. (I've got it on Abe's to-do list.) Meanwhile, you can follow the money with Block Explorer. This will tell you when it may have changed hands. For example, if you see 12.88 transferred to two addresses, one receiving 4.00 and one 8.88, you may conclude that the thief (probably) spent 4.00 on something and 8.88 was the change, or vice versa. But they could just be self-transfers designed to confuse you. Best advice is to move on. |
|
|
|
Update: as of 6/13/11 we have changed the 4 byte magic number in weeds to fix some problems and help support other things like bitcoin-abe that we now have a working version for weeds presently found in my patched branch of bitcoin-abe found here: https://github.com/sacarlson/bitcoin-abe . Bravo. I've applied the magic number upstream. In fact, I'd already given Abe Weeds support in a more scalable way but hadn't documented it until a minute ago. # datadir can supply information about new currencies.
# Note that "address_version" is a byte string: the byte (or, perhaps
# someday, several bytes) preceding the public key hash before base-58
# conversion. Example:
#
#datadir += [{
# "dirname": "/home/weeds/testnet",
# "chain": "Weeds",
# "code3": "WDS",
# "address_version": "o" }]
If you'd like to establish a canonical Weeds/MultiCoin datadir, I'll include code similar to util.determine_db_dir and load the data by default: # This function comes from bitcointools, bct-LICENSE.txt.
def determine_db_dir():
import os
import os.path
import platform
if platform.system() == "Darwin":
return os.path.expanduser("~/Library/Application Support/Bitcoin/")
elif platform.system() == "Windows":
return os.path.join(os.environ['APPDATA'], "Bitcoin")
return os.path.expanduser("~/.bitcoin")
|
|
|
|
Abe supports Weeds: http://john-edwin-tobey.org:2750/chain/Weeds(Sorry for the slowness. A faster server and faster code are in the works. The impatient are welcome to run and improve Abe.) I'd support beertokens too if I could find the config file. Could I have missed it? |
|
|
|
I wonder what the problem was. It seems fixed now. But I can almost guarantee Abe will pick up bugs on its way to being as fast as BlockExplorer. |
|
|
|
People actually send 15000BTC without a transaction fee? What if the transaction wouldn't be included?
They could try again with a fee. Either the same coin (from a wallet backup or custom software) or the change. If the second transaction depends on the first but has a big fee, a miner will gain by including the first so they can include the second. |
|
|
|
AGPL? Shit. Guess I'll go back to coding my own.
I'm curious what your main complaints are about AGPL? It does guarantee is will be free forever but does limit the code it can be integrated in...if he keeps all the copyright I'm sure if someone gave him the right price he'd offer it under different terms while keeping the community one as is! With the software as is, it means (among other things) that I have to publish the source code to any changes made to it, such as changes to the site design. I'm not concerned about publishing any changes I make that fix bugs or add features; these I would just send in a pull request anyway even if it wasn't AGPL. But the license requires me to have a whole source code publishing infrastructure if I change a single byte, which is unavoidable. This is now automated, as described in README.txt: The Affero General Public License requires whoever modifies this code
and runs it on a server to make the modified code available to users
of the server. You may do this by forking the Github project (if you
received this code from Github.com), keeping your modifications in the
new project, and linking to it in the page template. Or you may wish
to satisfy the requirement by simply passing "--auto-agpl" to
"abe.py". This option makes all files in the directory containing
abe.py and its subdirectories available to clients. See the comments
in abe.conf for more information.
|
|
|
|
I have to ask - how in the heck did you acquire enough knowledge about the block chain in order to do this? I have been looking everywhere and can't seem to find much about it.
The block chain is just a sequence of "blocks" whose format is described here: https://en.bitcoin.it/wiki/Protocol_specificationI figured out that the blk0001.dat file is just a concatenation of blocks in wire format, each preceded by two four-byte words: the chain's "magic value" and the block length. I probably checked the C++ code to verify this. The Bitcointools project contains code to parse the blocks. Abe uses that code, only slightly modified to obtain each transaction's hash. |
|
|
|
I could donate some space on my 4GB linode for you if you'd like.
I'd appreciate it. PM or email me with details. |
|
|
|
Send somebody some money. View your transaction in Block Explorer. You will see that your money went to your recipient, AND some more money went to another address. That is the change, and it returns to your wallet at a newly generated address. You merely need to spend that particular coin.
True... if you have not already spent it and its descendants... and if the transaction did not happen to come out even (without change). I think in the future transaction creation will be separate from execution, and sending the transaction hash first will be the straightforward solution in cases where you know beforehand that you will need proof. |
|
|
|
|
You could come pretty close, but the software support is rather lacking. With a patched client, you can sign a message with the key pair used in the transaction. The message could say "Jack owns this coin". That would be pretty good evidence, though there is always the chance the real owners gave you the key pair after they spent the coin, or you paid them to sign a false message.
If you haven't yet sent it, you could in theory create a transaction and send its hash to the recipient before you execute it. Again, the current software doesn't help much here, but with the command line you can at least find the transaction hash after the fact. The recipient could check the hash in a database like Block Explorer.
|
|
|
|
|
Show Posts
