Conservatism/neutrality is good when designing money as that invokes feelings of trust and stability.

Hence as latin is old, it should be the "Vires in Numeris".

"Load"/"spend" sounds like coupon words so don't use them.

Yellow bill by spy is not as good as the others he did, it looks jumbled + the folding/crease issue. Yellow color itself is good though.
Green and blue are likely the colors people associate with tranquility and reason the most though.

For disposable bills i think a low ink version of spys or an even a different simple version with same style is needed.


I also think it should be "Public key" instead of "address"... symmetry would require the first + it sounds more fancy.


All just my opinion of course, feel free to ignore it.

Also great.

Just tell the crazies that the number shown is in fact already encrypted *wink* and hence incorporated into the design.

It's likely controlled by a bot that will remove it instantly if too many coins are sold.

It is my understanding that most of the walls are like that.

Someone MIGHT dump 40K in a sec, but I doubt that highly as that would cost a lot and crash the market while you are trying to sell your coins.


Hence why they are disappearing/moving all the time and why I and many others do not rely on them for analysis.

That's a programming issue for the guy doing the printing program based on these designs. Why bother the designers here.

By far my favorite.

Not only does it look great b/w and probably better in color (if there's a color version), but it also looks like it will use a smaller amount of ink.

Those are the two primary focuses of BTC cash.

Some notes:
1. Could you un-slant all the BTCs.
2. Try to make it use even less ink? (white bodys of fat lines, whiter shade of gray)

My sentiment since 6.5 ...

Either someone with deep pockets found bitcoin or it's a bubble that may well go even higher before crashing.

It would take really only one rich guy in the world to double BTC value.

Lol walls like that are super fake. It would be taken down if you actually sold into it for a while.

Great stuff.

I have already talked to a pirate party guy about this stuff, its pretty nifty.

The org protocol idea is a way to make sure say the pirate party top keeps doing votes in the fashion agreed on for hundreds of years.

However I'm not programming it right now and probably not alone whenever.

Luv it!

The last one really looks like real money.

Further I think since you are printing this with a computer the number version should be used, not the empty field one. You would use a dedicated program to print a bunch of different denominations with the amounts pre-printed.


Could you make a version that's black and white and more simple to use less ink?

Gah almost all the cards I read about say that "the entire memory can always be read". How can I hide keys then?

Maybe I'm misunderstanding something.

EDIT:
Progress report:
SLE44-55 cards seem to be mag stripe cards in chip form. Security if any as I understand it is that the card and terminal establishes a secure channel.

If ONE terminal is compromised fake terminals could bring down any such system.

ACO3-5 cards seem to be what we are looking for with their own micro processor and signing capabilities. Will research more. 3-4$ lowest price I have seen so far:
http://www.smartcardzone.com/acos3.asp

What would your fees be compared to OKPay?

Before I read through your entire thread, what smartcard are you using and why?


Progress report:
I have learned the card should be programmed with the C language. Having used it before its not all that bad for simple things.

The reason for this is that the cards for C cost half as much. Sure a dollar or so is not much, but if you want to equip a village with cards 100% that's suddenly twice the village size you could go for.

Also pre-printed cards seem common. I was worried all the first gen cards would be ugly and white, but hopefully they can now be Casasicius-level pretty.

Or pictures of the LHC, Cern, ISS, Apollo rockets, internet, fire, electricity, light, bridges and other similar great advancements in science/engineering.

Bank notes seem to come with faces, so perhaps use guy fawkes as Nakamoto.

Could you make it less orange and more yellow/lighter color?

Anyway its great I may well use it.

But doesn't OKPay and similar already exist?

Anyway I'm sure we can cooperate on a bunch of things and that your work is great.

I read it now.

I will try to use what I can from their work and also share my work with them of course, however:

I am driven by the desire to see the existing banking sector BURN - I can't do that if I develop cards for them.

On a more rational node, EMV - after re-reading about it briefly - seems ludicrously unsafe and I think BTC can do better and stand on its own.


As for exactly what I will develop, I will describe the payment process below:
0. Card has 5-20 addresses so that even a shopaholic can use addresses with 6-block-verified balances.
1. ONE btc address sent to terminal.
2. If there's a balance on it the terminal requests amount/sends its receive address.
3. Amount multiplied "P" (0-9 nine number that cycles 1 each payment) sent to and displayed in terminal.
4. If the number fits, the user types their PIN (and for high security cards also P).
5A. Card locks itself for 10 seconds* and if everything was correct signs a TX and sends it back.
5B. Card locks itself for 1 minute in case of an incorrect code.

This security model can be further combined with a SMS service that monitors your addresses and warns you if there is too much going on immediately.

With this it would be quite impossible to fraud people without actually robbing them after learning the PIN. Since the merchant does not now P you could also shop just fine at a thief's supermarket every day (even low security cards would be quite safe with a warning SMS service).

All addresses and keys would be known by the owner of the card so that he may recharge it or empty/"block" it.

The card would self-fund by sending half of the just used address to the address just before itself in the cycle. The terminal may request more addresses if one is not enough for a big payment.


*Time here measured as "time while powered by a terminal".

EDIT: Also, I just realized, the connector cable + android would be cheaper for merchants to buy than existing VISA/Mastercard terminals and would not rely on being signed/blackbox security.

Hi guys, I'm DONE at my university so anyone want to design this baby with me?

I am aware of the ellet and its cool, but this is supposed to be cheaper, easier and more open to everyone. More solutions can't hurt.

Project:
1. We design it as described in this thread on standard cheap cards.
2. All is open source.
3. We develop and share together.
4. We create an API for BTC smartcards that all the BTC community can agree on.
5. We try to get the android wallet guys to incorporate card functionality via extension cable OR make our own simple simple receiver.

Profit:
1. We program the cards to send 1/10.000 of amounts to miners and ALSO a similar or LARGER amount to ourselves.
2. Everyone can release cards, it will just push adoption rates... and thus everyone's fame and fortune + BTC/world peace/death to banks agenda.
3. I and others can release free cards that have higher fees on them, though still around 1/1000 max. (with regular use will pay for itself within a year TOPS). Such could be distributed in dense communities or to people doing remittance regularly so as to reach "local 100% penetration".

We need:
1. Programmers!
2. "Cheerleaders"!
3. Business minded folk.
4. Everyone.

All support welcome.

I will start researching etc. in the coming days and post about progress (this is where cheers are crucial). You can join at any time.
I estimate the project will take 1 week to 6 months and after that I expect to get loaded rich with fees that keep coming forever after initial distribution.

Thread jacking: Why are paypal trying to kill themselves with dropping so many sites?

They must be aware of BTC, yet they push users towards it.

"Mined from other users" ... I suppose you COULD try to bruteforce keys instead of hashes...


Seriously don't be a journalist if you can't grasp a wiki article for your "research".