Why do people include transaction fees?

Assuming the miner hasn't tweaked the reference code's parameters, the rules are:

Create at most a 250,000 byte block:
+ 27 kilobytes of space is set aside for the highest-priority transactions, regardless of fee.
+ 223k of space left for fee-paying transactions.

Transactions with a small number of inputs/outputs, transferring a large number of bitcoins, that weren't recently received are the highest priority and are included first.

If you send a low-priority transaction without a fee you can end up waiting a very long time for it to get confirmed (and it may never be confirmed).

Why do miners include free transactions?

Either they're too lazy to change the default rules, or they believe that allowing free, high-priority transactions will help make Bitcoin more popular and will, therefore, increase the value of their coins.

Why is there any incentive to pay fees at all?

You'll notice that pretty much every block nowadays is bigger than 27k, so there IS competition for that free space. But if you've got 10 bitcoins that have been sitting in your wallet for a week or three, you'll still have no problem spending them without a fee (they'll have a much higher priority than somebody playing SatoshiDice 100 times a day).

I hereby encourage everybody to use tor.

But I think worrying about thugs getting your street address from your Internet service provider and then breaking into your house to try to coerce you into giving them your Bitcoins seems very unlikely.

The windows setup.exe is signed, as is the Mac .app bundle. The executables inside them are not signed (I can't think of a good reason to sign them, it would not increase download security at all).

You can also still check the download packages using the SHASUMS.asc file, which is signed with my gpg key.

And if you are running Linux or Windows you could check all of the files in the installer against other core developer's keys.

If the code signing certificate was revoked then we would go back to just using gpg keys. The code signing certificate is great because Windows and OSX know how to check it automatically when the download happens.

The crash-on-exit bug could be this issue:  https://github.com/bitcoin/bitcoin/issues/2204

We may have to live with it for the 0.8 release, and fix it in the next release, because there is a high risk that fixing it will cause more problems than it solves.

Bitcoin version 0.8.0 release candidate 1 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/test

This is a major release designed to improve performance and handle the
increasing volume of transactions on the network.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

Release-candidate 1 notes:

The OSX binary reports its version as "0.8.0rc1-1-gba1d080-beta" due to
issue https://github.com/bitcoin/bitcoin/issues/2285 . This will be fixed
before the final 0.8.0 release.

The Windows binaries could not be reproducibly built, due to issue
https://github.com/bitcoin/bitcoin/issues/2288 . This will also be fixed
before the final 0.8.0 release. The rc1 Windows binaries were built
by me (Gavin).



How to Upgrade
--------------

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoin-qt (on Linux).

The first time you run after the upgrade a re-indexing process will be
started that will take anywhere from 30 minutes to several hours,
depending on the speed of your machine. If you have enough
memory, running with the -dbcache setting (e.g. -dbcache=1000 )
may make re-indexing faster.

Special notes for release candidate 1:
--------------------------------------

If you helped test pre-release versions, there are two changes that you
should be aware of:

1. Subdirectories in the data directory changed names; to avoid re-indexing
the blockchain, rename:
  mkdir $DATADIR/blocks && mv $DATADIR/blktree $DATADIR/blocks/index
  mv $DATADIR/coins $DATADIR/chainstate

2. The "undo file" format changed; if you see errors at startup during block
validation re-run with the -reindex flag to fix them.

Incompatible Changes
--------------------

This release no longer maintains a full index of historical transaction ids
by default, so looking up an arbitrary transaction using the getrawtransaction
RPC call will not work. If you need that functionality, you must run once
with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
details).

Improvements
------------

Mac and Windows binaries are signed with certificates owned by the Bitcoin
Foundation, to be compatible with the new security features in OSX 10.8 and
Windows 8.

LevelDB, a fast, open-source, non-relational database from Google, is
now used to store transaction and block indices.  LevelDB works much better
on machines with slow I/O and is faster in general. Berkeley DB is now only
used for the wallet.dat file (public and private wallet keys and transactions
relevant to you).

Pieter Wuille implemented many optimizations to the way transactions are
verified, so a running, synchronized node uses much less memory and does
much less I/O. He also implemented parallel signature checking, so if you
have a multi-CPU machine all CPUs will be used to verify transactions.

New Features
------------

"Bloom filter" support in the network protocol for sending only relevant transactions to
lightweight clients.

contrib/verifysfbinaries is a shell-script to verify that the binary downloads
at sourceforge have not been tampered with. If you are able, you can help make
everybody's downloads more secure by running this occasionally to check PGP
signatures against download file checksums.

contrib/spendfrom is a python-language command-line utility that demonstrates
how to use the "raw transactions" JSON-RPC api to send coins received from particular
addresses (also known as "coin control").

New/changed settings (command-line or bitcoin.conf file)
--------------------------------------------------------

dbcache : now controls LevelDB memory usage. Running with (for example) -dbcache=1000
will use a gigabyte of memory and might make the initial blockchain download faster.

par : controls how many threads to use to validate transactions. Defaults to the number
of CPUs on your machine, use -par=1 to limit to a single CPU.

txindex : maintains an extra index of old, spent transaction ids so they will be found
by the getrawtransaction JSON-RPC method.

reindex : rebuild block and transaction indices from the downloaded block data.

New JSON-RPC API Features
-------------------------

lockunspent / listlockunspent allow locking transaction outputs for a period of time so
they will not be spent by other processes that might be accessing the same wallet.

addnode / getaddednodeinfo methods, to connect to specific peers without restarting.

importprivkey now takes an optional boolean parameter (default true) to control whether
or not to rescan the blockchain for transactions after importing a new private key.

Important Bug Fixes
-------------------

Privacy leak: the position of the "change" output in most transactions was not being
properly randomized, making network analysis of the transaction graph to identify
users' wallets easier.

Zero-confirmation transaction vulnerability: accepting zero-confirmation transactions
(transactions that have not yet been included in a block) from somebody you do not
trust is still not recommended, because there will always be ways for attackers to
double-spend zero-confirmation transactions. However, this release includes a bug
fix that makes it a little bit more difficult for attackers to double-spend a
certain type ("lockTime in the future") of zero-confirmation transaction.

Dependency Changes
------------------

Qt 4.8.3 (compiling against older versions of Qt 4 should continue to work)


Thanks to everybody who contributed to this release:
----------------------------------------------------

Alexander Kjeldaas
Andrey Alekseenko
Arnav Singh
Christian von Roques
Eric Lombrozo
Forrest Voight
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Luke Dashjr
Matt Corallo
Mike Cassano
Mike Hearn
Peter Todd
Philip Kaufmann
Pieter Wuille
Richard Schwab
Robert Backhaus
Rune K. Svendsen
Sergio Demian Lerner
Wladimir J. van der Laan
burger2
default
fanquake
grimd34th
justmoon
redshark1802
tucenaber
xanatos

The magic of public key crypto is that you can give somebody your public key, some data, and a signature, and they can be certain that:

a) that particular signature could only have been created by somebody that has the private key that corresponds to the public key
b) the data hasn't been changed in any way

They don't need to know the private key-- you keep it secret.

The "hash over..." bit is the way digital signatures work-- you sign a hash of the data, and not the data itself, because the hash is much smaller.

The "...simplified version of the transaction" bit is complicated. The data signed is the transaction minus all it's scriptSig signatures, plus (almost always) the previous transaction's scriptPubKey. See the OP_CHECKSIG page on the wiki for all the gory details.

Got a fantastic idea for a project, but need some BTC to make it happen?

Apply for a grant from the Bitcoin Foundation:
  https://bitcoinfoundation.org/blog/?p=58

Deadline is February 15'th.

Good grant proposals are for things that are clearly a benefit to the whole Bitcoin ecosystem and that are the kind of "common good" thing that doesn't have a clear business plan.  (if you have an idea with a clear business plan then you should talk to an angel investor or venture capitalist to get some funding).

Examples (I'm sure you can think of better):

• I'd love to see somebody run a free input-mixing service. A grant could cover server costs to run a server that takes connections over tor to coordinate mixes.
• Know any economists? A grant could pay to write some tools to extra bitcoin transaction data for an enterprising economist who might want to study the Bitcoin economy.
• There have been some very interesting research papers suggesting possible changes to core Bitcoin. A grant might pay for somebody to actually implement the ideas and demonstrate them on the -testnet.

I'm of the opinion that bitcoind/Bitcoin-Qt shouldn't be pushed to the central/canonical repos until we hit version 1.0.

Until then, I think we change too much too often (e.g. the blockchain format completely changed in the 0.8 release, and the wallet format will likely be changed before we hit version 1.0).

The payment protocol (or a simple extension of it) is intended to be that more-flexible, standardized protocol.


Excellent!

I think this is exactly the right thing to do.

There is still the question of what the default behavior should be. Here is a proposal:

Ignore blocks that take your node longer than N seconds to verify.

I'd propose that N be:  60 seconds if you are catching up with the blockchain.  5 seconds if you are all caught-up.  But allow miners/merchants/users to easily change those defaults.

Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.

Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."

Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).

Ummm, see this old forum thread, where Satoshi says:

Yeah-- "democratic" is such a loaded word. Everybody loves democracy, so I didn't want to bash it.

But democracy can be terrible if you're in the minority and the majority decides to trample on your rights.

I probably should have just said "Bitcoin is a lot more democratic than the system we currently have, where a handful of unelected central bankers control our money."

For the record:

I'm on the "let there be no fixed maximum block size" side of the debate right now.

I think we should let miners decide on the maximum size of blocks that they'll build on. I'd like to see somebody come up with a model for time-to-transmit-and-receive-and-validate-a-block versus increased-chance-that-block-will-be-an-orphan.

Because that is the tradeoff that will keep miners from producing 1 Terabyte blocks (or, at least, would keep them from producing 1 Terabyte blocks right now-- if we have petabyte thumb-drives and Terabyte/second networks in 10 years maybe 1Terabyte blocks will be just fine).

Right now, miners that use the reference implementation and don't change any settings will produce blocks no larger than 250Kbytes big.

So we're finding out right now how miners collectively react to bumping up against a block size limit. I'd like to let that experiment run for at least a few months before arguing that we do or do not need to eliminate the 1MB hard limit, and start arguing about what the default rules for acceptable block size should be.

Sergio:

It would be more helpful if you either took a little bit more time and actually wrote a little bit of code to make sure the attack works, and started the conversation privately with "here's code that demonstrates a very expensive-to-verify transaction and a few suggestions on how you might fix it..."

I created a simulation of TxPrep/TxAttack by adding them to src/test/data/script_valid.json and then running through the script_tests.cpp unit test in the debugger, and with the particular TxPrep you propose there is no problem with current code.

Also, TxAttack is not standard with the latest code; see CTransaction::AreInputsStandard(), which checks the scriptPubKeys being spent.

RE:  undocumented process of responsible disclosing :  good point.  Where would you expect to find the process documented?  We can fix that...

Starting now!

Thanks Sergio!

So:  if the attacker creates a block with a transaction that takes 3 minutes to verify, and then broadcasts it, it will take a very long time for it to propagate across the network (because peers verify blocks before relaying them).

And since this attack requires non-standard transactions, mining a block is the only way an attacker will be able to pull off this attack. So I don't think this is a practical attack on the production network: by the time the 3-minute-to-verify block got to 50% of the network the other half of the network will probably have produced a block (sure, the attacker could try to Sybil the network and send its block to a super-majority of mining nodes, but I bet all of the big mining pools are hiding their block-creating and share-accepting nodes behind multiple "front-end bitcoinds" by now to mitigate DDoS attacks).

Fixing the OP_*SIG opcodes so they "look before they hash" is a good idea. We're actually moving towards that; see fStrictEncodings and the IsCanonicalSignature/IsCanonicalPubKey in the latest script.cpp code. The intent is to eventually roll out a 'soft-fork' that requires signatures and public keys be well-formed and canonical.

Also, a nit: using OP_0 for the scriptSig wouldn't work for this attack (see if (vchSig.empty()) return false; in CheckSig()).

Okey dokey, first I think nobody should use an easy-to-memorize brainwallet for anything more than experimenting. I predict we'll start seeing very unhappy brainwallet users reporting huge losses sooner or later.

Second: the 'sentinel wallet' idea is all about incentives.

You need to put enough BTC in the sentinel wallet so it is economically rational for an attacker to "take the money and run" rather than spend time and money trying to crack a bigger brainwallet that might not even exist.

Again, I don't think you should use a brainwallet, so I'm not motivated to do the math to figure out how many BTC you should put into the sentinel wallet so a ration attacker will just take it, but that is the way you should think about it.

Run a testnet node and turn on CPU mining. We need more stable, long-running -testnet nodes.

I don't think anybody knows. But you can find out:

Send a token amount of bitcoin to two more brainwallets, made from each of the sentences.

When somebody else either spends those bitcoins or sends more bitcoins to them, you know that your main brainwallet isn't safe any more.  (are the services that will send you an email when there is activity on a bitcoin address still around?)