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 sound
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.
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 ch
>
> 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 definitio
On Tue, Jul 15, 2014 at 11:41 AM, Luke Dashjr 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
wallets/computers are o
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
p
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
> On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr 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 be race a
This is a well known problem of BIP 70 from day one, because BIP 70
functions at too-low a level.
What needs to be negotiated between parties is a _payment
relationship_ that exchanges HD wallet data. This is what is necessary
to establish and maintain an ongoing payment relationship.
BIP 70 is f
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 07/15
>
> 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 exp
>
> Payment protocol just doesn't well the use cases of,
> * an on-going payment stream from, e.g. Eligius to coinbase
> * deposit addresses and deposit situations
This seems to be the key point of disagreement here. Wladimir and I think
it satisfies your requirement just fine. You disagree. Let'
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 cann
On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr 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 be race attacks if this is implemented in an immediate fashon
> (attacker
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 appen
On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik 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 PaymentRequest until
Thankfully those two duplicated transactions were never spent when they first
appeared. Because of that, I chose to not not add them to the UTXO at all when
they first appear. When the duplicates appear they get added to the UTXO
successfully because the earlier, conflicting versions are not pre
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 wrote:
>> The request: It would be useful to limit the lifetime of a bitcoin
>> address.
>
>
> Not only useful but essential! Otherwise mobile clients can
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 wrote:
> I think generally control-characters (such as \u) should be
> disallowed in passphrases. (Even
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.
O
I don't know for sure if the test vector is correct NFC form. But for what
it's worth, the Pile of Poo character is pretty easily accessible on the
iPhone and Android keyboards, and in this string it's already in NFC form
(f09f92a9 in the test result). I've certainly seen it in usernames around
t
[+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 of
>
> 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. Addre
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
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik wrote:
> On Tue, Jul 15, 2014 at 4:19 AM, Wladimir 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 provides one, and one or more incomi
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir 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 several deployed us
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
On Tue, Jul 15, 2014 at 10:00 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.
Payment request expira
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 su
28 matches
Mail list logo
