The send RPC methods return a transaction id.

Pass the transaction id to the gettransaction RPC method, and it will give you details of the transaction, including what fees were paid.

In the future, there will be many more than 4,000 transactions per block.

-nolisten turns on -noirc.

Try:

addnode=69.164.218.197

... to connect to the testnet Faucet bitcoind.

The input-transaction-selection algorithm in bitcoin tries to use older transactions, which will have higher priority.

I'd guess that online wallets with lots of users have plenty of old transaction to choose from, so they don't need to pay transaction fees.  Actually, it'd be interesting to try to measure how quickly the average bitcoin in an e-wallet stays in the wallet before being used for an outgoing transaction...

Neat idea!  All sorts of chicken-and-egg hurdles to overcome (what good is a bitcoin loan if there is nothing to spend the bitcoins on?), but microlending bitcoins would be great.  I'm spread a little thin at the moment, but if you think a conversation with kiva right now might be worthwhile then go for it.  You don't need anybody's permission or advice to become the Bitcoin-Kiva Liason Officer.

Your 0.07 transaction is very-low-priority, and still waiting to get in a block.  From bitcoincharts:

It might take a few days, but it will eventually get confirmed.

Why would you "bring up the issue" ?

Just declare bitcoin-related income or capital gains as income, and bitcoin-related expenses as expenses, translated into units that the IRS understands (dollars), and follow the rules for WHEN you must declare income, capital gains and expenses and I bet a bitcoin you'll be just fine, even if you get audited.

That's actually a very hard attack to successfully pull off; I file it under "theoretically worrisome, but practically not a high priority."

It is hard because:
  + targeting a particular node is hard.  The long-running nodes that you probably want to target (merchants or exchangers or e-wallet services, where double-spending could get you a significant number of bitcoins) will already have 50+ connections to legitimate nodes, and an addr.dat full of the addresses/ports of legitimate nodes.

  + you have to feed the target a bogus version of the block chain.  And you won't be able to feed them new blocks very fast, because difficulty is so high (unless you invest a ton of hashing power to generate bogus blocks... but that's stupid, you're wasting money mining worthless blocks so you can try to pull off a probably-low-value double-spend???).  Anybody you target is going to wonder why their transactions are taking so long to confirm and why their block count is falling behind everybody else's.


Putting a few addnode=...  to connect to trusted nodes (with static IP addresses) at startup in your bitcoin.conf is a good idea. 

For (3), detecting dramatic, statistically-nearly-impossible-normally changes in the hashing rate is a better way to detect sybil attacks.  That's on my personal "it'd be nice to have" list (because, as I said, I don't think this is a big threat).

All this talk about neato-spiffy future hub-and-spoke supernodes-and-leaves architecture is great.

But I was kinda thinking of first solving the problem that anybody who just wants to download the client, get a few coins from a friend, and then spend them on something has to wait a very long time right now.  That doesn't require any re-architecting of the system or any new networking messages, and should make the "out of the box" bitcoin experience much better for lots of people.

And it is a step towards a future neato-spiffy Uber-efficient hyper++client.

Because that requires that you do some math to figure out how many to send to pay the escrow plus release the right amount.

And because I'm planning on eventually implementing "receiver creates and pays" escrow transactions, so merchants can setup escrow transactions (via the API) for their customers.  Merchants are used to paying fees as just a cost of doing business.

RE: how will I prevent you from creating new escrow transactions if you don't pay?  Click on "Create Escrow" and you'll be taken to a page that politely explains you're not allowed until you pay.  If you use the API, the create_escrow call will fail.

I realize some people may try to cheat by using/creating multiple Google accounts.  That will be a cost of doing business for me.  Perhaps I will reserve the right to publish deadbeat account email addresses on a "hall of shame..."  (I'd implement a Terms of Service Agreement to which you would have to agree before creating a new escrow)

RE: will this affect coins in existing escrow accounts:

No, existing escrow accounts will be unaffected, these new rules will be for new escrow accounts only.

I've been working on making the ClearCoin escrow service's fee structure simpler; here's the new structure, which will "go live" in the next day or two:

ClearCoin costs 0.5% (one half of one percent) of released coins. For example, if you are paying for something worth 100 bitcoins the cost will be 0.5 BTC.

Fees are paid only on released coins; no fees are charged on coins donated to charity or refunded to you.

Coins in escrow will never be taken or held if you have unpaid fees; if you do not pay your ClearCoin fees within 30 days we may prevent you from creating new escrow transactions but will never prevent you from releasing coins from existing escrow accounts. However, given how quickly the value of bitcoins has been increasing recently, it is better for you to pay your ClearCoin fees quickly.

Any month you accumulate more than a trivial amount of fees ClearCoin will email you an invoice with a detailed list and a bitcoin address to which you can send payment.  You can also pay at any time by sending bitcoins to an address on the ClearCoin website.


All of these changes were prompted because I think it was confusing to pay fees directly from the bitcoins being used for the transactions-- if you were paying for something that cost 159.95 BTC, calculating how much to send to pay for the cost AND ClearCoin fees was complicated.  This should also be much easier for anybody creating a lot of ClearCoin transactions via the new ClearCoin API.

As always, feedback, complaints, and suggestions are welcome.

Raw dump of the notes I got from Satoshi with the headersonly patch (which is in the git tree as headersonly branch):

My plan was to dive into what Satoshi wrote already, understand it, test it in fClient=true mode (sending/receiving/relaying transactions on testnet), fix whatever is broken/unimplemented.

And then write code to switch from fClient=true to fClient=false, downloading full blocks, etc.  And then writing code that does the toggle when generation is turned on for the first time or when getwork is called (I think those are the only times you need full blocks).

I haven't looked at or thought about the relaying code.  Simply relaying all transactions (without checking to see if they're valid) if fClient=true should work nicely.

If I were going to implement it...  hmm...

I think I'd just special-case the genesis block, so it has a value out of, oh, I dunno, 20 million CompleCoins.  Then maybe fix the mining reward to something small and constant (say 0.001 CompleCoin per block, forever-- or whatever you like).

The central authority would create the genesis block, and so would have 20 million CompleCoins that it could issue (aka spend) however it pleased.

The risk would be the central issuer ever losing control of its wallet/private key.  That risk could be mitigated a little bit by occasionally changing the key by spending all of the non-issued coins to a new address in a new, secure wallet somewhere and waiting a few blocks for confirmation.

I'm having lunch today with somebody else who is interested in using bitcoin tech for a centrally issued alternative currency, so I've been thinking a bit about it...

I'd tweak the formula to be:  max block size = 1000000 + (int64)(difficulty)

... just to avoid "if block number is < X max block size = 1000000 else..." logic.  Adding in the current 1MB max limit means all the old blocks are valid under the new rule.

I like Mike's point that difficulty and transaction volume aren't necessarily related.  Maybe a better formula for miners would be something like:

max block size = 1000000 + (average size of last N blocks in the best chain)
... where N is maybe 144 (smooth over 24-hours of transactions)

Anybody have access to what Visa daily transaction volume looks like in the days around Christmas?  Are there huge, sudden spikes that the above formula wouldn't handle?

So whenever you meet (or communicate with) somebody who owns bitbills check your bills' public address against their bills' public address.  If there is significant counterfeiting going on, eventually you'll find a match.  Try to redeem both and you'll quickly find out which is real and which is counterfeit (or that both are counterfeit).

I was going to suggest creating a public Google Documents doc where people could enter their bitbill public keys, but griefers could just look at the block chain and pretend that they were holding bitbills that they don't actually own.

Wait a while and they will be free again.

If you are sending 1 BTC (that you just received) in a 250 byte transaction, you need to wait 24 hours (1 day).
Send 0.25 BTC, you'll need to wait 4 days.
Send just 0.01 BTC as a 250 byte transaction, and you need to wait 100 days before you'll be allowed to send it for free.

priority is calculated as:  #BTC * #confirmations / transaction size.
Very-low-priority is defined as less than 1 * 144 / 250   (1 BTC, 144 confirmations == 24 hours, 250 bytes), and they require a fee.

The tentative plan is for fees to be reduced to 5 mils (0.005 BTC) half a mil (0.0005 BTC) for the next release.  Changing the definition of "very low priority" at the same time probably makes sense.

(corrected proposed fee)

giraffe.heliacal.net is also known as irc.lfnet.org

Laszlo runs that IRC chat server, and bitcoin uses it to "bootstrap" to find other machines running bitcoin.

Unless you run with the -noirc switch, in which case it won't -- it will try to connect via a list of compiled-in 'seed nodes' (which I'll try really hard to remember to recruit somebody to update for the next release).

After you've run bitcoin once, it stores nodes you were able to connect with in the addr.dat file, so you can run -noirc just fine.  But if everybody did that, newbies who just downloaded bitcoin would have a hard time finding people to connect with.

bitcredit:  do you have ideas or suggestions?

I think a global currency like bitcoin will do a lot to promote understanding and diversity, but did you have something specific in mind?

Sure, I'd like to see a lot more banging on the testnet to try to break it.

(python code is not obfuscated, I assume).

Golly, journeyofrivers is really going to hate me when he finds out I'm an Elected Official and a Cog in the System.  Last night I voted to steal millions of dollars from taxpayers and give it to public (I know!  Terrible!) schools.

(I'm only barely an elected official, one of 251 elected Amherst Town Meeting members.  My punishment is long boring meetings late at night a couple times a year...)

Seriously, we probably agree on most things on a philosophical level.  I just believe I'll get farther by taking "small steps to a much better world."