I'm very interested in being able to freeze specified addresses so that they won't be used for spending. But I (and, apparently, no one else) had time to work on it before 0.7's release. I'm not sure when I'll have time to work on it.

If you'd like to work on it, it would be helpful. If you decide to do so should start with a RPC interface because the RPC/CLI/GUI-Console is generally the starting point for advanced features.

It's referring to the public key list.
(I don't recall if the outer single quotes are required in the GUI, after I get a copy build I'll check and edit this message)

Oh great, There appears to be a bug with the GUI and some kinds of JSON objects. I thought this was tested, but perhaps it was never tested with arrays. Looking into it.

No. Or rather he'll compute it with the information he already has.
Yes, it can. But no, it is not needed in any case.
Correct, but irrelevant. You do not need the public key to validate the signature.

This is because Bitcoin uses public key recovery.

F'king MATHMATICS. HOW DOES IT WORK?

With the only message and the signature Bitcoin recovers the public key mathematically (technically two more bits are required than the signature, but our signatures include those two bits). The blockchain is not used.  Bitcoin then hashes the recovered public key to get the address. The address is then compared to the address you provide. The public key is not only not required, the verification interface doesn't even give you a place to provide it.

You do not need the public key.
You only need to know the signature, the message being signed, and the address that you're going to compare it to.

I'm so glad the RC is finally cut.  In my opinion, Bitcoin 0.7 is the most exciting release yet.  The new raw transactions API opens up an enormous number of possiblities, and the GUI  "console" makes those and many other advanced features accessible to a larger part of the Bitcoin userbase.

If anyone wants to play around with some fancy transactions on testnet3, let me know.  Joint input mixing transactions are especially fun.

Some extra stuff that makes me excited that didn't make it into Gavin's list:

* Addr.dat becomes peers.dat
-- this moves our peer database into a non-bdb file and eliminates the single most common source of database corruption I've seen reported, it also elimiates some confusing naming (A lot of people didn't like being told to delete their addr.dat— they thought it was their bicoin addresses!)

* loadblock command line parameter
-- Initially created for block loading benchmarking, this command lets you take a blockchain file and load it rapidly into bitcoin but without skipping any of the important security checks. It can be used to securely bootstrap a node from an untrusted blockchain download or be used to repair a node with corrupted indexes.

The "Tor hidden service support" bullet doesn't really do the new hidden service integration justice. It's really great. With this Bitcoin has a fighting chance of staying operable even in places where it's widely filtered, and people using tor with bitcoin are much less likely to accidentally leak identifying information.

If you're looking for some hidden service peers to use with the new Tor integration:  I have a node running at 6hgmaxwellgpv2oe.onion

One of the other things that went along with the raw transaction API is much better tools for inspecting and decoding transactions— and not just your own. From the console (GUI, CLI, or RPC) it's possible to do basically everything blockexplorer does— except look up by address; even for transactions that aren't in your wallet.

Yes, this works. it's unsurprising, and it's not good for security.

You're thinking— But Greg, I gave it like 10 million bits of entropy, it must be secure!

Wrong.  The entropy of your key is

(assuming you chose uniformly).

So say there is a 1/10000 chance someone would use a whole project gutenberg book as a seed. There are 40,000 project gutenberg ebooks.

-log2(1/10000) + -log2(1/40000) = 28.575 bits of entropy. Crackable in moments, since generating a _great_ many keys per second isn't hard for someone who it's confined to offensively slow javascript sha256 implementations.

Your attacker is not a million monkeys smashing typewriters for eons until by chance one produces your work of Shakespeare; your attacker is someone with a strong model of human behavior and a large amount of computing power.  You're up against a decenteralized consortium of geniuses  each commanding a trillion strong army of faultless robots at typewriters.

Against an attack with good models the strength of your key is only the randomness of how you selected it, and may have little to do with the size of the data itself.  Even if you postulate modifications of the book, the attacker can model those too. Changing all the e's to 3's? Sorry snowflake, nothing is original anymore.  And if you do have a strongly random way of choosing libraries, books, and modifications— you're just as well off using that randomness directly.  "Book Foo from library bar, modified thusly" has the same randomness as the actual data. (± the probability that you'd express it that particular way instead of actually doing it)

Humans are terrible at being random. Even when you think you're being clever and extra random you're often not, in fact being clever often makes you less random— you'll only think of a few possible ideas out of the space of all ideas so you can't choose uniformly between them.

Human generated private keys should simply never be used for applications where the keyed material is generally available for attack. Practically no one is able to do so securely, and a lot of people think they can but they really can't. Must of the common advice about passwords/keys is inapplicable for a case where attackers all over the world can instantly begin testing at enormous rates or apply precomputation attacks without having to compromise something first.

Your coins are immature.
Mined coins will not be added to the balance for a 120 blocks after they are created.

It exists precisely to prevent the early bloat before Bitcoin can scale to or justify that this thread is concerned with.

Public key recovery is possible with it if a trivial modification is made. (IIRC the algorithm, for mostly belt-and-suspenders reasons mixes a hash of the expected pubkey into the value being signed, so this would need to be changed to the hash of the address instead)

It's probably bad that I can't tell if you mean maxtxfee to be an absolute maximum or a max per KB.

It's perfectly possible to do a 'recovery' with a purely user provided string. This is one thing SDSK addresses.

The point of these scheme is basically forces the input to not be some insecure user generated string, or at least imposes a computational tradeoff in order to make a more arbitrary scheme valid.  In theory, the seeds used for this would be secure with just a single SHA256 (because they have lots and lots of real entropy).

Since we can't be absolutely sure of that, it would be nicer to use more computational expense in the strengthening. Unfortunately there is a fine line: People seem to be hell bent on using KDFs implemented in python and javascript which are a thousand times slower than native ones.  This means that "adequate" KDF from the cpu perspective is intolerable from a JS generating tool.

If the self-descriptive strengthened keying is not weak enough to be fast in these usecases then it just won't be adopted and people will continue to use sha256(password) Javascript web generators.

There absolutely is, http://bitcoin.org/bitcoin.pdf  Section 10.


Only partially. The sender can opt-in. The receiver gets it if sender chose, if they like it or not. Further downstream users— who's identity is now more disclosed by association with a named entity in the block-chain— don't really get a say at all.  The hundreds of thousands of other uninterested nodes will waste cpu cycles validating these signatures (and the pointless transactions required to create the inputs) and storage recording them, even those these transactions do not serve to further their interests in the way that general blockchain validation does.  They could, of course, filter out the ones that they're aware of, but unless they all do it they'll be forced to validate them when they are mined or risk their security.

There are many sources of cost here and most of them are externalized.


It doesn't.  A transaction requires only the keys being online that sign for the particular input coins.  Prudent key management would have those keys used only once.   A marker address is a long term key.  In-band marker address usage requires constantly assigning funds do a long term key.  It's a bad practice and increases the exposure to theft, if only marginally.


Bitcoin has gone to rather extraordinary lengths to avoid including any more data than strictly necessary in the globally and eternally visible flooded blockchain. The only data included is the minimum required to have the system be fully decentralized, secure, and inflation proof. This information is in the interest of all bitcoin users: we want to protect you from double spends because we want to prevent inflation in order to make Bitcoin useful.  If it were believed to be viable to include a memo field in transactions there would be one; it isn't like the usefulness of them is a surprise (the old IP transactions had a memo field, in fact, but they never showed up in the public network.)

There is no mechanism available to directly compensate most of the parties that undertake the costs created by a third party's use of in-band marker addresses.


There is no reason that other schemes can't be made just as easy— or even easier, since they have a chance of being integrated. Validating a detached signature using blockexplorer could be as simple as following a link.  E.g. With a simple bit of JS,  http://blockexplorer.com/tx/eb620fe4cdc24afbd2ded229577c64fbb099a39e80bcc15750b84c04b7878d90#G7mlJ2Db1W68LQPkqNt0UAyEE9xNI4KVMxy/GSwI/TU8GH2rUzs7jKFr9yq6M43zsKUHlqIF9HQ1pypvWpuUg8E=   could display  "This transaction is certified against reversal by 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB"

Of course, as Pieter points out— payment protocols are even more powerful. There are a lot of superior options.

My concern is that things like inband-marker addresses discourage the implementation of better solutions which have fewer compromises simply because it has a lower startup cost.  As a community we need to resist that kind of lazyness if we're to keep our system healthy.

Edit: With some code from Joric, I setup exactly the validation I described above. The signature checking is all client side, so the normal operaiton of the site doesn't even cause them to learn the relevant marker addresses being checked unless they go out of their way to inject monitoring code.

Thats unfortunate, because they're really a bad idea.

There are multiple problems with marker addresses but foremost among them is that they're incompatible with Bitcoin's privacy model and their use harms the privacy of not only the people who use them but also people who transact with people who use them (and so on, transitively with decaying harm). They also encourage poor key management practices (e.g. constantly assigning funds to a long term online key which is potentially subject to theft), and an additional burden on the public network to convey store additional information that is only interesting to a single pair of parties.

We added the signmessage feature in order to have detached, private, identification authentication available. Rather than in-band marking a party can trivially sign a transaction ID with an address reserved for that purpose and then pass it over whatever mechanism they like (including appending the signature to the normal transaction ID they display).   This avoids all of the concerns above related to marker addresses.

So, one point thats a minor engineering thing but important is that you should _not_  be using the same key for currency transactions and mining, because it's reasonable and prudent to keep large volumes of coins offline or at least encrypted. There are a bunch of ways to do this (persistent delegations, one time delegations, ECC math related keys) which have different consequences; I think it's just important to do one.

As far as the overall design goes, it seems to me that it has a weakness I'd call "unavailability of the preferable alternative" or a hobson's-choice-attack that I think exists in all the stochastic PoS schemes I've looked at.

Lets say there exists a pair of short competing forks.  There is an earlier fork, the one you heard first and a competing later one. Network convergence demands you sign the earlier one, but you're not the chosen miner for the blocks there. You are, however, a chosen node in the weaker fork.  You (like almost all users) have no transactions that would be reversed by mining in one over the other.... so you confirm the weaker one because _doing so cost you nothing, and in the event that it does win, you get more coin that way, so doing so is the rational action_. Your choice isn't "Fork A" or "Fork B", it's "sign" or "do nothing"  _independently_ on each fork you're permitted to sign, and signing costs you nothing and has a non-zero expected return.   With PoW you're burning a finite resource on your preferred choice, and you can't simultaneously mine multiple forks without diluting your resources.

This happens is because your stochastic PoS has the property that the existence of a fork expands the network wide pool of stake producing capacity. At least, opposed to some other schemes, creating that fork still requires a POW investment so at least thats good.

I'd have to think harder and see more concrete details to do a real analysis, but I think if you think of this under the Byzantine Altruistic Rational model (BAR; Byzantine participants want to burn the earth, Altruistic help out at their own expense, Rational make fairly short term greedy self-interested decisions), I think your scheme defends against byzantine faults better than Bitcoin if and only if your population is very altruist heavy instead of rational. It requires participants to sign the single convergence optimal chain and only that chain, even though doing something else would make them more coin. I think altruistic-heavy is unlikely: just holding a lot of currency for the sake of being able to mine it has a real cost associated with it, so its demanding a lot of expenditure from altruists in the form of stationary funds.

If instead the population is rational heavy I would expect your scheme to _increase_ the amount of time required to become confident that a reorg will not happen_ even absent a byzantine attacker_ because a shorter fork may, by luck of which users are on or offline, gather signatures faster and become the rational target for the pow workers to extend, then it's competitor could catch up when some signers wake back up, and so on.   While this instability wouldn't extend beyond your signing horizon, you'd likely lose stability within it, and it also potentially presents interesting attacks against newly bootstrapping nodes.  (e.g. a late created fork with lying timestamps with 1/3rd the POW difficulty but every single block signed because they're all held by an attacker)

Exactly.


Luke is talking about block withholding. We know how to fix it for centralized pools in an incompatible way— as luke points out, though not for fully decentralized pools.


Even most SHA256 "breaks" would not necessitate or justify a POW change (though might require the replacement of SHA256 _everywhere else_ in the protocol). E.g. the existent breaks for MD5 wouldn't make us move away from an MD5 POW if we were using it for that.

As Luke says, there could be reasons to justify altering the POW, but they're not things that would come quietly or subtly.   E.g. things like an active monopolizing super-majority attacker on the current POW.  Breaking everything is justified when the alternative is everything being even more broken, but not otherwise.

Or, potentially fictitious income.

A plan for extreme profit:
(1) Create highly blockchain visible service
(2) Use it yourself in high volume to create the appearance of large income
(3) Raise 34500 BTC from selling shares in an IPO
(4) PROFIT!

I don't have any reason to believe this to be the case here— beyond a remaining flicker of hope that so many of my fellow men are not actually stupid enough to throw away thousands of BTC on what is apparently the least entertaining gambling site ever created— but nor can I exclude that possibility from the data made available.

Caveat Emptor.

We do want that functionality, mostly to make it so that users using the raw transaction api can mix it with regular wallet usage without stepping on themselves.


This is very much incompatible with how encryption in Bitcoin works today. And I think we'd be unlikely to accept patches to change it to make that work.

Today there is a master key which is used to encrypt all the private keys, and the master key is encrypted with a KDF expanded passphrase from the user. This makes it possible to change the passphrase without rewriting all the private key material.

It's also important to note that bitcoin's account feature is __NOT__ multiple wallets, spending from any account can spend any coins, including ones that were previously paid to another account.


If you make use of a private key then someone going through memory could get a copy of it, end of story.

What you are asking for could be accomplished via the raw transaction API, but you'd end up having to implement all of the wallet functionality in your own code. It could also be accomplished through multi-wallet support, which is something that I think we want long term but isn't being directly worked on right now.

But I think what you actually want really involves multisig or at least client side signing... because without that a sever compromise still results in compromising at least the private keys that get used during the compromise.

You've basically got it. You don't need to dump or provide the private key: Those parameters are optional— they're used for cases where the relevant keys aren't in your local wallet.

Here are some quick walk-throughs I'm working on that use this api:

https://people.xiph.org/~greg/escrowexample.txt
https://people.xiph.org/~greg/signdemo.txt

Thats not the official git repository, thats gavin's staging repository for pull requests.

The official one is https://github.com/bitcoin/bitcoin/ and it's linked from the bitcoin.org site.

The RPC is getrawtransaction (no s).