Several months ago, around the time when the 0.3.9 bugs were found, I privately told Satoshi that I thought whitelisting acceptable transaction types was a better way to go, rather than blacklisting transaction types that we find out cause problems.

The danger is similar websites that try to blacklist <script> tags in HTML entered by users to prevent cross-site-scripting hacks.  See http://ha.ckers.org/xss.html for a nice sampling of how creative hackers can be.

I haven't asked Satoshi if the recent discussion of BitDNS putting extra data in the block chain swayed his opinion or if he woke up in the middle of the night and realized that a creative use of OP_SOMETHING might lead to an exploit.  I don't think it matters; I'm still convinced that whitelisting acceptable transaction types is the right thing to do.

As for "the above option was thrown out by the developers"  -- nothing has been thrown out!  Again, I haven't talked to Satoshi, but I'm open to the idea of a third 'standard' transaction type that includes extra, arbitrary data.   Lets have that discussion, implement it on the -testnet, poke at it, try to imagine all the possible ways it can be misused, try to estimate the benefits and costs... and if there's general consensus that it is a good idea, roll it into production.

There's been exactly one block with non-standard transactions:
  http://blockexplorer.com/b/71036
... and it contained no fees.

HOWEVER:  jgarzik, you're over-reacting, too.  This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid.  Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them.  There will be no havoc.

I'll and add another reason not to have a "list transactions that happened after <txid>" :

move "transactions" don't have a transaction id, but they do affect account balances (and are listed in listtransactions).

Your code is going to get really messy if you expect to call listtransactions and then squirrel away the txid of the last item returned.  If it was "category":"move",  there WILL be no txid...

RE: eliminating polling:  at some point fairly soon, I plan on cleaning up my "monitorreceived" patch, to POST to a URL when transactions come in or blocks are accepted... but I need to do some Deep Thinking to redesign based on lessons learned from 'accounts'.  It might turn into a very minimal API, where the notification is "Hey, txid <123ae4221...> just got to N confirmations, you might want to call gettransaction and getbalance to get up-to-date."

Yes, although the first big feature on my ClearCoin TODO list is a reputation/feedback system.

Thanks for all the great feedback!

Maybe one way to think about ClearCoin is as a tool to help manage risk between buyer and seller.

If the buyer completely trusts the seller, then you don't need ClearCoin-- just send bitcoins directly.
If the seller completely trusts the buyer, then just send the product first.

Usually there's some level of trust/mistrust between buyer and seller.  If you use ClearCoin in creative ways, you should be able to come up with a way of using ClearCoin that balances the risks to both buyers and sellers.

To take davout's example:  The person paying could deposit 20% of the funds in a ClearCoin account, then immediately release that 20% as a "good faith payment".  Then they deposit the other 80%.

That gives an 80/20 risk split.   "Half now, half on delivery" type arrangements can be done the same way.

davidonpda:  You can choose how long your coins will be tied up when you create the escrow account-- one month, six months, or a year.  Of course, the longer they're held the more comfortable the person on the other side of the transaction will be.

PS to Vinnie:  ClearWing Software is the company; ClearCoin is the service.

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.

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.

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.

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:

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).

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...

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.


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:


... in one of my bitcoin.conf files.  The correct syntax is rpcssl=1

Bitcoin contains this magical little piece of code:

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=api

The 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").