Re: [bitcoin-dev] Version 1 witness programs (first draft)

[Mark Friedenbach via bitcoin-dev]

Clean stack should be eliminated for other possible future uses, the most 
obvious of which is recursive tail-call for general computation capability. I’m 
not arguing for that at this time, just arguing that we shouldn’t prematurely 
cut off an easy implementation of such should we want to. Clean stack must 
still exist as policy for future soft-fork safety, but being a consensus 
requirement was only to avoid witness malleability, which committing to the 
size of the witness also accomplishes.

Committing to the number of witness elements is fully sufficient, and using the 
number of elements avoids problems of not knowing the actual size in bytes at 
the time of signing, e.g. because the witness contains a merkle proof generated 
by another party from an unbalanced tree, and unbalanced trees are expected to 
be common (so that elements can be placed higher in the tree in accordance with 
their higher expected probability of usage). Other future extensions might also 
have variable-length proofs.

> On Sep 30, 2017, at 7:47 PM, Luke Dashjr  wrote:
> 
> Should it perhaps commit to the length of the serialised witness data instead 
> or additionally? Now that signatures are no longer variable-length, that'd be 
> possible...
> 
> As far as tail-call needs are concerned, CLEANSTACK wouldn't have been 
> checked 
> until AFTER the tail-call in the first draft. But I suppose eliminating it 
> for 
> other possible future purposes is still useful.
> 
> Luke

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

Re: [bitcoin-dev] Version 1 witness programs (first draft)

[Luke Dashjr via bitcoin-dev]

Should it perhaps commit to the length of the serialised witness data instead 
or additionally? Now that signatures are no longer variable-length, that'd be 
possible...

As far as tail-call needs are concerned, CLEANSTACK wouldn't have been checked 
until AFTER the tail-call in the first draft. But I suppose eliminating it for 
other possible future purposes is still useful.

Luke


On Sunday 01 October 2017 2:23:47 AM Mark Friedenbach wrote:
> The CLEANSTACK rule should be eliminated, and instead the number of items
> on the stack should be incorporated into the signature hash. That way any
> script with a CHECKSIG is protected from witness extension malleability,
> and those rare ones that do not use signature operations can have a “DEPTH
> 1 EQUALVERIFY” at the end. This allows for much simpler tail-call
> evaluation as you don’t need to pass arguments on the alt-stack.
> 
> > On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev
> >  wrote:
> > 
> > I've put together a first draft for what I hope to be a good next step
> > for
> > 
> > Segwit and Bitcoin scripting:
> >https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
> > 
> > This introduces 5 key changes:
> > 
> > 1. Minor versions for witnesses, inside the witness itself. Essentially
> > the witness [major] version 1 simply indicates the witness commitment is
> > SHA256d, and nothing more.
> > 
> > The remaining two are witness version 1.0 (major 1, minor 0):
> > 
> > 2. As previously discussed, undefined opcodes immediately cause the
> > script to exit with success, making future opcode softforks a lot more
> > flexible.
> > 
> > 3. If the final stack element is not exactly true or false, it is
> > interpreted as a tail-call Script and executed. (Credit to Mark
> > Friedenbach)
> > 
> > 4. A new shorter fixed-length signature format, eliminating the need to
> > guess the signature size in advance. All signatures are 65 bytes, unless
> > a condition script is included (see #5).
> > 
> > 5. The ability for signatures to commit to additional conditions,
> > expressed in the form of a serialized Script in the signature itself.
> > This would be useful in combination with OP_CHECKBLOCKATHEIGHT (BIP
> > 115), hopefully ending the whole replay protection argument by
> > introducing it early to Bitcoin before any further splits.
> > 
> > This last part is a big ugly right now: the signature must commit to the
> > script interpreter flags and internal "sigversion", which basically serve
> > the same purpose. The reason for this, is that otherwise someone could
> > move the signature to a different context in an attempt to exploit
> > differences in the various Script interpretation modes. I don't consider
> > the BIP deployable without this getting resolved, but I'm not sure what
> > the best approach would be. Maybe it should be replaced with a witness
> > [major] version and witness stack?
> > 
> > There is also draft code implementing [the consensus side of] this:
> >https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
> > 
> > Thoughts? Anything I've overlooked / left missing that would be
> > uncontroversial and desirable? (Is any of this unexpectedly controversial
> > for some reason?)
> > 
> > Luke
> > ___
> > 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] Version 1 witness programs (first draft)

[Mark Friedenbach via bitcoin-dev]

The CLEANSTACK rule should be eliminated, and instead the number of items on 
the stack should be incorporated into the signature hash. That way any script 
with a CHECKSIG is protected from witness extension malleability, and those 
rare ones that do not use signature operations can have a “DEPTH 1 EQUALVERIFY” 
at the end. This allows for much simpler tail-call evaluation as you don’t need 
to pass arguments on the alt-stack.

> On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev 
>  wrote:
> 
> I've put together a first draft for what I hope to be a good next step for 
> Segwit and Bitcoin scripting:
>https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
> 
> This introduces 5 key changes:
> 
> 1. Minor versions for witnesses, inside the witness itself. Essentially the 
> witness [major] version 1 simply indicates the witness commitment is SHA256d, 
> and nothing more.
> 
> The remaining two are witness version 1.0 (major 1, minor 0):
> 
> 2. As previously discussed, undefined opcodes immediately cause the script to 
> exit with success, making future opcode softforks a lot more flexible.
> 
> 3. If the final stack element is not exactly true or false, it is interpreted 
> as a tail-call Script and executed. (Credit to Mark Friedenbach)
> 
> 4. A new shorter fixed-length signature format, eliminating the need to guess 
> the signature size in advance. All signatures are 65 bytes, unless a 
> condition 
> script is included (see #5).
> 
> 5. The ability for signatures to commit to additional conditions, expressed 
> in 
> the form of a serialized Script in the signature itself. This would be useful 
> in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the 
> whole replay protection argument by introducing it early to Bitcoin before 
> any 
> further splits.
> 
> This last part is a big ugly right now: the signature must commit to the 
> script interpreter flags and internal "sigversion", which basically serve the 
> same purpose. The reason for this, is that otherwise someone could move the 
> signature to a different context in an attempt to exploit differences in the 
> various Script interpretation modes. I don't consider the BIP deployable 
> without this getting resolved, but I'm not sure what the best approach would 
> be. Maybe it should be replaced with a witness [major] version and witness 
> stack?
> 
> There is also draft code implementing [the consensus side of] this:
>https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
> 
> Thoughts? Anything I've overlooked / left missing that would be 
> uncontroversial and desirable? (Is any of this unexpectedly controversial for 
> some reason?)
> 
> Luke
> ___
> 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

[bitcoin-dev] Version 1 witness programs (first draft)

[Luke Dashjr via bitcoin-dev]

I've put together a first draft for what I hope to be a good next step for 
Segwit and Bitcoin scripting:
https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki

This introduces 5 key changes:

1. Minor versions for witnesses, inside the witness itself. Essentially the 
witness [major] version 1 simply indicates the witness commitment is SHA256d, 
and nothing more.

The remaining two are witness version 1.0 (major 1, minor 0):

2. As previously discussed, undefined opcodes immediately cause the script to 
exit with success, making future opcode softforks a lot more flexible.

3. If the final stack element is not exactly true or false, it is interpreted 
as a tail-call Script and executed. (Credit to Mark Friedenbach)

4. A new shorter fixed-length signature format, eliminating the need to guess 
the signature size in advance. All signatures are 65 bytes, unless a condition 
script is included (see #5).

5. The ability for signatures to commit to additional conditions, expressed in 
the form of a serialized Script in the signature itself. This would be useful 
in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the 
whole replay protection argument by introducing it early to Bitcoin before any 
further splits.

This last part is a big ugly right now: the signature must commit to the 
script interpreter flags and internal "sigversion", which basically serve the 
same purpose. The reason for this, is that otherwise someone could move the 
signature to a different context in an attempt to exploit differences in the 
various Script interpretation modes. I don't consider the BIP deployable 
without this getting resolved, but I'm not sure what the best approach would 
be. Maybe it should be replaced with a witness [major] version and witness 
stack?

There is also draft code implementing [the consensus side of] this:
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1

Thoughts? Anything I've overlooked / left missing that would be 
uncontroversial and desirable? (Is any of this unexpectedly controversial for 
some reason?)

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

[Aymeric Vitte via bitcoin-dev]

By "all of this" I meant the other issues that I mentioned too "would
everybody even here say that they feel very comfortable with their keys?
That if something happen to them there is no pb for the family or
trusted parties to retrieve the keys? That this process is secured in
case the trusted parties are finally untrusted? etc", I am extending the
problematic while the very basic concerns are still unsolved

Then I don't agree with the fact that users should not have the control
of their keys, but if I try to summarize, your suggestions probably lead
to the fact that the "wallet" part should be outside of bitcoin-qt, in a
simple offline module (assuming that you can trust the simple sw + the
os + the hw +the cpu, but ok, the pb is the same with a hw wallet),
which I think is a good idea

That's why I made a module some time ago, supposed to be "bitcoin
transactions made simple", you do your transactions offline, check them,
and send them to the network via qt, the web or other, it's working but
is not online on github because unfinished, and unfinished because
nothing is simple and it's unlikely that normal people can use this for
now, unfortunately you need to be a bit online to make your transaction,
fetch the output you want to spend or get the info, then associate the
right key, calculate the fees, that's not simple, that's why it's
different from a standard wallet, but probably a good way

Small sw a bit like a credit card finally, and people know they must not
disclose their code(s) in case they are asked on IRC or elsewhere



Le 30/09/2017 à 23:14, Jonas Schnelli via bitcoin-dev a écrit :
>> uhh do you apply this logic to the bitcoin-core wallet itself?
>> because clearly it generates keys and is intended to be used for signing
>> in online environments.  Lots of real-world use-cases depend on that today.
> The current Bitcoin Core wallet setup is not as ideal as it could be.
> An good example is, that the wallet and the full node (the p2p logic on 8333) 
> do share the same process (same memory space).
> AFAIK a lot of users use Core in watch-only mode and do the signing offline 
> (offline / through HWWs).
> Although, Core has currently no direct support for offline signing (expect 
> the rawtx API which are pretty expert-ish).
>
> The Core development process goes into that direction but it takes time due 
> to the strict and extremely important code quality insurance.
>
>> So if existing bitcoin-core wallet behavior is "ok" in any context then
>> how is it any worse for it to generate a key/address that will not be
>> stored in the internal wallet, and the user may do with it as they wish?
>> That is all my proposed RPC call does and unlike the existing RPC calls
>> it never even stores the key or address to disk.  It is also useful when
>> run on an offline hardware device, such as a laptop connected to an
>> non-networked printer.
> IMO we should make it better not worse.
> Paper wallets delude to do address reuse, the spending-procedure is unclear, 
> and very likely insecure.
> A quick photo-snapshot by an attack may result in a full compromised key.
> Printer buffers, etc. are also something to worry here.
>
>> Further, you mention the word trust.  That's the crux of the matter.  As
>> a full node operator, I've already placed my trust in the bitcoin-core
>> developers and dev/release practices.  Why exactly should I trust the
>> software in this minimal offline hardware/os you mention if it is NOT
>> bitcoin core?  And even if open source software, does that not at least
>> double my workload/expense to audit theat software in addition to
>> bitcoin-core?
> I think Bitcoin Core does a great job there. But not sure about other 
> security layers are outside of Core.
> Especially your operating system.
> The reason why we see a growing demand in hardware wallets is probably 
> because people no longer trust in current available operating systems as well 
> as current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).
>
>>> Users should have no way to view or export the private keys (expect for
>>> the seed backup).
>> I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
>> be removed from bitcoin-core to fit this paradigm?
> Yes. That actually something we are considering (especially if we would allow 
> BIP44 or other HD public key derivation forms).
> Also, we heard of "support sessions“ on IRC where attackers told victims they 
> must enter „dumpprivkey“ in the Console and give them the output in order „to 
> fix the problem“.
>
>> (Personally I actively avoid wallet software that takes this view and
>> treat users like children, preventing individuals direct access to the
>> keys for their own funds, which disempowers and sometimes results in a
>> form of lockin)
> I dislike that as well – in general. But I guess most users like 
> self-protection. Also, the user layer is attackable. If _you_ can access the 
> private-keys, an attacker can do also. What 

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

[Luke Dashjr via bitcoin-dev]

On Thursday 07 September 2017 12:38:55 AM Mark Friedenbach via bitcoin-dev 
wrote:
> Tail-call execution semantics
> BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368
> Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics

Just noticed this doesn't count sigops toward the block sigop limit.
Is that really safe? How long would it take, to verify a malicious block with 
only inputs such that there is nearly 4 MB of sigops?

(I do already understand the difficulty in supporting the sigop limit.)

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

[Jonas Schnelli via bitcoin-dev]

> 
> uhh do you apply this logic to the bitcoin-core wallet itself?
> because clearly it generates keys and is intended to be used for signing
> in online environments.  Lots of real-world use-cases depend on that today.

The current Bitcoin Core wallet setup is not as ideal as it could be.
An good example is, that the wallet and the full node (the p2p logic on 8333) 
do share the same process (same memory space).
AFAIK a lot of users use Core in watch-only mode and do the signing offline 
(offline / through HWWs).
Although, Core has currently no direct support for offline signing (expect the 
rawtx API which are pretty expert-ish).

The Core development process goes into that direction but it takes time due to 
the strict and extremely important code quality insurance.

> 
> So if existing bitcoin-core wallet behavior is "ok" in any context then
> how is it any worse for it to generate a key/address that will not be
> stored in the internal wallet, and the user may do with it as they wish?
> That is all my proposed RPC call does and unlike the existing RPC calls
> it never even stores the key or address to disk.  It is also useful when
> run on an offline hardware device, such as a laptop connected to an
> non-networked printer.

IMO we should make it better not worse.
Paper wallets delude to do address reuse, the spending-procedure is unclear, 
and very likely insecure.
A quick photo-snapshot by an attack may result in a full compromised key.
Printer buffers, etc. are also something to worry here.

> Further, you mention the word trust.  That's the crux of the matter.  As
> a full node operator, I've already placed my trust in the bitcoin-core
> developers and dev/release practices.  Why exactly should I trust the
> software in this minimal offline hardware/os you mention if it is NOT
> bitcoin core?  And even if open source software, does that not at least
> double my workload/expense to audit theat software in addition to
> bitcoin-core?

I think Bitcoin Core does a great job there. But not sure about other security 
layers are outside of Core.
Especially your operating system.
The reason why we see a growing demand in hardware wallets is probably because 
people no longer trust in current available operating systems as well as 
current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).

> 
>> Users should have no way to view or export the private keys (expect for
>> the seed backup).
> 
> I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
> be removed from bitcoin-core to fit this paradigm?

Yes. That actually something we are considering (especially if we would allow 
BIP44 or other HD public key derivation forms).
Also, we heard of "support sessions“ on IRC where attackers told victims they 
must enter „dumpprivkey“ in the Console and give them the output in order „to 
fix the problem“.

> (Personally I actively avoid wallet software that takes this view and
> treat users like children, preventing individuals direct access to the
> keys for their own funds, which disempowers and sometimes results in a
> form of lockin)

I dislike that as well – in general. But I guess most users like 
self-protection. Also, the user layer is attackable. If _you_ can access the 
private-keys, an attacker can do also. What most users want is a key-safe that 
only signs transactions which they could verify beforehand in a safe 
environment, and not a way to export private keys or something else that can 
touch the keys.


>> They should never leave the device over the channel used for the signing 
>> I/O. Users should have no way to view or export the private keys (expect for 
>> the seed backup). Backups should be encrypted (whoever finds the paper 
>> backup should need a second factor to decrypt) and the restore process 
>> should be footgun-safe (especially the lost-passphrase deadlock).
> 
> Is there really nothing existing yet to address all of this?

The answer is probably: No (for now). But working towards this should be the 
focus.


---
/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] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Andreas Schildbach via bitcoin-dev]

Generally agreed. This is why I nack'ed BIP72 years ago when we
discussed about standardization.

However, there are many ways to use BIP70 without BIP72. BIP72 is just a
kludge to biggy-pack the payment protocol onto BIP21. And also, as you
note, BIP72 can be easily fixed using a hash parameter.


On 09/29/2017 04:55 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev 
> wrote:
>> Andreas Schildbach wrote:
>>> This feels redundant to me; the payment protocol already has an
>>> expiration time.
>>
>> The BIP-70 payment protocol has significant overhead and most importantly 
>> requires back and forth. Emailing a bitcoin address or printing it on an 
>> invoice is much easier, so I would expect people to keep doing that.
> 
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment qr
> codes don't cryptographically commit to the identity of the merchant, which
> means a MITM attacker can redirect the payment if they can obtain a SSL cert
> that the wallet accepts.
> 
> For example, if I have a wallet on my phone and go to pay a
> merchant, a BIP-72 URI will look like the following(1):
> 
> 
> bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11=https://merchant.com/pay.php?h%3D2a8628fc2fbe
> 
> A wallet following the BIP-72 standard will "ignore the bitcoin
> address/amount/label/message in the URI and instead fetch a PaymentRequest
> message and then follow the payment protocol, as described in BIP 70."
> 
> So my phone will make a second connection - likely on a second network with a
> totally different set of MITM attackers - to https://merchant.com
> 
> In short, while my browser may have gotten the correct URL with the correct
> Bitcoin address, by using the payment protocol my wallet is discarding that
> information and giving MITM attackers a second chance at redirecting my 
> payment
> to them. That wallet is also likely using an off-the-shelf SSL library, with
> nothing other than an infrequently updated set of root certificates to use to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and frequently
> updated root certificate lists with proper revocation (see Symantec).
> 
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
> supports a h= parameter with a hash commitment to what the payment request
> should be, and will reject the MITM attacker if that hash doesn't match. But
> that's not actually in the standard itself, and as far as I can tell has never
> been made into a BIP.
> 
> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made
> to replace it.
> 
> 1) As an aside, it's absolutely hilarious that this URL taken straight from
>BIP-72 has the merchant using PHP, given its truly terrible track record 
> for
>security.
> 
> 
> 
> ___
> 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] Paper Wallet support in bitcoin-core

[Sjors Provoost via bitcoin-dev]

> Op 30 sep. 2017, om 06:49 heeft Jonas Schnelli via bitcoin-dev 
>  het volgende geschreven:
> 
>> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
>> Paper wallets are a safety hazard, insecure, and generally not advisable.
>> 
> 
> I have to agree with Luke.
> And I would also extend those concerns to BIP39 plaintext paper backups.
> 
> IMO, private keys should be generated and used (signing) on a trusted, 
> minimal and offline hardware/os. They should never leave the device over the 
> channel used for the signing I/O. Users should have no way to view or export 
> the private keys (expect for the seed backup). Backups should be encrypted 
> (whoever finds the paper backup should need a second factor to decrypt) and 
> the restore process should be footgun-safe (especially the lost-passphrase 
> deadlock).

I believe BIP39 does an excellent job at reducing the amount of bitcoin 
permanently lost. Stolen funds can at least in theory be retrieved at some 
future date. There's a trade-off between having a backup process that is secure 
and one that people actually use. I don't know the right answer, and tend to 
agree it's better left to individual wallets to decide.

Sjors


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] Paper Wallet support in bitcoin-core

[Dan Libby via bitcoin-dev]

On 09/29/2017 09:49 PM, Jonas Schnelli wrote:

> AFAIK, client implementations such as your proposal are off-topic for this ML.
> Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such 
> proposals.

ok, thanks.  I will take the proposal there.

> I have to agree with Luke.

thanks for your feedback.

> And I would also extend those concerns to BIP39 plaintext paper backups.
> 
> IMO, private keys should be generated and used (signing) on a trusted, 
> minimal and offline hardware/os.

uhh do you apply this logic to the bitcoin-core wallet itself?
because clearly it generates keys and is intended to be used for signing
in online environments.  Lots of real-world use-cases depend on that today.

So if existing bitcoin-core wallet behavior is "ok" in any context then
how is it any worse for it to generate a key/address that will not be
stored in the internal wallet, and the user may do with it as they wish?
 That is all my proposed RPC call does and unlike the existing RPC calls
it never even stores the key or address to disk.  It is also useful when
run on an offline hardware device, such as a laptop connected to an
non-networked printer.

Further, you mention the word trust.  That's the crux of the matter.  As
a full node operator, I've already placed my trust in the bitcoin-core
developers and dev/release practices.  Why exactly should I trust the
software in this minimal offline hardware/os you mention if it is NOT
bitcoin core?  And even if open source software, does that not at least
double my workload/expense to audit theat software in addition to
bitcoin-core?

> Users should have no way to view or export the private keys (expect for 
> the seed backup).

I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?

(Personally I actively avoid wallet software that takes this view and
treat users like children, preventing individuals direct access to the
keys for their own funds, which disempowers and sometimes results in a
form of lockin)

> Backups should be encrypted (whoever finds the paper backup should need a 
> second factor to decrypt) and the restore process should be footgun-safe 
> (especially the lost-passphrase deadlock).

This is more relevant to an application layer above the 2 RPC calls I
proposed. Encryption could be implemented (or not) by whichever software
calls the proposed RPC apis.  And further the APIs can be called for
use-cases beyond just paper wallets.



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

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

[Adam Ritter via bitcoin-dev]

I'm happy to help with secure paper wallet support. Bitcoin core is already
used offline by the Glacier Protocol, though there's no official offline
support.

I extended the Glacier Protocol with an extra password derivation function.
I used Scrypt with 2GB RAM requirement, though maybe using Argon2id V1.3
would be better.

Also I'd prefer using BIP45 Multisig HD Wallets over a multisig address, as
in the current Glacier Protocol implementation the redeem key is public
because of the test withdrawal transaction.

On Sat, Sep 30, 2017 at 6:49 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > Hi,
> >
> > I'm writing to suggest and discuss the addition of paper wallet
> > functionality in bitcoin-core software, starting with a single new RPC
> > call: genExternalAddress [type].
> >
>
> AFAIK, client implementations such as your proposal are off-topic for this
> ML.
> Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for
> such proposals.
>
>
> > On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> > Paper wallets are a safety hazard, insecure, and generally not advisable.
> >
>
> I have to agree with Luke.
> And I would also extend those concerns to BIP39 plaintext paper backups.
>
> IMO, private keys should be generated and used (signing) on a trusted,
> minimal and offline hardware/os. They should never leave the device over
> the channel used for the signing I/O. Users should have no way to view or
> export the private keys (expect for the seed backup). Backups should be
> encrypted (whoever finds the paper backup should need a second factor to
> decrypt) and the restore process should be footgun-safe (especially the
> lost-passphrase deadlock).
>
>
> /jonas
>
> ___
> 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] Rebatable fees & incentive-safe fee markets

[Gregory Maxwell via bitcoin-dev]

On Sat, Sep 30, 2017 at 3:55 AM, Jorge Timón via bitcoin-dev
 wrote:
> Gmaxwell I think what's new is that in this case, with a single tx you would
> take out all txs with fee below 1 btc. With current rules, you would only
> remove enoguh txs for that one to fit, not empty the whole block and mine
> only a block with that single tx.

I think this is not relevant: By paying the same amount you can delay
the same transactions today.

The difference is that your 'attack' wastes less capacity-- it can be
a simple 150 weight txn rather than a collection that add up to almost
4 million weight; but it costs exactly the same.  To the extent that
this difference matters at all, I think it's an improvement.

The only argument that I see for it not being one is that it's easier
to do accidentally.  But part of the purpose of this alternative
market is to achieve an equilibrium other than the ultrabloating one;
so yes, you're going to find outcomes where the blocks are not
maximally full.

I wonder how the economics would respond if there is a PI controller
on the maximum size, so that 'lost space' in single blocks with bogon
fee transactions could be recovered if doing so didn't change the
medium timescale total. I think the paper's analysis assumes there is
no limit, but that is impractical for technical reasons (e.g. making
it impossible to budget communications and storage capacity for
nodes...).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev