In a system like bitcoin, where the system has to keep running, you
have to consider how to roll out upgrades, and the costs associated
with that.
* the general cost of any network-wide change, versus P2SH which is
already analyzed by devs, rolled out and working
* the cost of P2SH output is predic
Additional costs would be in terms of A) chance of user error/application
error -- proposed method is much simpler, as well as extra bytes for
control flow ( 4 per script if I am counting right).
The costs on a normal script do seem slightly more friendly, except this
method allows for hidden-til
On Wed, Jul 16, 2014 at 1:56 PM, Jeremy wrote:
> Right now, this could be expressed multiple ways (ie, using an op_dup if
> then else chain) , but all would incur additional costs in terms of
> complicated control flows. Instead, I would propose:
Can you quantify "additional costs in terms of com
Ok, I just fixed the String filtering so that it can handle SMP chars
and my implementation behaves exactly like in your modified testcase
quoted below.
Bitcoinj code available on this branch, in case we decide to change the
spec:
https://github.com/schildbach/bitcoinj/commits/bip38-normalize-con
Please excuse me. I had a more thorough look at the original problem and
found that the only problem with the original test case was that you
cannot specify codepoints from the SMP using \u in Java. I always tried
\u010400 but that doesn't work.
Here is a fix for bitcoinj. The test now passes.
ht
If I first remove \u, so the non-normalized passphrase is
"\u03D2\u0301\U00010400\U0001F4A9", and then NFC normalize it, it
becomes "\u03D3\U00010400\U0001F4A9"
UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what
you got, Andreas!)
Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvN
Hey all,
I had an idea for a new transaction type. The base idea is that it is
matching on script hashes much like pay to script hash, but checks for one
of N scripts.
A motivating case is for "permission groups". Let's say I want to have a
single "root user" script, a 2 of 3 group, and a 2 of 2
>
> In particular, can this document
> specifically call out that a local network attacker can MITM all the
> peers.
It already does, last sentence of the authentication section is:
Querying multiple nodes and combining their answers can be a partial
solution to this, although as nothing authent
On Wed, Jul 16, 2014 at 7:25 AM, Jeff Garzik wrote:
> On the specific issue I raised, the BIP only says "Querying multiple
> nodes and combining their answers can be a partial solution to this"
> which is not very helpful advice. That's a partial answer to my
> question #2 with zero response for
>
> On the specific issue I raised, the BIP only says "Querying multiple
> nodes and combining their answers can be a partial solution to this"
> which is not very helpful advice. That's a partial answer to my
> question #2 with zero response for question #3.
>
I'm sorry you think it's unhelpful.
On the specific issue I raised, the BIP only says "Querying multiple
nodes and combining their answers can be a partial solution to this"
which is not very helpful advice. That's a partial answer to my
question #2 with zero response for question #3.
This sort of thing really needs a warning label
Thanks Jeff.
I do feel like a lot of this is covered in the writeup I attached to the
implementation pull request, and I went over it again in the ensuing
discussion, and also in the BIP.
The discussion of how to make it secure is covered in the "Upgrade" section
of the writeup and in the "Authen
On Wed, Jul 16, 2014 at 11:29 AM, Mike Hearn wrote:
> Yes sorry, you're right, the issue starts with the null code point. Python
> seems to have problems starting there too. It might work if we took that
> out.
Forbidding control characters, at least anything < 32 makes a lot of
sense to me. Carr
Thanks Mike. The BIPS process is ideally an implementation & draft BIP,
like IETF RFCs. Thanks for being a model citizen. :) Having an idea is
good; having an implementation is better.
Reviewing the code at the pull request, it appears OK, and I did give it a
quick test. I have a few minor ni
Damn, I just realized that I implement only the decoding side of BIP38.
So I cannot propose a complete test vector. Here is what I have:
Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK
UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER
LONG I, PILE OF POO)
P
I will change the bitcoinj implementation and propose a new test vector.
On 07/16/2014 11:29 AM, Mike Hearn wrote:
> Yes sorry, you're right, the issue starts with the null code point.
> Python seems to have problems starting there too. It might work if we
> took that out.
>
>
> On Wed, Jul 16
Yes sorry, you're right, the issue starts with the null code point. Python
seems to have problems starting there too. It might work if we took that
out.
On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
wrote:
> Guys, you are always talking about the Unicode astral plane, but in fact
> its a
Guys, you are always talking about the Unicode astral plane, but in fact
its a plain old (ASCII) control character where this problem starts and
likely ends: \u.
Let's ban/filter ISO control characters and be done with it. Most
control characters will never be enterable by any keyboard into a
I'm all for fixing bugs, but I know from bitter experience that outside the
BMP dragons lurk. Browsers don't even expose Unicode APIs at all. You end
up needing to ship an entire pure-js implementation, which can be too large
for some use cases (too much time sunk on that issue in my last job).
I'
19 matches
Mail list logo
