An idea for the bitcoin malware proposal below, the idea is at the bottom…
Using a desktop website and mobile device for 2/3 multisig in lieu of a
hardware device (trezor) and desktop website (mytrezor) works, but the key is
that the device used to input the two signatures cannot be in the same
Could we see a PR that adds it to BIP 66? Perhaps we'd all agree quickly
that its so simple we can just add it...
In either case it doesn't seem strictly necessary to me that it was
non-standard before it becomes a soft-fork...
On Tue, Feb 3, 2015 at 7:00 AM, Wladimir laa...@gmail.com wrote:
One way to do that is to just - right now - add a patch to 0.10 to
make those non-standard. This requires another validation flag, with a
bunch of switching logic.
The much simpler alternative is just adding this to BIP66's DERSIG
right now, which is a one-line change that's obviously
On Tue, Feb 3, 2015 at 4:00 AM, Wladimir laa...@gmail.com wrote:
One way to do that is to just - right now - add a patch to 0.10 to
make those non-standard. This requires another validation flag, with a
bunch of switching logic.
The much simpler alternative is just adding this to BIP66's
I think we should just do it, and include it with the other DERSIG changes
for 0.10.
On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
I understand it's late, which is also why I ask for opinions. It's
also not a priority, but if we release 0.10 without, it will
+1 I just ran an it-works test on #5743. Not exhaustive, but I do agree
it should be included w/ other DERSIG changes.
On Tue, Feb 3, 2015 at 1:19 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
I think we should just do it, and include it with the other DERSIG changes
for 0.10.
On
Using a desktop website and mobile device for 2/3 multisig in lieu of a
hardware device (trezor) and desktop website (mytrezor) works, but the key
is that the device used to input the two signatures cannot be in the same
band. What you are protecting against are MITM attacks. The issue is
Hi Adam - the conversation was pretty open regarding the factor / channel used
to sign at the bottom. No argument from me and I agree completely that
hardened single purpose computers are more secure than desktop browsers,
browser extensions, SMS, or mobile apps when involved in multisig
On Tue, Feb 3, 2015 at 10:15 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
The much simpler alternative is just adding this to BIP66's DERSIG
right now, which is a one-line change that's obviously softforking. Is
anyone opposed to doing so at this stage?
I'm retracting this proposed change.
TREZOR like devices with BIP70 support and third party cosigning services
are a solution I really like the sound of. I suppose though that adding
BIP70 request signature validation and adding certificate revocation
support starts to balloon the scope of what is supposed to be a very simple
Regardless, I think a standard for passing partially signed transactions
around might make sense (maybe a future extension to BIP70), with attention
to both PC - small hardware devices and pushing stuff around on the
Internet. It would be great if users had a choice of hardware signing
Why even bother with the specific HD scheme such as BIP32 or BIP44. What
are the interesting parameters?
Required:
- gap limit
Optional:
- which node of the derivation chain is actually exported (m0' for
BIP32, m44'0'account' for BIP44)
- which subnodes are used for external and
On 02/03/2015 10:33 AM, Levin Keller wrote:
Why not have more descriptive parameters? Saving on data?
Yes. QR codes are very size sensitive.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
On 03/02/15 11:37, Andreas Schildbach wrote:
Not really IMHO. Keys can be used on multiple blockchains.
Ah, correct. Timestamp it is.
Nitpick: They cannot be used on multiple blockchains according to BIP32.
In BIP43 we fixed that. :-)
--
Best Regards / S pozdravom,
Pavol Rusnak st...@gk2.sk
On 02/03/2015 01:22 AM, Pavol Rusnak wrote:
Hm, let me put the questions the other way around:
What gap limit should a wallet use if it encounters h=bip32?
It should follow the spec. I know BIP32-hierarchy is short on gap
limits, which is why (amongst other reasons) I expect
On 02/03/2015 11:10 AM, Pavol Rusnak wrote:
Another option that might make sense is the block number.
Not really IMHO. Keys can be used on multiple blockchains.
--
Dive into the World of Parallel Programming. The Go
On 02/03/2015 04:04 AM, Will wrote:
An idea for the bitcoin malware proposal below, the idea is at the bottom…
...
The trick we need to look at is how to use the bitcoin network as a
delivery mechanism to bypass the need for the trusted third party in the
example above.
Using the Bitcoin
On 03/02/15 10:33, Levin Keller wrote:
bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]path=[path in
derivation tree]subchains=[numbers]creationdate=[unixtimestamp]
I cannot come up with an usecase where path parameter would be needed.
FWIW childnumber and depth are already expressed in
18 matches
Mail list logo
