Re: [bitcoin-dev] BIP 174 thoughts
> * Key-value map model or set model.
> * Ability for Combiners to verify two PSBT are for the same transaction
> * Optional signing
> * Derivation from xpub or fingerprint
> * Generic key offset derivation
> * Hex encoding?
I think all of Pieters points are valid and reasonable thought, though I’m
unsure if it would be worth changing the existing-implementation-breaking
things like the k/v set model.
AFAIK things like non-hex-encoding or generic key offset derivation are
extensions and would not break existing implementations.
Further thoughts on BIP174 from my side.
Key derivation in multisig:
From my understanding, the signers and the creator must have agreed – in
advance to the PSBT use case – on a key derivation scheme.
BIP32 derivation is assumed, but may not always be the case.
Sharing xpubs (the chaincode) may be a concern in non-trust-relationships
between signer(s) and the creator (regarding Pieters xpub/fingerprint concerns).
Providing the type 0x03, the bip32 derivation path is one form of a support to
faster (or computational possible) derivation of the required keys for signing
a particular input.
From my point of view, it is a support of additional metadata shared between
creator and signer and provided from the creator to the signer for faster (or
computation possible) key deviation.
I think it could be more flexible (generic) in BIP174.
It could be just a single child key {32-bit int}, or just a keypath ({32-bit
int}]{32-bit int}…) which is very likely sufficient for a HWW to derive the
relevant key without the creation of a lookup-window or other „maps".
It could even be an enciphered payload which was shared during
address/redeem-script generation and „loops“ back during a signing request.
Maybe I’m overcomplicating things, but for practical multisig with HWWs, a
simple BIP32-child-key-index or BIP32-keypath derivation support field should
be sufficient.
A generic „derivation support field“, provided from the signer to the creator
during address-generation that just „loops“ back during the PSBT use-cases is
probably a overkill.
Thanks
—
/jonas
signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible?
Well miners already regularly mine empty blocks. However, it is usually in the economic interest of the miners to collect transaction fees. This incentive should hopefully be enough to prevent miners from choosing to produce many empty blocks. If a nation state attacker decides to allocate billions in resources to attack Bitcoin, then that is a bigger discussion. The risk there is double-spends, not empty blocks. -Alex On Mon, Jun 18, 2018 at 11:39 AM Артём Литвинович via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Dilution is a potential attack i randomly came up with in a Twitter > arguement and couldn't find any references to or convincing arguments of it > being implausible. > > Suppose a malicious actor were to acquire a majority of hash power, and > proceed to use that hash power to produce valid, but empty blocks. > > As far as i understand it, this would effectively reduce the block rate by > half or more and since nodes can't differentiate block relay and block > production there would be nothing they can do to adjust difficulty or black > list the attacker. > > At a rough estimate of $52 per TH equipment cost (Antminer pricing) and > 12.5 BTC per 10 minutes power cost we are looking at an order of $2 billion > of equipment and $0.4 billion a month of power costs (ignoring block > reward) to maintain an attack - easily within means of even a minor > government-scale actor. > > Is that a plausible scenario, or am i chasing a mirage? If it is > plausible, what could be done to mitigate it? > > > -Artem > ___ > 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] Miner dilution attack on Bitcoin - is that something plausible?
https://github.com/libbitcoin/libbitcoin/wiki/Other-Means-Principle >> On Mon, Jun 18, 2018 at 11:39 AM Артём Литвинович via bitcoin-dev >> wrote: >> Dilution is a potential attack i randomly came up with in a Twitter >> arguement and couldn't find any references to or convincing arguments of it >> being implausible. >> >> Suppose a malicious actor were to acquire a majority of hash power, and >> proceed to use that hash power to produce valid, but empty blocks. >> >> As far as i understand it, this would effectively reduce the block rate by >> half or more and since nodes can't differentiate block relay and block >> production there would be nothing they can do to adjust difficulty or black >> list the attacker. >> >> At a rough estimate of $52 per TH equipment cost (Antminer pricing) and 12.5 >> BTC per 10 minutes power cost we are looking at an order of $2 billion of >> equipment and $0.4 billion a month of power costs (ignoring block reward) to >> maintain an attack - easily within means of even a minor government-scale >> actor. >> >> Is that a plausible scenario, or am i chasing a mirage? If it is plausible, >> what could be done to mitigate it? >> >> >> -Artem >> ___ >> 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] BIP 174 thoughts
Hello,
First of all, we'd like to apologize for such a late feedback, since
there is a PR for this already. We've come up with a few more notes on
this, so we are introducing those in this message and replying on
Pieter's points in another one.
1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we
know, which BIP-32 path goes to which input? The only idea that comes to
my mind is that we should match the input's scriptPubKey's pubkey to
this 0x03's key (the public key).
If our understanding is correct, the BIP-32 path is global to save space
in case two inputs share the same BIP-32 path? How often does that
happen? And in case it does, doesn't it mean an address reuse which is
discouraged?
Also, we believe that if the public key is to be used as "spent to by an
output" it should be in an output section. If the public key is to be
used to sign an input, it should be in the input section. Again, how
often are those the same? We understand creating another section might
be cumbersome, but it'd significantly increase clarity to have global,
input and output section.
Alternately, we could keep “spend to” public keys in the global section,
and put the input public keys to the per-input sections. This is less
clear, but doesn’t introduce another section. A question to consider is,
will there be more per-output data? If yes, it might make sense to have
an output section.
2) The global items 0x01 (redeem script) and 0x02 (witness script) are
somewhat confusing. Let's consider only the redeem script (0x01) to make
it simple. The value description says: "A redeem script that will be
needed to sign a Pay-To-Script-Hash input or is spent to by an output.".
Does this mean that the record includes both input's redeem script
(because we need to sign it), but also a redeem script for the output
(to verify we are sending to a correct P2SH)? To mix those two seems
really confusing.
Yet again, adding a new output section would make this more readable. We
would include the input’s redeem script in the input section and the
output’s redeem script again in the output section, because they’ll most
likely differ anyway.
The rationale says that the scripts are global to avoid duplication.
However, how often is this the case? The scripts include a hash of some
OP codes and the recipient's public key for example. So a) how often are
two scripts equal to justify this? b) if they're the same, doesn't it
yet again signalize address reuse?
3) The sighash type 0x03 says the sighash is only a recommendation. That
seems rather ambiguous. If the field is specified shouldn't it be binding?
4) Is it a good idea to skip records which types we are unaware of? We
can't come up with a reasonable example, but intuitively this seems as a
potential security issue. We think we should consider introducing a
flag, which would define if the record is "optional". In case the signer
encounters a record it doesn't recognize and such flag is not set, it
aborts the procedure. If we assume the set model we could change the
structure to {data}. We are not keen on
this, but we wanted to include this idea to see what you think.
---
In general, the standard is trying to be very space-conservative,
however is that really necessary? We would argue for clarity and ease of
use over space constraints. We think more straightforward approach is
desired, although more space demanding. What are the arguments to make
this as small as possible? If we understand correctly, this format is
not intended for blockchain nor for persistent storage, so size doesn’t
matter nearly as much.
Thank you,
Tomas Susanka
Jan Matejek
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] BIP 174 thoughts
hello,
this is our second e-mail with replies to Pieter's suggestions.
On 16.6.2018 01:34, pieter.wuille at gmail.com (Pieter Wuille) wrote:
> * Key-value map model or set model.
>
> This was suggested in this thread:
> https://twitter.com/matejcik/status/1002618633472892929
>
> The motivation behind using a key-value model rather than a simple
> list of records was that PSBTs can be duplicated (given to multiple
> people for signing, for example), and merged back together after
> signing. With a generic key-value model, any implementation can remove
> the duplication even if they don't understand fields that may have
> been added in future extensions.
>
> However, almost the same can be accomplished by using the simpler set
> model (the file consists of a set of records, with no duplication
> allowed). This would mean that it would technically be legal to have
> two partial signatures with the same key for the same input, if a
> non-deterministic signer is used.
Strongly agree with this.
Just to note, we should probably use varint for the field - this
allows us, e.g., to create “namespaces” for future extensions by using
one byte as namespace identifier and one as field identifier.
>
> On the other hand, this means that certain data currently encoded
> inside keys can be dropped, reducing the PSBT size. This is
> particularly true for redeemscripts and witnessscripts, as they can
> just be computed by the client when deserializing. The two types could
> even be merged into just "scripts" records - as they don't need to be
> separated based on the way they're looked up (Hash160 for P2SH, SHA256
> for P2WSH). The same could be done for the BIP32 derivation paths,
> though this may be expensive, as the client would need to derive all
> keys before being able to figure out which one(s) it needs.
It could be nice if the output scripts records would be ordered the same
as their corresponding outputs. But what if the Creator doesn’t want to
include a script for an output? Perhaps the Script record should have a
field to match it to the appropriate output.
As for input scripts, we suggest that they are per-input and not
included in the global record, see the other thread.
>
> One exception is the "transaction" record, which needs to be unique.
> That can either be done by adding an exception ("there can only be one
> transaction record"), or by encoding it separately outside the normal
> records (that may also be useful to make it clear that it is always
> required).
This seems to be the case for some fields already - i.e., an input field
must have exactly one of Non-witness UTXO or Witness Output. So “adding
an exception” is probably just a matter of language?
We’d also like to note that the “number of inputs” field should be
mandatory - and as such, possibly also a candidate for outside-record field.
>
> * Ability for Combiners to verify two PSBT are for the same transaction
>
> Clearly two PSBTs for incompatible transactions cannot be combined,
> and this should not be allowed.
>
> It may be easier to enforce this if the "transaction" record inside a
> PSBT was required to be in a canonical form, meaning with empty
> scriptSigs and witnesses. In order to do so, there could be per-input
> records for "finalized scriptSig" and "finalized witness". Actually
> placing those inside the transaction itself would only be allowed when
> all inputs are finalized.
Agreed! Also increases clarity, which is desired.
> * Derivation from xpub or fingerprint
>
> For BIP32 derivation paths, the spec currently only encodes the 32-bit
> fingerprint of the parent or master xpub. When the Signer only has a
> single xprv from which everything is derived, this is obviously
> sufficient. When there are many xprv, or when they're not available
> indexed by fingerprint, this may be less convenient for the signer.
> Furthermore, it violates the "PSBT contains all information necessary
> for signing, excluding private keys" idea - at least if we don't treat
> the chaincode as part of the private key.
>
> For that reason I would suggest that the derivation paths include the
> full public key and chaincode of the parent or master things are
> derived from. This does mean that the Creator needs to know the full
> xpub which things are derived from, rather than just its fingerprint.
We don’t understand the rationale for this idea. Do you see a scenario
where an index on master fingerprint is not available but index by xpubs
is? In our envisioned use cases at least, indexing private keys by xpubs
(as opposed to deriving from a BIP32 path) makes no sense.
Maybe this folds into the proposal for generic derivation below, or
something like implementation-specific derivation methods?
best regards
Jan Matejek
Tomas Susanka
signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org
Re: [bitcoin-dev] BIP 174 thoughts
I agree with matejcik’s point 1 to 3 and especially with point 4. The mandatory flag (or optional-flag) makes much sense to me. > --- > > In general, the standard is trying to be very space-conservative, > however is that really necessary? We would argue for clarity and ease of > use over space constraints. We think more straightforward approach is > desired, although more space demanding. What are the arguments to make > this as small as possible? If we understand correctly, this format is > not intended for blockchain nor for persistent storage, so size doesn’t > matter nearly as much. I don’t see any reasons why space would be an issue. HWWs probably can’t handle PBST natively since it is not optimised for presenting various informations in a signing-verification. A single stream-in of a PSBT through USB (or similar channel) will not work in many cases since HWW come often with very restrictive RAM constraints. Furthermore, I forget to mention in my last mail, that registering (or defining) a mime-type for PSBT would probably a great usability feature. (Send PSBT by email/messanger and with dbl-click to open feature, etc.) /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 174 thoughts
On Tue, Jun 19, 2018 at 7:20 AM, matejcik via bitcoin-dev
wrote:
Thanks for your comments so far. I'm very happy to see people dig into
the details, and consider alternative approaches.
> 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we
> know, which BIP-32 path goes to which input? The only idea that comes to
> my mind is that we should match the input's scriptPubKey's pubkey to
> this 0x03's key (the public key).
> If our understanding is correct, the BIP-32 path is global to save space
> in case two inputs share the same BIP-32 path? How often does that
> happen? And in case it does, doesn't it mean an address reuse which is
> discouraged?
Yes, the reason is address reuse. It may be discouraged, but it still
happens in practice (and unfortunately it's very hard to prevent
people from sending to the same address twice).
It's certainly possible to make them per-input (and even per-output as
suggested below), but I don't think it gains you much. At least when a
signer supports any kind of multisig, it needs to match up public keys
with derivation paths. If several can be provided, looking them up
from a global table or a per-input table shouldn't fundamentally
change anything.
However, perhaps it makes sense to get rid of the global section
entirely, and make the whole format a transaction plus per-input and
per-output extra fields. This would result in duplication in case of
key reuse, but perhaps that's worth the complexity reduction.
> 2) The global items 0x01 (redeem script) and 0x02 (witness script) are
> somewhat confusing. Let's consider only the redeem script (0x01) to make
> it simple. The value description says: "A redeem script that will be
> needed to sign a Pay-To-Script-Hash input or is spent to by an output.".
> Does this mean that the record includes both input's redeem script
> (because we need to sign it), but also a redeem script for the output
> (to verify we are sending to a correct P2SH)? To mix those two seems
> really confusing.
>
> Yet again, adding a new output section would make this more readable. We
> would include the input’s redeem script in the input section and the
> output’s redeem script again in the output section, because they’ll most
> likely differ anyway.
I think here it makes sense because there can actually only be (up to)
one redeemscript and (up to) one witnessscript. So if we made those
per-input and per-output, it may simplify signers as they don't need a
table lookup to find the correct one. That would also mean we can drop
their hashes, even if we keep a key-value model.
> 3) The sighash type 0x03 says the sighash is only a recommendation. That
> seems rather ambiguous. If the field is specified shouldn't it be binding?
Perhaps, yes.
> 4) Is it a good idea to skip records which types we are unaware of? We
> can't come up with a reasonable example, but intuitively this seems as a
> potential security issue. We think we should consider introducing a
> flag, which would define if the record is "optional". In case the signer
> encounters a record it doesn't recognize and such flag is not set, it
> aborts the procedure. If we assume the set model we could change the
> structure to {data}. We are not keen on
> this, but we wanted to include this idea to see what you think.
Originally there was at least this intuition for why it shouldn't be
necessary: the resulting signature for an input is either valid or
invalid. Adding information to a PSBT (which is what signers do)
either helps with that or not. The worst case is that they simply
don't have enough information to produce a signature together. But an
ignored unknown field being present should never result in signing the
wrong thing (they can always see the transaction being signed), or
failing to sign if signing was possible in the first place. Another
way of looking at it, the operation of a signer is driven by queries:
it looks at the scriptPubKey of the output being spent, sees it is
P2SH, looks for the redeemscript, sees it is P2WSH, looks for the
witnessscript, sees it is multisig, looks for other signers'
signatures, finds enough for the threshold, and proceeds to sign and
create a full transaction. If at any point one of those things is
missing or not comprehensible to the signer, he simply fails and
doesn't modify the PSBT.
However, if the sighash request type becomes mandatory, perhaps this
is not the case anymore, as misinterpreting something like this could
indeed result in an incorrect signature.
If we go down this route, if a field is marked as mandatory, can you
still act as a combiner for it? Future extensions should always
maintain the invariant that a simple combiner which just merges all
the fields and deduplicates should always be correct, I think. So such
a mandatory field should only apply to signers?
> In general, the standard is trying to be very space-conservative,
> however is that really necessary? We would argue for clarity and ease of
> use over sp
Re: [bitcoin-dev] BIP 174 thoughts
On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote: ... > First of all, it's unclear to me to what extent projects have already > worked on implementations, and thus to what extent the specification > is still subject to change. A response of "this is way too late" is > perfectly fine. ... I am working on a python implementation of BIP 174 as part of a multi-sig hardware wallet I have in the works. I am not so far along as to say that all these changes are way too late, but I’ll comment on the following: > Key-value map model or set model I believe the key-value map model should be kept because as Jonas Schnelli said it’s probably not worth significantly breaking existing implementations like Peter Gray’s, or maybe more who have not spoken up. However, I appreciate the benefit of the set model particularly in regards to size consideration and the merging of redeemscripts and witnesscripts into single “scripts” records. >Ability for Combiners to verify two PSBT are for the same transaction This idea makes a lot of sense, much more intuitive. >Hex encoding? I was hoping for some standard here was well and I agree using something more compact than hex is important. My understanding is Z85 is better for use with JSON than Base64, which is probably a good benefit to have here. I will continue developing under the current spec and if there ends up being consensus for some of the changes here I’m fine with re-doing the work. I will be following this thread closer now. Best, Jason Les ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
