-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:20:40 CEST, Justus Ranvier 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 despite what you say it's
-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. Nobo
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
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 18/05/
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 :
> >> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach :
> >> One problem we couldn't figure out here
>> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach :
>> 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 fraudul
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 someo
> 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
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 the
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, whe
Thanks for all the feedback, and for everyone who read through the docs.
My BIP numbering was a blunder, and I have revised the numbering to be PCP-0
(Paper Currency Proposal Number 0) through PCP-4. I think I was brain-dead on
that, sorry, and I am now on PCP.
Please allow me to walk you
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 notes
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 fi
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 prov
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 Schildbach
> 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 ran
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
On Sat, May 17, 2014 at 9:07 AM, Chris Pacia 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 spent. This is especi
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 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 Automat
It seems to me that there's a huge need for a paper currency that is
counterfeit-resistant, inexpensive to print, internationally recognized
(border-less), fits in a wallet, and machine readable.
I pitched this idea at the Cincinnati Bitcoin meetup last week, and I didn't
get thrown out, so I t
21 matches
Mail list logo