I'm happy to announce ClearCoin, my bitcoin escrow service: https://clearcoin.appspot.com/It makes bitcoin transactions safer by securely holding coins in escrow until both buyer and seller are satisfied. If you are buying something using bitcoins, it makes the transaction much safer. If you are unsatisfied, you will eventually get your bitcoins refunded to you-- you can think of ClearCoin as do-it-yourself chargebacks. If you are selling something using bitcoins, ClearCoin is safer than ad-hoc arrangements to reassure reluctant customers (like "I'll ship you the product if you promise to pay within 30 days" or "pay me half now and half on delivery"). I'm looking for questions, comments and feedback. You can give it a try for free-- transactions of less than 100 bitcoins are free, and you can setup an escrow account to yourself just to see how ClearCoin works. |
|
|
|
|
Just to close the loop on this:
This happened when:
You ran version 0.3.17, and sent/received some coins
You then ran an earlier version, and the coins you sent/received with 0.3.17 were rewriten to the wallet (e.g. you spent them or they got included in a block). They'd get rewritten incorrectly (marked as version 0.3.17, but missing extra info).
... and then you upgraded to version 0.3.17 again. Bitcoin would crash trying to read the extra, missing info.
svn r196 fixes the problem, by storing the extra account info in a different way and detecting the badly-written 0.3.17 entries.
|
|
|
|
What's a non-standard transaction?
A transaction that is signed in a way that the standard bitcoin client doesn't understand. For example, there's been some discussion in other threads about using OP_DROP to embed extra data in transactions; doing something like that would create non-standard transactions. |
|
|
|
|
I just commited svn r197 (version 0.3.17.05); it is a "prevent possible security problems we haven't thought of" fix.
Before this change, you could compile your own version of bitcoin, create nonstandard transactions containing extra information or fancy new payment features, and all the official bitcoin clients on the network would happily include those transactions in the blocks they were generating and would relay them to their peers.
After this change, official bitcoin clients will not relay nonstandard transactions or include them in blocks that they create. They will, however, still accept non-standard transactions that do manage to get included in a generated block.
So, what should you do if you had a fantastic scheme for doing something fabulous with bitcoin that relied on the ability to generate nonstandard transactions?
1. Implement your fantastic new features.
2. Run it on the testnet to test it out. You can pretty easily generate blocks there, and, as said above, peers will accept your nonstandard transactions in blocks that you generate.
3. Convince the rest of us that your idea is great-- or, at least, convince a good percentage of the bitcoin-generating nodes that your idea is great.
|
|
|
|
Is this correct? Does my wallet save every single address?
Yes. The getaccountaddress method will return the same address until it is used (until a payment is received on that address). But getnewaddress always creates, stores, and returns a new address. |
|
|
|
|
My private gpg key is kept in my LastPass Vault (as a secure note), along with all of my passwords.
I'm a big fan of LastPass; Steve Gibson did a good review of their tech and why it's safe on a Security Now podcast a while back.
|
|
|
|
PS: Anyone can recommend some kind of automatic backup software for Linux?
My automatic backup strategy is: Cron task that runs a shell script twice a day. The shell script does: call bitcoind backupwallet to create a time/date-stamped wallet file gpg encrypt the wallet with my public key copy the result to an off-machine backup location (I'm using Amazon S3, which is itself redundantly backed up to multiple geographic locations automatically) Shell script looks like: #!/usr/bin/env bash
GPGU="Gavin Andresen"
TS=$(date "+%Y%m%d-%H-%M")
WALLET=/tmp/clearcoinwallet${TS}
WALLET_E=/tmp/clearcoinwallet${TS}.crypt
~/bin/bitcoind backupwallet $WALLET
/usr/bin/gpg -r "$GPGU" --output $WALLET_E --encrypt $WALLET
~/bin/s3cmd put $WALLET_E s3://NAME_OF_MY_S3_BUCKET
rm $WALLET $WALLET_E
I'd suggest doing something similar (replace the s3cmd with an scp to copy somewhere if you're not an S3 user; you could even ftp somewhere, since the wallet is encrypted it doesn't matter if somebody is eavesdropping). |
|
|
|
I archived my wallet to be opened 16 years from now. Will I run into a similar problem?
Peer into my crystal ball with me as we predict the future.... No, seriously, upward compatibility (reading old wallet.dat's into new versions of bitcoin) shouldn't be an issue. And Satoshi and I are discussing possible fixes for the upgrade/downgrade/upgrade scenario that we think is causing this. |
|
|
|
|
genjix, you're the third person to run into this problem; I'm looking into it.
I suspect the problem is running a later svn version and then running the same wallet with an earlier svn version; the format of wallet transactions changed recently to support the 'accounts' feature.
Your bitcoins are still safe in the wallet (all the private keys are still in there). Stay tuned...
|
|
|
|
1. Why not have both? The market will decide which one people choose to use most. One might be used more at first, then later as browsers are updated, site owners might later switch to the other. But.... Are they mutually exclusive??
Nope, the hard parts aren't parsing the bitcoin: url string (or the file), and once parsed the same code could do the actual request. 2. What's stopping us? Let's just implement them BOTH immediately. We obviously have the knowledge and expertise to get the job done. Let's just get the job done already.
The hard part: what happens if I click on a pay-using-bitcoin link and I don't happen to have bitcoin running right now? The browser or OS runs bitcoin and hands it the payment request info. The bitcoin process checks to see if there is already another bitcoin process running. Nope. Ok, load the wallet. And then wait until we're caught up fetching the block chain that we missed while we weren't running. Gotta do that because some of the transactions in my wallet might have been spent (if you copied your wallet somewhere), or you might have received payments while bitcoin wasn't running. And so N minutes after clicking bitcoin is FINALLY ready to send payment. If N is greater than 1, then that really sucks! --------------- I like click-to-pay, and I want it to work; it would work well now for the "I'm running bitcoin and connected to the network 24/7" use case. But I don't think that will be the common use case (most people probably won't bother generating). So I think we've got to figure out some clever way of making click-to-pay quick-- maybe ask for payment permission and then have bitcoin chug away in the background, popup an alert if there's some problem paying, or just shut itself down after it's caught up with the block chain and has submitted the payment. Or, assuming you have enough coins in your wallet, maybe just throw the transaction onto the network and let peers tell you if you're accidentally double-spending (that makes me very nervous, though). Or... |
|
|
|
I've been lobbying for the mimetype solution. I did a little mockup a while ago of what happens if you click on a link and do NOT have bitcoin installed (which, in my opinion, is the most important case): http://skypaint.com/btcpay/mimepay.html |
|
|
|
I just checked in a minor bug fix / cleanup. The bug: boolean options/flags were being treated inconsistently. If you specified -gen=0, that meant (and still means) "do not generate." But specifying -testnet=0 did the opposite of what you might expect. Now all boolean flags behave the same way; for example: -gen : means generate -gen=1 (or gen=1 in bitcoin.conf): means generate -gen=0 (or gen=0 in bitcoin.conf): means do not generate ... and if you don't specify the option at all, that means "don't." Check your bitcoin.conf file! If you are using anything beside "0" and "1" for boolean options, you need to change. I had: rpcssl=true # THIS IS WRONG! ... in one of my bitcoin.conf files. The correct syntax is rpcssl=1 |
|
|
|
I'm very curious as of what restricts the supply of bitcoins? basically, what mechanism prevents some computer to create new bitcoins, and pass them as valid to other bitcoin clients?
Bitcoin contains this magical little piece of code: int64 GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 4 years
nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees;
}
If you try to create more than GetBlockValue coins (50, right now) when you get lucky and generate a block, all the other clients will reject it. There are a bunch of other checks to prevent cheating (make sure you actually did the work to find a valid hash for the block, make sure all the transactions in the block are valid, etc), but that simple little piece of code is what restricts the supply. |
|
|
|
I'm mostly libertarian, although I'm sure the more pure libertarians here would call me a fuzzy-headed socialist. Anyway, for seatbelts: Be careful comparing rich, Western countries to poorer countries. As we get richer we value personal safety more, so we demand things like seat belts and air bags in our cars. I believe that our politicians see that demand, then jump on the bandwagon and pass laws that basically everybody thinks are a Good Idea, and then take credit for making us safer. I'm not 100% certain that is true for seatbelts; I haven't actually looked at the graph of traffic fatalities over time, to see if there is a bend in the curve when seatbelt legislation is passed. For smoking: we shouldn't be allowed to do things that hurt, or have a "reasonable" chance to hurt, other people. Personally, I waffle back and forth over whether second-hand smoke imposes an unreasonable chance of harm on others. I've looked at the evidence, and it seems that only people exposed to repeated, long-term secondhand smoke have an increased risk of death. Like spouses or children of smokers. And the smoking bans NEVER apply to private residences. So again, I think politicians may just be jumping on the bandwagon and passing feel-good laws that do no good (although in the last couple of days I read that it looks like grotesque images on cigarette packs ARE measurably effective at reducing smoking). For vaccinations: "herd immunity" from vaccinations is a true "public good," in the strict economic definition of "public good." I think it is fine and dandy for the government to provide true public goods, either directly or (usually better) by supporting/subsidizing private industry. Follow this link for a reasonable, very-smart, mostly-libertarian perspective on public goods. |
|
|
|
The JSON-API wiki page describes all the methods: http://www.bitcoin.org/wiki/doku.php?id=apiThe wiki needs a good re-organization; anybody want to volunteer to revamp the Start page? RE: comment and comment-to : they're stored in your wallet along with the transaction, but not sent over the network. The new gettransaction and listtransactions methods will return them (as "message" and "to"). |
|
|
|
It's not the length of the message that is the problem in any way, at least with text. I mean, even taking into account bandwidth one doesn't care if a message is 5 bytes or 500 bytes. If it includes attachments, yeah it makes sense to penalize huge posts.
The size of a message is not a matter of bandwidth, but rather a matter of mind lazyness. If you read a long message just to realize at the end that it was just crap, then you can consider you got screwed. You would have prefer a shorter message. Therefore short messages has to be rewarded. Thus, to me it make sense to pay more for longer messages. Excessive, lazy quoting (like this message!) should also be discouraged. |
|
|
|
I wrote this three years ago, and I'd still like to see something like it implemented. Now we've got Bitcoin, implementing it might be much easier; I'd love to see a bitcoin bbs/forum that uses these ideas to reward thoughtful, high-quality discussion (replace "email list" everywhere below with "discussion forum" and I think it all still works):
I was listening to " The Ethics of Liberty" yesterday, and it got me thinking about email lists. Most email discussion lists seem to suffer from a Tragedy of the Commons-- there's not a whole lot of motivation for people posting their opinions to think twice about spouting off, or going on and on and on, or otherwise polluting the list with stuff that the subscribers to the list might consider junk. There are a couple of solutions to these kinds of problems. You can try to set up some kind of policing system, with trusted moderators given the power to bless posts, ban people, etc. You need really thick-skinned, generous-hearted, even-tempered moderators for that to work. A solution that works in the real world that hasn't been tried for the email mailing list problem (as far as I know) is some kind of economic system, where the common resource is given a value and anybody wanting to use the resource must pay rent (which is then used to maintain the resource). So, here's a thumbnail sketch of how this might work for an email mailing list: Create an artificial currency. If you have enough of this currency, you're allowed to post messages to the list. Longer posts cost more than shorter posts. Everybody starts with some amount of this currency. Everybody is allowed to use it themselves, give it away, or sell it (for real money!) to people who want to use it to post messages. Every message posted includes ways of: - Tagging the message as "Worthwhile" --> transfers currency from your account to the poster's account. - Tagging the message as "Waste of my Time" --> transfers currency from poster's account to the common pool of currency. The amount of currency in the system is tied to the desired message traffic. We all have a limited attention span; basically, the trick will be to create an artificial economy so that the people who contribute positively are encouraged to contribute more, and people who "pollute" are punished. Currency goes into the system every day (again, based on desired message traffic per day). Some is assigned to new people signing up for the list, and the rest evenly distributed to everybody already on the list. "Lurkers" on the list could either hoard their currency, offer to sell it, or give it away to people from whom they want to hear more. |
|
|
|
I'm reminded of the Y2K hype back in 2000; that was a predictable event that turned out to be a non-event.
When I see somebody claim that Y2K was a non-event, I have to either assume this is a strawman argument or somebody who is completely clueless about what actually happened. ....... But saying that it is a non-issue because other similar kinds of problems have been non-issues is ignoring why they were non-issues in the first place. I don't get it. Y2K was a non-event exactly because it was predictable and so lots of people did lots of work to make sure nothing terribly bad happened. My point is only that the block #210,000 switchover will, I think, be exactly the same. An entirely predictable event that people will plan and prepare for. It will be a significant event only for the very small minority of people who have to do the planning and preparing. RE: complacency: I think we're a lot better at getting complacent about random events (like earthquakes and hurricanes) than "this is absolutely 100% certain to happen on or around this date" events. |
|
|
|
1. I'm allowing people to have more than one address.
2. I'm letting people label each address.
This means I need to use the label as a label, and it also means I can't use it to store the account. So I'm solving this using an external database to store relationship between addresses and users.
You can continue to use accounts as labels, create an each-address-gets-one-label, and map addresses-->user in your database. However, your application will be faster and simpler if you let bitcoin do the addresses-->user mapping (one account per user), and store address-->user-specified-label in your database. The bitcoin 'getaddressesbyaccount' method will give you the addresses-->user relationship, and all the accounting becomes much easier (listtransactions gets you all the transactions associated with a particular user, etc). What happens to the existing label functionality? I have a webapp that uses a label to get an address then uses the address. Will this still work or will I have to change the app to use accounts?
The label methods still work, call the corresponding account methods (e.g. call setlabel <bitcoinaddress> and it calls setaccount), but are deprecated, so they don't show up in the help and will eventually be removed. The only 'potentially breaking change' is the sendtoaddress function, which now returns a transaction id instead of the word 'sent'. |
|
|
|
Was there an interim version of accounts on git at some point that had just ("acentry", "account") for the key?
I just browsed back through the git commit history, and I don't see any interim commits of the account code (I was working in local branches, and didn't push interim versions up). davout: You should try dumping your wallet using the latest bitcointools (dbdump.py --wallet), it will tell you if it finds weird key values in there. |
|
|
|
|
Show Posts
