That's the key assumption. If it's invalidated there will be a difference in actual payout between different ways to treat invalid blocks. There's no bias (for methods like prop) one way or the other so I don't think it really matters much, but there is at least a conceptual difference, and I think kano is entitled to consider one way as more proper.

Resets what to 0?

I think what kano is trying to say is that, since invalid block is equivalent to no block, the existence of an invalid block shouldn't affect people's scores. So in a method like proportional, people's scores shouldn't be reset to 0 for invalid blocks.

The problems with his approach are that:
1. It's more complicated to implement.
2. It doesn't matter that much in the case he is considering.
3. It assumes using the proportional method. For PPLNS it's moot since scores aren't updated upon finding blocks. For DGM it matters somewhat since scores are meaningfully updated on blocks, but as I derived some time ago, the correct way to handle this and ensure a fair reward is to update the scores on any block, even if it is invalid. But I was surprised that Graet implied that scores are reset to 0, unless I misunderstood or missing an implementation detail, this could imply an error in his DGM.

Deepbit has proportional and PPS options, proportional is 3%, PPS is 10%.

This will make vanity addresses even better, they'll be like collector's items .

But I'm guessing the techniques we are developing here may have some use even if Bitcoin addresses as we know them become obsolete.

ETA: Also, if I understand correctly, some form of address will still be used as an implementation detail, but just won't be externalized to end users. In this sense they will be like IP addresses - nobody knows which IP they're visiting, but they still exist. I suspect that if one could get a "vanity IP address" there would be a market for that, so no reason Bitcoin addresses would be different.

So, gloom and doom injection thwarted .

In a nutshell, a pool which doesn't submit block headers to its miners, rather submits an address and accepts as shares any block header (with low enough hash) which credits this address in the generation transaction (with a Merkle branch to prove it). The miner can either construct the block locally or get it from an unrelated getwork server. Hence the pool, which handles rewards and can reduce variance more effectively if it is large, is split from the agent responsible to decide what is being hashed.

None that I know of. Maybe it's time to start lobbying for one.

This of course can be solved with a deposit system. A customer pays a deposit to a miner for including him in his search. If the customer defects the miner confiscates the deposit, and if the customer wants to quit (say, if someone found him an address) he gets the deposit back. The size of the deposit needs to cover the average cost of a squandered address. The deposit size can be reduced if the miner periodically quizzes the client, then the deposit only needs to equal the worth of the work between quizzes. This requires the client's system to be online at all times.

This will work much better if instead of direct interaction between clients and miners, there will be a small number of "vanity pools" which accept contracts from clients and keeps deposits, and distribute work to miners. Pools can build some sort of reputation so clients can feel safe keeping a deposit with them.

This needs to be "T & (P | R)" where P has a private key and R is a nonce. Otherwise the miner could maliciously generate R with a private key and steal the money.

This is a challenge. One possible approach (and again I hope I'm not reinventing the wheel) is to have a body of n arbiters which are assumed do not all collude. Each will generate a private key bi and public key Bi. The Bi's will be distributed among miners. The miner generates a pair d, D and tries different nonces C in the transaction script (B1 & B2 & ... & Bn) & (C | D) . If the resulting address matches a pattern, he informs the arbiters who the client is. He sends C to the client and each arbiter send his bi to the client. Each arbiter then deletes the key and generates a new pair to be used for the next completed address and broadcasts the public key to all miners. Then the only way to steal the funds is if all arbiters collude and share the client's keys.

This endeavor is worth what its purchaser will pay for it. I can think of two main reasons to use vanity addresses:

1. Well, vanity - to show the world you have an intensional address with a harder pattern than other people. Then it doesn't matter at all how hard or easy it is, there will be a market of those who want harder than average.

2. To have a simple firstbits address - then generally you want the vanity pattern as short as possible while being unique. The length it takes to be unique is fixed, so if generating addresses is too easy there will be no market for generation since anyone can generate the required address.

So, harder generation is better for generators and for businesses wanting to protect their brand, indifferent for most other people.

You are a great necromancer. Not every day I see in "Updated Topics" a thread title I don't recognize.

As I said before, p2pool is a solution but not the only solution, you can also have split pools. And p2pool isn't really good for at-home miners, it's more suitable for large miners and proxy pools.

I tried to search for prior mentions of this application but couldn't find any. Probably should have searched harder, I see now there are in the next-to-last page in the VanityGen thread.

If we're going for general scripts we don't even need these EC operations. Use an A & (B|C) transaction (that's possible, right?) where A is generated by the client, B is generated by the miner and C is filler.

Edit: A is what allows you to outsource the generation without doing EC addition/multiplication per attempt.

Tools such as Vanitygen used to generate vanity addresses, Bitcoin addresses which follow a specific pattern, have been somewhat popular.

Generating a vanity address is a computationally intensive task, more so the more specific the pattern. It is conceivable that some people would like a vanity address but lack the appropriate hardware to generate it. Others may have the necessary hardware but not sufficient interest in an address. This suggests the need for a vanity market where clients outsource the production of addresses to generators for an agreed upon fee.

Ostensibly, this suffers from the problem of the need for secrecy - whoever generates the address has access to the corresponding private key, but the client who is to be the owner of the address must remain the sole person knowing the private key. This problem can be solved with some ECDSA magic of the kind discussed here.

The way it would work is this:

1. Client generates himself a single private key c and corresponding public key c*G. He also chooses a pattern P.
2. Client keeps c secret, but submits c*G and P to the generator.
3. Generator repeatedly generates a private key g, calculates g*c*G and checks if the address generated from the public key g*c*G matches the pattern P.
4. #3 is repeated until a match g is found.
5. Generator submits g to the client. The client uses g*c as a private key and g*c*G as the corresponding public key, which maps to the desired vanity address.
6. The generator, not knowing c or g*c, cannot claim coins from the generated address.

The procedure can be modified so that instead of using g*c as the private key and g*c*G as the public key, the private key will be g+c and the public key will be g*G+c*G. This is deemed less secure, but I believe is suitable for this application and may be less computationally expensive.

Sure, we'll do that. We'll decide on the exact time later.

A hotel seems overkill, I have an idea for what the venue for the next meetup will be, stay tuned.


Nothing too specific, we met at the cafe, did an introductions round (including overviews of Bitcoin projects each is working on) and carried on to small-group conversations. It was about 3 hours total. I recall talking about the future difficulty equilibrium challenge, interpretation of exchange rate trends, block chain mechanics, securing a wallet, split-key signatures, viability of BTC-denominated loans, eyal's open business concept, Bitcoin coverage in the media, alt coins, and many other things I don't recall at the moment.

I think ADgordo is saying he's originally from Israel but no longer lives here.

But you could plan a trip to Israel around the next meetup

January 2012 meetup was a success. 10 people attended. Lots of interesting discussions.

Sure, but isn't the plan to make it standalone at some point? If the "no validation" is only supposed to remain while it uses the Satoshi client then it's not a problem.

Do you mean that we'll have predictions such as "The Bitcoin rate will be above X at time Y"? Sounds like a tool completely unsuited for the task...

It means I can choose a label (say "My Bitcoin address"), hit the "generate 1000 addresses" button, and obtain a list of 1000 addresses I can use, labeled "My Bitcoin address 1" through "My Bitcoin address 1000", which I can easily copy in order to paste elsewhere. MultiBit does something like this as far as I understand.

This may fly for blocks buried deep enough in the chain. But for recent blocks you need to check they are actually valid before propagating them further. Otherwise you get into a situation that nobody does any checking because he trusts that everyone else will do the checking and only feed him clean data.

I disagree, there are certainly situations where 0-confirm transactions are to be trusted (notable example is paying for a latte).

Very cool.
Finally my 16GB will be of use .

What about bulk generation of addresses?

You should post a donation address here, I'm sure there are people willing to donate but not to use it at this point.

Unless, of course, you and the hacker are one. If people are to use this to store their life savings, you'd have quite an incentive to try to hack into your customer's computers.

That's basically it. The details were discussed here and there are two main approaches. One that is considered less secure (but IMO good enough for this application) is to have two private/public key pairs, each of them could be a valid Bitcoin pair in its own right, but they are not used as such - rather, a new private key can be obtained by combining the 2 private keys, and the corresponding public key can be found by combining the two public keys. The more secure version, which may be what casascius wants to do here, is to derive the private key from the 2 private keys, but to derive the corresponding public key from one private key and one public key.

As described in the OP each seed would be used for just one key. The idea can be extended to deriving multiple keys from one casascius seed.

Fermat is turning in his grave hearing your suggestion that the FLT is derived from some mod 9 calculations.