Practically I would approach it from a different angle. We need to make
sure that notes we're accepting are still loaded, but assuming it's NFC
enabled this is still quite easy for the user and is an acceptable
usability drawback.
Then what we need to make sure is that when someone is redeeming
Submitted with humility and some fear of getting laughed out of here...
Off topic aside, a bunch of us have lately started to think about the
atmosphere on this list and how to improve it. Nobody should have to fear
getting flamed or laughed at for proposing ideas, even if they turn out to
be
Alex,
I think that what you are talking about more or less something like
the Firmcoin
Check: http://firmcoin.com/?p=92
On 18/05/2014 08:47 a.m., Alex Kotenko wrote:
One problem we couldn't figure out here though - how to protect the
notes from unauthorized redeem. Like if someone
2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
One problem we couldn't figure out here though - how to protect the
notes from unauthorized redeem. Like if someone else tries to reach your
wallet with his own NFC - how can we distinguish between deliberate
redeem by owner
Asking random ignorant stranger to care to protect themselves never works.
We need solution that requires strictly zero effort.
Best regards,
Alex Kotenko
2014-05-19 14:06 GMT+01:00 Brooks Boyd bo...@midnightdesign.ws:
2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
Alex,
I think the problem of making paper bitcoins is equivalent to the idea of
creating paper implementation of bitcoin sidechain. Hard one in my mind. If
we could resolve this one in secure and decentralized way it would be the
same breakthrough as bitcoin itself is.
Martin Sip
On
Hmm, this is firmcoin thing looks like what I mean. They don't have a
solution yet, and prices they quote smartcards are unacceptable, but if
they will manage to get down in selfcost - that may work. Ok, I'll follow
them and see what it will come to.
Best regards,
Alex Kotenko
2014-05-19 13:55
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 02:21 PM, Mike Hearn wrote:
Submitted with humility and some fear of getting laughed out of
here...
Off topic aside, a bunch of us have lately started to think about
the atmosphere on this list and how to improve it. Nobody
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:20:40 CEST, Justus Ranvier justusranv...@gmail.com wrote:
You and Gavin could do a lot better by working on a Bitcoin social
contract - a promise of what features will *never* be added (or taken
away) from Bitcoin, because
I had a long discussion recently with somebody who wants and has resources
to do exactly this - paper currency representing bitcoins. Yet we've been
thinking mostly about a centralized solution, where one party is producing
and maintaining paper currency, with bitcoins tied to each note verifiable
One problem we couldn't figure out here though - how to protect the
notes from unauthorized redeem. Like if someone else tries to reach your
wallet with his own NFC - how can we distinguish between deliberate
redeem by owner and fraudulent redeem by anybody else with custom built
long range
Yes, but it must not sacrifice usability. It's paper money, people are used
to it and they have rather high standard of expectations in this area. Any
usbility sacrifices in this area result into failure of the whole thing.
Best regards,
Alex Kotenko
2014-05-18 13:14 GMT+01:00 Andreas
Now you are talking about Trusted Platform Modules. Like smartcards,
actually. Devices that won't leak their keys but let the holder spend the
coins. It could even have it's own simple SPV wallet client to make it
easier to handle. And they'd use the attestation features provided by the
TPM to
Jerry, some feedback on generating space-efficient QR codes. QR codes
have 4 possible encodings, see Storage:
http://en.wikipedia.org/wiki/QR_code
The encoding you're proposing in BIP81 switches you to binary mode
without actually using all the bits. So you'll end up with bloaty QR
codes. One fix
Erm, few things here.
- I can't see really how to embed electronics capable to run an SPV
client into printed paper. I know that passive NFC tags can be printed on
paper, but not actual chips and/or power modules. So we are talking about a
completely different things here.
- even with paper
The problem with not involving any electronics is that somebody needs to
generate a recoverable private key that we have to trust haven't recovered
the private key.
The only plausible solution is multisignature P2SH addresses where you
trust several independent entities to not collude instead,
On Saturday, 17 May 2014, at 11:31 am, Jerry Felix wrote:
I picked some BIP numbers myself that seem to be available.
I'm quite certain you're explicitly *NOT* supposed to do this.
--
Accelerate Dev Cycles with
Since these notes have to be redeemed immediately the number of use
cases seems limited. I can't really just hand someone the note and walk
away because they have to scan it to see if it is actually valid.
Otherwise someone could just pass fake notes if they felt the recipient
wouldn't redeem them
On Sat, May 17, 2014 at 9:07 AM, Chris Pacia ctpa...@gmail.com wrote:
I can't really just hand someone the note and walk away
because they have to scan it to see if it is actually valid.
Not just scan it, but they actually must successfully sweep it—
otherwise they can be trivially double
19 matches
Mail list logo
