Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

[Peter Todd via bitcoin-dev]

On Wed, Aug 17, 2016 at 09:33:24PM -0300, Sergio Demian Lerner via bitcoin-dev 
wrote:
> If I send a transaction to an IoT device (say to an OpenDime or to the old
> Firmcoin), and the OpenDime must verify that the transaction has been mined
> (SPV verification), then it may expect the witness program to be of certain
> maximum size (an implementation-imposed  limit). If a Miner modifies the
> witness size and makes it too large, then the device may not be able to
> accept the transaction and the bitcoins may be lost. Lost because the
> private key is in the device, and because the device cannot accept that
> cloned transaction, never ever.
> 
> The same is true (although less strict) for side-chains and drive-chains:
> they may have certain restrictions on the size of transactions they accept
> to lock bitcoins.
> 
> That's why I'm proposing that a transaction becomes INVALID if the witness
> size is higher than the expected size (by the sender).

An important part of the design of segwit is that resource constained devices
doing lite-client verification don't need to get witness data at all to verify
lite-client merkle-path proofs.

Remember that lite-clients can't verify anything useful in witnesses anyway, so
for them to have witness data is useless (unless they're doing some kind of
embedded consensus protocol with data published in witnesses, but few people
here care about that use-case).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

[Sergio Demian Lerner via bitcoin-dev]

On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell  wrote:

> On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev
>  wrote:
> > I think that we're not attacking the real source of the problem: that the
> > witness data size is not signed.
>
> It's not possible to do that for the general case, since you may not
> even know the witness size in advance (even for checksig's ECDSA, the
> encoding is variable sized).
>
> That's why scripts can check a maximum witness size, and not necessarily
an exact value.


I think that is overly focusing on "someone might change the feerate",
> yes that is an example of an undesirable witness tampering, but it's
> not the only one.
>
> I don't think fees are the problem. There is another problem. Let me
re-explain.
If I send a transaction to an IoT device (say to an OpenDime or to the old
Firmcoin), and the OpenDime must verify that the transaction has been mined
(SPV verification), then it may expect the witness program to be of certain
maximum size (an implementation-imposed  limit). If a Miner modifies the
witness size and makes it too large, then the device may not be able to
accept the transaction and the bitcoins may be lost. Lost because the
private key is in the device, and because the device cannot accept that
cloned transaction, never ever.

The same is true (although less strict) for side-chains and drive-chains:
they may have certain restrictions on the size of transactions they accept
to lock bitcoins.

That's why I'm proposing that a transaction becomes INVALID if the witness
size is higher than the expected size (by the sender).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

[Sergio Demian Lerner via bitcoin-dev]

I think that we're not attacking the real source of the problem: that the
witness data size is not signed. It may be the case that a new source of
malleability is detected in witness programs later, or related to new
opcodes we'll soft-fork in the future.

The problem is real, as some systems (such as hardware wallets or other
low-memory IoT embedded systems) may have hard limits in the size of the
witness program they can accept. So we need a solution for all current and
future segwit extension problems.

We could soft-fork to add an opcode OP_PROGSIZE using segwit script
versioning that pushes in the stack the size of the segwit program being
evaluated, and then the script can take any action it wishes based on that.

Example:
<0x50> OP_PROGSIZE OP_GREATERTHAN OP_VERIFY . OP_CHECKSIG

Then an attacker cannot create a clone of the transaction having a witness
ECDSA signature longer than 0x50 bytes. (many details omitted in this
example)



On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > On August 17, 2016 at 12:40 AM Luke Dashjr  wrote:
> >
> >
> > On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev
> wrote:
> > > To completely replicate the original behaviour, one may use:
> > > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if
> script}
> > > ELSE DROP {else script} ENDIF"
> >
> > This is much uglier than expected. IMO if that's the best workaround for
> the
> > current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if
> they
> > need to avoid malleability issues.
>
> It is ugly only if you want to faithfully replicate the behaviour. I'd
> argue that in no real use case you need to do this. For example, "OP_SIZE
> OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must
> return a valid MINIMALDATA number.
>
> And your workaround does not fix malleability, since any non-0x01 values
> are valid FALSE
>
> However, in some case, enforcing MINIMALIF does require 1 more witness
> byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/
> 013036.html
>
> I think the best strategy is to make it a relay policy first, and decide
> whether we want a softfork later.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Bryan Bishop via bitcoin-dev]

On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>

"Welcome to my threat model."

In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.

I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.

Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.

As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.

Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.

((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Marek Palatinus via bitcoin-dev]

Hi,

I fundamentally disagree with the concept of driving signing workflow by
the wallet software. Wallet software does not know in advance all data
necessary for the signer to do the job. As Jochen mentioned above, Segwit
vs Non-segwit use cases are a good example, but there may be many.

Currently the TREZOR protocol works like device is a server and wallet is a
client calling methods on it. It's like: "Sign this for me, please", "Ok,
give me this information", "Here it is", "Now I need this another
piece" "There is the signature". Wallet does not know in advance what
will go next, and it is for sake of simplicity. I'm quite happy with the
protocol so far.

Considering the difference in between current hardware, I really don't
think it is possible to find any minimal URI-based API good enough for
communicating with all vendors. What I see more likely is some 3rd party
libraries (JS, C++, Python, ...) defining high-level API and implementing
hardware-specific protocols and transports as plugins. That way vendors are
not limited by strict standard and application developers and services can
integrate wide range of hardware wallets easily. However, this can be done
already and we do not need any standardization process (yet).

slush

On Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Dana
>
> >> The URI scheme does not require any sorts of wallet app level
> >> configuration (where the stdio/pipe approach would require to configure
> >> some details about the used hardware wallet).
> >
> > Hi everybody, just thought I’d throw my opinion in here.
> >
> > The URI scheme is a nice idea, but this ignores the fact that hardware
> wallet vendors do most of the work on talking between the computer/mobile
> and the wallet on a lower level of communication. In the case of BitLox,
> the base protocol is Google’s ProtoBuf. The commands and transaction data
> is in a “schema” which is then encoded in different methods accessible via
> ProtoBuf (depending on the data being sent). The advantages of this
> protocol is that it can be implemented on a wide variety of platforms. (but
> that’s a whole 'nother discussion)
> >
> > The URI would be handled way up in the specific application (such as
> the mytrezor wallet software or the various standalone wallets) - nowhere
> near the actual hardware communications layer.
>
> This is maybe a question of the scope.
> The BIP I'm proposing would make a clear interface cut between
> wallet-with-unsigned-transaction and a signing-device (and maybe between
> wallet-requires-pubkey, signing-device generate some pubkeys [or
> non-hardened xpub]).
>
> The detached-signing proposal does not duplicate work. It just moves the
> current plugin design into a separate application. Plugins in security
> and privacy critical wallet software is something that should probably
> be avoided.
>
> It's intentional at a high level to allow maximum flexibility at the
> hardware interaction layer.
>
> Your protobuf example is a good use-case. You could implement your
> custom processes behind the URI scheme (which is probably way more
> efficient then writing a couple of wallet plugins where you – at the end
> – mostly don't control the deployment and the source-code).
>
> Defining a standard on the hardware interaction layer is possible, but a
> fairly different approach.
>
> 
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi Dana

>> The URI scheme does not require any sorts of wallet app level
>> configuration (where the stdio/pipe approach would require to configure
>> some details about the used hardware wallet).
> 
> Hi everybody, just thought I’d throw my opinion in here.
> 
> The URI scheme is a nice idea, but this ignores the fact that hardware wallet 
> vendors do most of the work on talking between the computer/mobile and the 
> wallet on a lower level of communication. In the case of BitLox, the base 
> protocol is Google’s ProtoBuf. The commands and transaction data is in a 
> “schema” which is then encoded in different methods accessible via ProtoBuf 
> (depending on the data being sent). The advantages of this protocol is that 
> it can be implemented on a wide variety of platforms. (but that’s a whole 
> 'nother discussion)
> 
> The URI would be handled way up in the specific application (such as the 
> mytrezor wallet software or the various standalone wallets) - nowhere near 
> the actual hardware communications layer.

This is maybe a question of the scope.
The BIP I'm proposing would make a clear interface cut between
wallet-with-unsigned-transaction and a signing-device (and maybe between
wallet-requires-pubkey, signing-device generate some pubkeys [or
non-hardened xpub]).

The detached-signing proposal does not duplicate work. It just moves the
current plugin design into a separate application. Plugins in security
and privacy critical wallet software is something that should probably
be avoided.

It's intentional at a high level to allow maximum flexibility at the
hardware interaction layer.

Your protobuf example is a good use-case. You could implement your
custom processes behind the URI scheme (which is probably way more
efficient then writing a couple of wallet plugins where you – at the end
– mostly don't control the deployment and the source-code).

Defining a standard on the hardware interaction layer is possible, but a
fairly different approach.





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Dana L. Coe via bitcoin-dev]

> On Aug 17, 2016, at 15:24, Jonas Schnelli via bitcoin-dev 
>  wrote:
> 
> URI scheme instead of stdio/pipe
> 
> The URI scheme is not ugly. Its a modern way – implemented in almost all
> platforms – how applications can interact with each other while not
> directly knowing each other. Registering a URI scheme like "bitcoin://"
> has some concrete advantages over just piping through stdio.
> 
> Also, the stdio/piping approach does not work for mobile platforms
> (where the URI scheme works).
> 
> The URI scheme does not require any sorts of wallet app level
> configuration (where the stdio/pipe approach would require to configure
> some details about the used hardware wallet).

Hi everybody, just thought I’d throw my opinion in here.

The URI scheme is a nice idea, but this ignores the fact that hardware wallet 
vendors do most of the work on talking between the computer/mobile and the 
wallet on a lower level of communication. In the case of BitLox, the base 
protocol is Google’s ProtoBuf. The commands and transaction data is in a 
“schema” which is then encoded in different methods accessible via ProtoBuf 
(depending on the data being sent). The advantages of this protocol is that it 
can be implemented on a wide variety of platforms. (but that’s a whole 'nother 
discussion)

The URI would be handled way up in the specific application (such as the 
mytrezor wallet software or the various standalone wallets) - nowhere near the 
actual hardware communications layer.

Best regards,
Dana
BitLox


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP draft: HTLC transactions

[Johnson Lau via bitcoin-dev]

> On July 20, 2016 at 2:17 AM Luke Dashjr via bitcoin-dev 
>  wrote:
> 
> On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote:
> 
> > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote:
> > 
> > > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
> > > in Bitcoin.
> > > 
> > > HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV
> > > can be used to recover your funds if the other party is not cooperative.
> > > These
> > > 
> > > scripts take the following general form:
> > >  [HASHOP]  OP_EQUAL
> > >  OP_IF
> > > 
> > > 
> > > 
> > > OP_ELSE
> > > 
> > >  [TIMEOUTOP] OP_DROP 
> > > 
> > > OP_ENDIF
> > >  OP_CHECKSIG
> > 
> > Note that because you're hashing the top item on the stack regardless
> > scriptSig's that satisfy HTLC's are malleable: that top stack item can be
> > changed anything in the digest-not-provided case and the script still
> > passes.
> 
> OP_SIZE
> OP_IF
>  [HASHOP]  OP_EQUALVERIFY
>  
> OP_ELSE
>   [TIMEOUTOP]
>  
> OP_ENDIF
> OP_CHECKSIG
> 

This is incompatible with my proposal for fixing the OP_IF/NOTIF malleability 
in segwit ("MINIMALIF"). In this case only the timeout branch may be executed.

To make it compatible, you may use one of the following 2 scripts:

OP_SIZE OP_0NOTEQUAL
OP_IF
 [HASHOP]  OP_EQUALVERIFY
 
OP_ELSE
  [TIMEOUTOP] OP_DROP
 
OP_ENDIF
OP_CHECKSIG

or

OP_IF
 [HASHOP]  OP_EQUALVERIFY
 
OP_ELSE
  [TIMEOUTOP] OP_DROP
 
OP_ENDIF
OP_CHECKSIG

The overall witness size are the same for these scripts. They are 1 byte larger 
than Luke's script, in case MINIMALIF is not enforced.

(btw, the OP_DROP after TIMEOUTOP is missing in Luke's script)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Nicolas Bacca via bitcoin-dev]

On Wed, Aug 17, 2016 at 9:24 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Conclusion:
> ===
> * Non of the points convinced me that there is a better alternative to
> the proposed URI scheme interaction (please tell me if I'm stubborn).
>

I'd also agree with this - and it's convenient to test against simulators /
mocks.

-- 
Nicolas Bacca | CTO, Ledger
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Nicolas Bacca via bitcoin-dev]

On Wed, Aug 17, 2016 at 2:14 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I'm not aware of any ECC-enabled smart-cards that can sign the specific
> curve
> that Bitcoin uses, not to mention the fact that those smartcards generally
> only
> speak higher level protocols than raw signature generation, precluding the
> signing of bitcoin transactions.
>

any Java Card supporting ECC can sign on user supplied Weierstrass curve
parameters - you can find a good shopping list at
http://www.fi.muni.cz/~xsvenda/jcsupport.html (look for ALG_ECDSA_SHA256 on
javacard.crypto.signature). The NXP JCOP platform (found in Yubico Neo) is
a popular choice, and then you can add your own custom logic for validation.

-- 
Nicolas Bacca | CTO, Ledger
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi all

Thanks for the response.


Jochen's points:
===
Indeed. There are some missing points and I'd like to work this into the
BIP. Thanks for bringing this up.

Along with a support for wallet-creation with a xpub from the signing
device, we might also want to support loading multiple pubkeys into a
keypool from the device (in case someone likes to use hardened
derivation at all levels). I guess this would not be over-complex to
achieve.

Luke's points:
=

USB / Plugin/Driver problematic
---
I don't think it would be wise to set Trezors USB communication
(hardware interface) as "the standard". A) A USB stack/interaction in
wallets should be avoided IMO. B) This approach won't work for some
platforms (like iOS) due to technical and legal restrictions.

In my opinion, each hardware wallet has to provide custom software in
any case. We don't want to standardize how a hardware wallet has to do
backups, recovers, firmware upgrade, etc. and if we agree on that, then
hardware wallets must provide an application (mostly Chrome extensions
today) to implement theses processes.

Also diversity at the hardware interface will reduce centralized risks
for weak security/vulnerabilities.

The proposed URI scheme approach does not require any sorts of
libraries/dependencies. USB HID can be a problem for cross platform
desktop wallets as well as it won't work of one of the major mobile
platform (iOS). USB HID interaction can be restricted or disabled in non
superuser setups where I'm not aware of any restriction on URI-Scheme level.

URI scheme instead of stdio/pipe

The URI scheme is not ugly. Its a modern way – implemented in almost all
platforms – how applications can interact with each other while not
directly knowing each other. Registering a URI scheme like "bitcoin://"
has some concrete advantages over just piping through stdio.

Also, the stdio/piping approach does not work for mobile platforms
(where the URI scheme works).

The URI scheme does not require any sorts of wallet app level
configuration (where the stdio/pipe approach would require to configure
some details about the used hardware wallet).


Thomase D.'s points:
===
Standardizing to many layers of the interaction stack (including the
hardware interaction) will very likely result in vendors not sticking to
the standard.

I agree, the URI scheme has some fragility, but at a level where we can
handle it and with the advantage of abstracting the used brand/device
for privacy and security reasons.

> The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets.

Most operating systems allow to check if a certain URL-Scheme is
supported (registered), this would allow at least to check for known
major vendors (like trezor, etc.) which should solve most
multi-hardware-wallet use-cases.

The URI return scheme does work fine and with the correct set timeouts
it should result in a neat user experience.
It's the proposed way of application intercommunication in Apple iOS [1]
and Google Android [2].

Conclusion:
===
* Non of the points convinced me that there is a better alternative to
the proposed URI scheme interaction (please tell me if I'm stubborn).
* Also, we should move the end users UX in the center of the
problems-to-solve (and not overweight the ideal
code-/API-/hardware-interaction-design while ignoring the end user
experience).
* We should try to not over-standardize the interaction with the device
itself to allow flexibility on the hardware wallet vendor side.

[1]
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
[2] https://developer.android.com/training/basics/intents/sending.html





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev