Search content
Sort by
Showing 20 of 30 results by CAFxX
Re: POLL: What name would you give to the smallest unit of bitcoin (0.00000001)?
How about 10 nanocoins?
I can't believe I had to get to page 3 of this thread before someone suggested this... finally, thank you, we have a winner.
Wow, missed that one. Have to say that's got my vote as well.
Re: POLL: What name would you give to the smallest unit of bitcoin (0.00000001)?
In SI units, 1E-8 BTC would be 10 nBTC (read: nano-BTC). So I guess any of "10 nBTC", "10 nanoBTC", "10 nanocoins" or "10 nanos". XD
p.s. The 1E-8 atomic unit isn't fixed in stone. It could very well change tomorrow: as such it's pointless searching for a name...
p.s. The 1E-8 atomic unit isn't fixed in stone. It could very well change tomorrow: as such it's pointless searching for a name...
Just a quick note... the project above wouldn't be really secure as is, because a secure design would at least require a display and confirmation button (to be secure against arbitrary software running on the host and - to a limited extent - against theft of the key).
Also consider that there are faster drop-in replacement like the atmega328 (cost < $3)
The atmega328 isn't actually faster, it just has more memory. Also, it might be worth looking at one of the cheaper low-end ARM microcontrollers with integrated USB; they have a lot more processing power and aren't much more expensive.
Quote
Also, one very important warning: do not screw up and use a weak random number source. Your users will never forgive you.
IIUC the project I linked above is using a capacitor connected to one of the ADC as a source of randomness. It might not be as good as one of those TRNGs, but with some decent entropy estimation, followed by equalization and whitening it should make a decent entropy source.Anyway, would you join the IRC channel and lend us a hand from time to time?
BTW, which IRC channel is it?The person with the private key is the same organizing the lottery. He could very well disappear before the extraction or simply refuse to pay the winners.
I know, I'm strictly talking cheating with the random part. In that case it would be WAY easier to just take the money than cheat with the randomness but it is possible. Perhaps someone stole the key or someone with money wanted to help his chances. I don't know. But it does have a SMALL flaw. * anybody else wouldn't be able to mount such an attack without the private key (or without breaking the asymmetric encryption scheme)
Random.org does not use pure computer randomization functions:
RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs. People use RANDOM.ORG for holding drawings, lotteries and sweepstakes, to drive games and gambling sites, for scientific applications and for art and music.
I agree its random but people still have a hard time understanding and trusting it. I can't think of a single million dollar lottery that uses computers. Only balls. People can see it and everyone understands it. Does random.org allow for getting data at a very specific time. If not there is no way to verify what the person got is right or not. RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs. People use RANDOM.ORG for holding drawings, lotteries and sweepstakes, to drive games and gambling sites, for scientific applications and for art and music.
Since we're talking bitcoin, then the most sensible way would be
- Take the N last confirmed blocks at time of extraction
- Hash them
- Sign hash with private key
- Treat the signed hash as a huge random integer - extract from it the random number(s) needed for your lottery.
- Anyone can verify that you haven't made it up by verifying the signed hash (using your public key) against the hash of the well-known last N confirmed blocks at time of extraction
- Profit!
The person with the private key could be cheating by generating the last block needed and not submitting if it doesn't work in their favor. They can slightly increase their odds. - Take the N last confirmed blocks at time of extraction
- Hash them
- Sign hash with private key
- Treat the signed hash as a huge random integer - extract from it the random number(s) needed for your lottery.
- Anyone can verify that you haven't made it up by verifying the signed hash (using your public key) against the hash of the well-known last N confirmed blocks at time of extraction
- Profit!
I know I've tried something very similar. Still not cheat proof.
Since we're talking bitcoin, then the most sensible way would be
- Take the N last confirmed blocks at time of extraction
- Hash them
- Sign hash with private key
- Treat the signed hash as a huge random integer - extract from it the random number(s) needed for your lottery.
- Anyone can verify that you haven't made it up by verifying the signed hash (using your public key) against the hash of the well-known last N confirmed blocks at time of extraction
- Profit!
- Take the N last confirmed blocks at time of extraction
- Hash them
- Sign hash with private key
- Treat the signed hash as a huge random integer - extract from it the random number(s) needed for your lottery.
- Anyone can verify that you haven't made it up by verifying the signed hash (using your public key) against the hash of the well-known last N confirmed blocks at time of extraction
- Profit!
Lotteries need true random numbers. Would you like to see a graphic representation of PHP's rand() function on a Windows machine? It's pretty. It's pretty because there's a diagnol pattern across the whole thing.
That's what mt_rand() is for.The only reason one might need true random numbers is for generating cryptographic keys. Asking such numbers to an external entity would render pointless the whole cryptography attempt (not to mention, exceptionally slow).
What's wrong with /dev/random in your opinion?
What's wrong with /dev/random in your opinion?
@CAFxX, that's interesting, but are Bitcoin signatures ECDSA? I heard they're some specific elliptic algorithm + two SHA-256.
Yes they are ECDSA: https://en.bitcoin.it/wiki/Protocol_specification#SignaturesIIRC SHA-256 is even less computationally-intensive than ECDSA. I wouldn't be surprised if creating/signing a transaction would require less than 3s.
Quote
Atmega328 is also 8-bits, right? I'm still shocked that's enough for crypto math, but it seems it's true.
yes, they're identical apart from different amount of flash memory (32kb vs 8kb) and max clock speed.Quote
Anyway, would you join the IRC channel and lend us a hand from time to time?
I'll be done with my master's thesis in a couple of weeks. Afterwards I'll gladly try to help.So the USB Wallets should be easily expansible to support changes in the Bitcoin cryptosystem. FPGA's, I think, are generally better suited for that than a microprocessor like Arduino/Atmel's AVR (wish I'm not sure can even handle signing a transaction in, like, less than a minute), or even some powerful ARM processor.
I think an FPGA is something really worth having in a USB Wallet, but that's something we can all discuss, try out, etc.
I think an FPGA is something really worth having in a USB Wallet, but that's something we can all discuss, try out, etc.
The link I posted above says that the atmega8 (an 8-bit low-end microcontroller) can do
Quote
On-token private key operations (ECDSA Sign) with acceptable speed (~2seconds/sign for prime192v1 NIST curve)
Also consider that there are faster drop-in replacement like the atmega328 (cost < $3)I care because I have to live in the same house with the bully. You should care because he is also known to leave his own house and beat the kids on the next block whenever he starts feeling insecure about himself. And he carries a damn big stick.
All right, I concede that maybe "to care" wasn't the right verb to use. In the proper sense I do care because I strive to do all that's legitimate for a non-US national to do to change this (IMHO) for the better (with the obvious boundary of preserving US nationals' freedoms).
Beside that, I don't care.
if you care about freedom and liberty.
Yes I do. The thing "the US" doesn't get IMHO is that a person's freedom ends where another's begins. It's too easy building your citizens' freedom at the expense of other peoples'.Mind you: I'd be equally critic if this were to be the position of the EU or whatever else. It's just that these kind of things generally come always from the US (ACTA, SWIFT, etc.) - so I get started up pretty easily when somebody links "freedom" and "US".
And BTW, I disagree with the primadonna view of the US: no, you're not strictly needed. Simlarly, the EU is not strictly needed, Japan is not strictly needed, China isn't either and so is India. Nobody's strictly needed.
Don't reinvent the wheel: http://code.google.com/p/opencryptotoken/
Don't get me wrong, I'm very excited about bitcoin, but I think the Feds are not going to be happy.
With all due respect, but... who gives a damn about the US?