(pics) Physical Bitcoin Bills - For Real World Transactions - Printcoins.com

[BurtW]

Mike is right.  I don't really care about a refund and would rather pay for and have the prototype bills for my collection and to support the project.  There is a lot of great ideas here and it looks like they are converging on a viable product.

I would buy the bills as currently described above for circulation (back to back holograms, laser etched, hole in paper for contact between the holograms, etc.) and I believe others would buy them also.

The last idea of using a vanity address for the denomination is very interesting maybe 1xx001... 1xx005... 1xx010.., 1xx020... 1xx050... 1xx100... where xx is some sort of production code (encoding production year/month or something like that)?

[1714776381]

1714776381

[1714776381]

1714776381

[1714776381]

1714776381

[1714776381]

1714776381

[PrintCoins]

Mike is right.  I don't really care about a refund and would rather pay for and have the prototype bills for my collection and to support the project.  There is a lot of great ideas here and it looks like they are converging on a viable product.

I would buy the bills as currently described above for circulation (back to back holograms, laser etched, hole in paper for contact between the holograms, etc.) and I believe others would buy them also.

The last idea of using a vanity address for the denomination is very interesting maybe 1xx001... 1xx005... 1xx010.., 1xx020... 1xx050... 1xx100... where xx is some sort of production code (encoding production year/month or something like that)?

I like the idea of the production cod in there. I am using version numbers that look like:
2011A

Where the letter increments and the year just matches the year the bill was printed.

[Red Emerald]

I liked the idea of bitbills, but their site hasn't changed in a while.  I like this approach a little more since these could fit in a wallet just like paper cash.

I still don't like the idea of the manufacturer having the ability to know the private key, but there isn't a way around that.

[DeathAndTaxes]

Mike is right.  I don't really care about a refund and would rather pay for and have the prototype bills for my collection and to support the project.  There is a lot of great ideas here and it looks like they are converging on a viable product.

I would buy the bills as currently described above for circulation (back to back holograms, laser etched, hole in paper for contact between the holograms, etc.) and I believe others would buy them also.

The last idea of using a vanity address for the denomination is very interesting maybe 1xx001... 1xx005... 1xx010.., 1xx020... 1xx050... 1xx100... where xx is some sort of production code (encoding production year/month or something like that)?

I like the idea of the production cod in there. I am using version numbers that look like:
2011A

Where the letter increments and the year just matches the year the bill was printed.

Well the longer the attempted vantity code the more hashes it takes on average to find one valid address.

Each digit you attempt to match increases the time to find a matching address by a factor of 16.

Thus 12011Axxx would be 4,096x more difficult to find than 1AAxxx (where x is the denomination).

[BurtW]

I was thinking use this year as the base year and then use one of the x spots to encode the next 58 years, use the second x spot to encode the production week 1-52 mapped onto the base 58 digit.

The entire public address is the "serial number"

[PrintCoins]

Updates:

* Due to the rise in the value of bitcoins, bills are now cheaper
* Denominated bills are back up for sale
* Paper stock is now significantly heavier - 32 lbs,  100% cotton
* Hologram size is now 12% larger
* Denominated bills are sold pre-funded. You don't fund them yourself.

[casascius]

Rob, we should do a deal where one of us manufactures the bill, sends it to the other, and we each add a private key.

Example: You and I both generate a large batch of keypairs.  We exchange public keys and compute the bitcoin address of the resulting set.  You make your bills and send them to me in completed sheets where I can feed them through an inkjet printer.  I print a 2nd key and QR on them (doesn't even have to be covered up).  I put a "zero BTC" hologram on it as my stamp of approval, and then I ship it out to whoever you tell me to.  (I already have the holograms - I had like 4000 of them made that say "zero BTC", not sure in advance what I'd do with them, but this might be perfect)

[PrintCoins]

Rob, we should do a deal where one of us manufactures the bill, sends it to the other, and we each add a private key.

Example: You and I both generate a large batch of keypairs.  We exchange public keys and compute the bitcoin address of the resulting set.  You make your bills and send them to me in completed sheets where I can feed them through an inkjet printer.  I print a 2nd key and QR on them (doesn't even have to be covered up).  I put a "zero BTC" hologram on it as my stamp of approval, and then I ship it out to whoever you tell me to.  (I already have the holograms - I had like 4000 of them made that say "zero BTC", not sure in advance what I'd do with them, but this might be perfect)

That would work.

Code:

Bill Example
--------------------------------
5 Bitcoins                5

Priv1          Pub1
                     Pub Combined 
Priv2          Pub2

5                              5BTC
---------------------------------

I can accompany the sheets with a text file of public addresses so you don't need to get them directly from the sheets.

Do you have code (in any language) on github somewhere for merging the private keys? If I can also have some example outputs that I can test against, I can see if I can port it over to javascript and make a simple web app for users.

[BurtW]

Example: You and I both generate a large batch of keypairs.  We exchange public keys and compute the bitcoin address of the resulting set.  You make your bills and send them to me in completed sheets where I can feed them through an inkjet printer.  I print a 2nd key and QR on them (doesn't even have to be covered up).  I put a "zero BTC" hologram on it as my stamp of approval, and then I ship it out to whoever you tell me to.  (I already have the holograms - I had like 4000 of them made that say "zero BTC", not sure in advance what I'd do with them, but this might be perfect)

Mike,  There are a few details missing here.

First question:  are you proposing that you guys use the point addition method or the serial point generation method that we recently discussed in the other thread?

I was assuming everyone was moving to using the serial point generation system (private key multiplication)

I think in order to make it as simple as possible for the customer you should end up with the bill having just three numbers/QR codes:

The final public key address
The first private key (under a sticker)
The second private key (under a sticker)

I think it might be ok to leave off the second sticker but the first one is critical and adding the second sticker to cover the second private key would avoid confusion and cover up another number/QR code so the customer only sees the one public key address/QR they need in order to fund the check or check the value of the preloaded bill.

[casascius]

Yes, we'd use point multiplication.

Each of us has a private key, so we should have no problem computing the addresses if we trade public keys.

If we both trade public keys, then Rob can pre-print the complete bitcoin address, and I can also print it a second time in small print for confirmation that the two still correspond.  My hologram isn't big enough to cover the whole QR code without actually sticking to it, so I'd print my QR code in the open, and stick my (windowed) hologram beside it, such that the firstbits of the combined address (as I printed it) show through the window.

Probably what I should do is make a derivative program of Casascius Bitcoin Address Utility that does both sides of the work, and then open source it.  Function one would generate a privkey/pubkey file (csv), function two would take the local privkey file and a foreign pubkey file and generate a bitcoin address list, which we would both independently sign and publish.

[Daily Anarchist]

I think you're making great progress on this and I am eagerly awaiting the day that I can feel confident in purchasing your Bitbills. There are several more things that need to happen for them to be a truly kick-ass Bitcoin-backed paper currency.

Right now your prices are prohibitive.

I see that you are charging less premium(percentage wise) on a 50 BTC note than a 1 BTC note. But that doesn't really make sense. I'm assuming that the cost of making the 50 BTC note is ~ the same as making a 1 BTC note. Therefore, when an individual purchases a single solitary note, whether it be a 50 or a 1, the premium(in nominal terms, not percentage of note value) should be the same.

The savings should come in when an individual purchases large quantities of the same note. This would be bulk pricing. And since people are much more likely to buy 1's in bulk than they are 50's in bulk, we can reasonably expect people to get better discounts on their 1's than on their 50's, which I think is the goal you were trying to achieve when pricing the notes in the first place.

[Red Emerald]

Probably what I should do is make a derivative program of Casascius Bitcoin Address Utility that does both sides of the work, and then open source it.  Function one would generate a privkey/pubkey file (csv), function two would take the local privkey file and a foreign pubkey file and generate a bitcoin address list, which we would both independently sign and publish.

This sounds awesome.  There should also be a utility for taking the two private keys and combining them into a wallet import format of some kind so people can easily use these bills.

[casascius]

This sounds awesome.  There should also be a utility for taking the two private keys and combining them into a wallet import format of some kind so people can easily use these bills.

I intend to promote using private keys with the prefix "6" instead of "5" to mean keys that require other keys to be combined.  To get the "6", I intend to use 0xA2 instead of 0x80 as the version byte.  That way, a UI allowing redemption will know that this is only half of a private key, so it will know to ask for the other half.

As it turns out, 0xA2 thru 0xA9 also produce prefixes of "6", so for example 0xA3 could be used to signal a key in three parts, if somebody finds a use case for it.

[Daily Anarchist]

With the increase purchasing power of Bitcoin seemingly inevitable, could we see the day where Printcoins has bills ranging as low as 1 BTC to as high as 100 BTC much like FRN's and Cas has coins ranging from 0.01 BTC to 0.50 BTC much like today's FRN coins? That would be badass.

[BurtW]

Is this the proposal?  Should work.

Person 1:
  Create a random private key (a)
  From the random private key calculate the standard public key (A = a*G)
  Send the public key (A) to person 2

Person 2:
  Create a random private key (b)
  From the random private key calculate the standard public key (B = b*G)
  Send the public key (B) to person 1

Person 1:
  From the random private key (a) and the public key created by person 2 (B) calculate the final public key (F = a*B)
    [Note a*B = a*b*G which makes the final private key a*b]
  Calculate the final public key address of the final public key (F)

Person 2:  
  From the random private key (b) and the public key created by person 1 (A) calculate the final public key (F = b*A)
    [Note b*A = b*a*G which makes the final private key b*a]
  Print the private key (b) on the bill - and cover it with a sticker to hide it
  Calculate the public key address of public key F and print it on the bill
  Send the bill to person 1

Person 1
  Finally print the private key (a) on the bill
  Can match the public key address calcluated above with the public key address on the bill

[PrintCoins]

I think you're making great progress on this and I am eagerly awaiting the day that I can feel confident in purchasing your Bitbills. There are several more things that need to happen for them to be a truly kick-ass Bitcoin-backed paper currency.

Right now your prices are prohibitive.

I see that you are charging less premium(percentage wise) on a 50 BTC note than a 1 BTC note. But that doesn't really make sense. I'm assuming that the cost of making the 50 BTC note is ~ the same as making a 1 BTC note. Therefore, when an individual purchases a single solitary note, whether it be a 50 or a 1, the premium(in nominal terms, not percentage of note value) should be the same.

The savings should come in when an individual purchases large quantities of the same note. This would be bulk pricing. And since people are much more likely to buy 1's in bulk than they are 50's in bulk, we can reasonably expect people to get better discounts on their 1's than on their 50's, which I think is the goal you were trying to achieve when pricing the notes in the first place.

You are right on. I adjusted my formula based upon your post, and the price of the higher denomination bills includes a much smaller markup than before.

[Daily Anarchist]

I think you're making great progress on this and I am eagerly awaiting the day that I can feel confident in purchasing your Bitbills. There are several more things that need to happen for them to be a truly kick-ass Bitcoin-backed paper currency.

Right now your prices are prohibitive.

I see that you are charging less premium(percentage wise) on a 50 BTC note than a 1 BTC note. But that doesn't really make sense. I'm assuming that the cost of making the 50 BTC note is ~ the same as making a 1 BTC note. Therefore, when an individual purchases a single solitary note, whether it be a 50 or a 1, the premium(in nominal terms, not percentage of note value) should be the same.

The savings should come in when an individual purchases large quantities of the same note. This would be bulk pricing. And since people are much more likely to buy 1's in bulk than they are 50's in bulk, we can reasonably expect people to get better discounts on their 1's than on their 50's, which I think is the goal you were trying to achieve when pricing the notes in the first place.

You are right on. I adjusted my formula based upon your post, and the price of the higher denomination bills includes a much smaller markup than before.

Glad to help. Keep up the good work!

[PrintCoins]

Mike, do not answer this yet.  Let me edit it with the "crossing system" you proposed...

Person 1:
  Create a random private key (a)
  From the random private key calculate the standard public key (A = a*G)
  Print the private key (a) on the bill and cover it with a sticker
  Send the bill, along with the corresponding public key (A), to person 2

Person 2:  
  Create a second private key (b)
  From the random private key (b) and the public key created by person 1 (A) calculate the final public key (B = b*A)
    [Note b*A = b*a*G which makes the final private key b*a]
  Print the private key (b) on the bill - As you said this could be left in the clear if you want to
  Calculate the public key address of public key B and print it on the bill
  Fund the public key address with the correct number of BTC

I hate to gum up the works, but there is one flaw. If I ever can see the full printed bill in circulation, and I was an evil person who actually was saving private keys, since the second one is in the clear, I would have both, and thus would be back in the beginning again (except with a new layer of trust in the bills).

How I could be evil, is buy these under a false name, have Mike ship them, and then somehow pass them off again to someone else to resell them or spend them.

Yep, it is far fetched, but I predict that in the next two years their will be a boatload of people printing all sorts of bitcoin bills, and this little run-around might become feasible.

Since Mike and I are the only game in town at the moment, and it would be absurd to go through all these steps where I could achieve the same ends without any steps, it should be just fine to use the clear second half of the private key. I would just recommend that when this becomes a common practice, both private keys need to be obscured.

[casascius]

I hate to gum up the works, but there is one flaw. If I ever can see the full printed bill in circulation, and I was an evil person who actually was saving private keys, since the second one is in the clear, I would have both, and thus would be back in the beginning again (except with a new layer of trust in the bills).

How I could be evil, is buy these under a false name, have Mike ship them, and then somehow pass them off again to someone else to resell them or spend them.

Yep, it is far fetched, but I predict that in the next two years their will be a boatload of people printing all sorts of bitcoin bills, and this little run-around might become feasible.

Since Mike and I are the only game in town at the moment, and it would be absurd to go through all these steps where I could achieve the same ends without any steps, it should be just fine to use the clear second half of the private key. I would just recommend that when this becomes a common practice, both private keys need to be obscured.

That's possible yeah, but when I get some holograms that are cut as rectangles, then I can deal with that.  For now people are going to have to just trust you're not doing that, the same way they probably already trust we're not doing it now.  That's why I'm looking to get them to quote us on a continuous hologram pattern that works as both circles and big rectangles, so we can get both kinds out of the same hologram order.  My one inch circles are really only good for obscuring a small dot with tiny print like I do on my coins, just no way I could see it covering a full QR code.

[PrintCoins]

I hate to gum up the works, but there is one flaw. If I ever can see the full printed bill in circulation, and I was an evil person who actually was saving private keys, since the second one is in the clear, I would have both, and thus would be back in the beginning again (except with a new layer of trust in the bills).

How I could be evil, is buy these under a false name, have Mike ship them, and then somehow pass them off again to someone else to resell them or spend them.

Yep, it is far fetched, but I predict that in the next two years their will be a boatload of people printing all sorts of bitcoin bills, and this little run-around might become feasible.

Since Mike and I are the only game in town at the moment, and it would be absurd to go through all these steps where I could achieve the same ends without any steps, it should be just fine to use the clear second half of the private key. I would just recommend that when this becomes a common practice, both private keys need to be obscured.

That's possible yeah, but when I get some holograms that are cut as rectangles, then I can deal with that.  For now people are going to have to just trust you're not doing that, the same way they probably already trust we're not doing it now.  That's why I'm looking to get them to quote us on a continuous hologram pattern that works as both circles and big rectangles, so we can get both kinds out of the same hologram order.  My one inch circles are really only good for obscuring a small dot with tiny print like I do on my coins, just no way I could see it covering a full QR code.

Yeah, right now there is a lot based on trust, and I think that even with an un-obscured second key, it works extremely well, since it would take a massive effort on my part to undermine this system.

Since this is paving the way for the future currency producers, I just wanted to show how it isn't 100% of a perfect system. Even as a two part obscured private key, it isn't 100%, as collusion is possible.

Each person added to the scheme increases the trust factor by an exponent as the greater the number of people, the more difficult a conspiracy is (ignoring the possibility of sock-puppets).

The downside: this will cost more in labor, shipping and materials.