Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
You could append don't [permit|confirm] after X [time|block] to
the address I
On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik jgar...@bitpay.com wrote:
Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
Payment
On Tue, Jul 15, 2014 at 04:00:41AM -0400, Jeff Garzik wrote:
Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
You could append
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@gmail.com wrote:
In my opinion encouraging the use of the payment protocol and
deprecating the use of addresses is the best way forward, and not just
for this reason.
There are major gaps that the payment protocol doesn't cover.
There are
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@gmail.com wrote:
There are major gaps that the payment protocol doesn't cover.
There are several deployed use cases where you are provided/request an
address, an API
Payment Protocol would probably be the communication format for any new
meta-data.
What's the likelihood of something like this every making it on the
blockchain?
--
Want fast and easy access to all the code in your
The request: It would be useful to limit the lifetime of a bitcoin
address.
Not only useful but essential! Otherwise mobile clients can run out of RAM
and have to cycle around and reuse addresses.
Which is indeed why BIP70 has this feature. It was thought about quite some
time ago.
[+cc aaron]
We recently added an implementation of BIP 38 (password protected private
keys) to bitcoinj. It came to my attention that the third test vector may
be broken. It gives a hex version of what the NFC normalised version of the
input string should be, but this does not match the results
I think generally control-characters (such as \u) should be
disallowed in passphrases. (Even the use of whitespaces is very
questionable.)
I'm ok with allowing pile-of-poo's. On mobile phones there is keyboards
just containing emoticons -- why not allow those? Assuming NFC works of
course.
I have a python implementation that seems to pass this test vector:
https://github.com/wozz/electrum/blob/bip38_import/lib/bip38.py#L299
On Jul 15, 2014, at 9:19 AM, Andreas Schildbach andr...@schildbach.de wrote:
I think generally control-characters (such as \u) should be
disallowed in
BIP70 does not work well for unknown number of future payments of
unknown, unpredictable value.
On Tue, Jul 15, 2014 at 6:25 AM, Mike Hearn m...@plan99.net wrote:
The request: It would be useful to limit the lifetime of a bitcoin
address.
Not only useful but essential! Otherwise mobile
On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
BIP70 does not work well for unknown number of future payments of
unknown, unpredictable value.
You can specify zero as an output value, in which case it's the same as no
value specified. You can then just reuse the
On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
You could append
Unicode guarantees that null-terminated strings still work. U+
terminates a unicode (or C) string. strlen() gets the string byte
count. mbstowcs() gets the character count.
Whitespace can be problematic, but should be allowed. Control
characters should be filtered. Emoticons probably
Unicode guarantees that null-terminated strings still work.
UTF-8 guarantees that. Other encodings do not, you can have null bytes in
UTF-16 strings for example. Indeed most languages that use pascal-style
encodings internally allow null characters in strings, it's just not a good
idea to
Can you provide the rationale for standard practice? For example, why
should whitespace be allowed? I regularly use trim() on any passphrase
(or other input ftm).
So what's the action point? Should we amend the spec to filter control
characters? That would get rid of the \u problem.
On
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr l...@dashjr.org wrote:
They can already do this. It's perfectly valid for wallets/services to
ignore (and not consider as payment) transactions using an address more
than once. There might
On whitespace: Security UX testing I've seen shows it is mentally
easier for some users to memorize and use longer passphrases, if they
are permitted spaces. I've not seen anything written on use of
tabs/NLs/FFs in passphrases.
I can see the logic of some systems, that convert \s+ into ' ' for
On Tue, Jul 15, 2014 at 11:41 AM, Luke Dashjr l...@dashjr.org wrote:
There's no reason deposits cannot use a unique payment request or address
every time...
Actually, and this is key, there _are_ reasons why deposits might not
be able to use PaymentRequests. Payments happen even when
Actually, and this is key, there _are_ reasons why deposits might not
be able to use PaymentRequests. Payments happen even when
wallets/computers are offline.
I don't understand this point. It's the *sender* that is parsing the
PaymentRequest and following the instructions. By definition
I was part of adding in that test vector, and I think it's a good test
vector since it is an extreme edge-case of the current definition: If the
BIP38 proposal allows any password that can be in UTF-8, NFC normalized
form, those characters cover the various edge cases (combining characters,
null
Yes, we know, Andreas' code is indeed doing normalisation.
However it appears the output bytes end up being different. What I get back
is:
cf9300*01*303430300166346139
vs
cf9300*f0*909080f09f92a9
from the spec.
I'm not sure why. It appears this is due to the character from the astral
planes.
If the user creates a password on an iOS device with an astral
character and then can't enter that password on a JVM wallet, that
sucks. If JVMs really can't support unicode NFC then that's a strong
case to limit the spec to the subset of unicode that all popular
platforms can support, but it
23 matches
Mail list logo
