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

[Jonas Schnelli via bitcoin-dev]

> 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


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] Rebatable fees & incentive-safe fee markets

[Jorge Timón via bitcoin-dev]

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.

On 30 Sep 2017 5:53 am, "Jorge Timón"  wrote:

> I really don't see how this "outlier behaviour" can be prevented. I think
> it would be the norm even with your proposed "fix". Perhaps I'm missing
> something too.
>
> On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is correct. Under assumptions of a continuous mempool model however
>> this should be considered the outlier behavior, other than a little bit of
>> empty space at the end, now and then. A maximum fee rate calculated as a
>> filter over past block rates could constrain this outlier behavior from
>> ever happening too.
>>
>> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna 
>> wrote:
>> >
>> > Maybe I'm getting this wrong but wouldn't this scheme imply that a
>> miner is incentivized to limit the amount of transactions in a block to
>> capture the maximum fee of the ones included?
>> >
>> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
>> If I were to submit a transaction paying 1 btc in maximal money fees, then
>> the miner would be incentivized to include my transaction alone to avoid
>> that lower fee paying transactions reduce the amount of fees he can earn
>> from my transaction alone. This would mean that I could literally clog the
>> network by paying 1btc every ten minutes.
>> >
>> > Am I missing something?
>> >
>> > Daniele
>> ___
>> 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 Fri, Sep 29, 2017 at 10:43 AM, Daniele Pinna via bitcoin-dev
 wrote:
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If I
> were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.

If I'm not mistaken that is is nothing new or interesting: You can
delay some transaction by paying more than it offered by every block
you delay it from. E.g. if the next full block would pay 0.8 BTC in
fees, you just need to make transactions paying more than that. But
you'll pay it for each delay and the people you push out only pay once
(when they are successful), so it gets awfully expensive fast.

(Arguably the monopoly price model is better because outbidding party
doesn't need to bloat the chain to do their thing; arguable its
somewhat worse because its harder to do by accident.)

My thought on this was the same as PT's initial: miners and users can
arrange OOB payments (and/or coinjoin rebates) and bypass this. I
don't see why it wouldn't be in their individual best interest to do
so, and if they do that would likely be a centralizing effect.
___
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]

Anyway, I'll count that as a NAK from Luke.  what do others here think?

I wish to guage if I were to submit a functional pull request for one or
both of these RPC calls, if would it be likely to be accepted.

If so I'm happy to contribute my time, otherwise...

On 09/29/2017 03:13 PM, Dan Libby wrote:
> It seems to me that the same statement can be made for *any* key storage
> mechanism depending on one's security/threat model, including
> bitcoin-core's internal wallet storage.  There certainly are cases where
> a paper (or metal) offline wallet makes a lot of sense, particularly for
> long-term offline storage... something that electronic media pretty much
> sucks at.
> 
> Though if you care to elaborate I'd be interested to learn of your
> specific critiques, if you have any beyond the generic statements here:
> https://en.bitcoin.it/wiki/Paper_wallet
> 
> Regardless, the APIs I've proposed have uses beyond paper wallets.  It
> can also be used by third party wallets, or any number of reasons that
> individuals or devs might have to generate keys.
> 
> 
> 
> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
>> Paper wallets are a safety hazard, insecure, and generally not advisable.
>>
>>
>> On Friday 29 September 2017 5:29:17 PM Dan Libby via bitcoin-dev 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].
>>>
>>> -- rationale --
>>>
>>> bitcoin-core is the most trusted and most secure bitcoin implementation.
>>>
>>> Yet today (unless I've missed something) paper wallet generation
>>> requires use of third party software, or even a website such as
>>> bitaddress.org.  This requires placing trust in an additional body of
>>> code from a less-trusted and less peer-reviewed source.  Ideally, one
>>> would personally audit this code for one's self, but in practice that
>>> rarely happens.
>>>
>>> In the case of a website generator, the code must be audited again each
>>> time it is downloaded.  I cannot in good faith recommend to anyone to
>>> use such third party tools for wallet generation.
>>>
>>> I *would* recommend for others to trust a paper wallet that uses
>>> address(es) generated by bitcoin-core itself.
>>>
>>> At least for me, this requirement to audit (or implicitly trust) a
>>> secondary body of bitcoin code places an additional hurdle or
>>> disincentive on the use of paper wallets, or indeed private keys
>>> generated outside of bitcoin-core for any purpose.
>>>
>>> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
>>> or getrawchangeaddress for this purpose, because the associated private
>>> keys are added to the bitcoin-core wallet and cannot be removed... or in
>>> the case of hd-wallets are deterministically derived.
>>>
>>> As such, I'm throwing out the following half-baked proposal as a
>>> starting point for discussion:
>>>
>>>
>>> -
>>>
>>> genexternaladdress ( "type" )
>>>
>>> Returns a new Bitcoin address and private key for receiving
>>> payments. This key/address is intended for external usage such as
>>> paper wallets and will not be used by internal wallet nor written to
>>> disk.
>>>
>>> Arguments:
>>> 1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
>>> default: p2sh-p2wpkh
>>>
>>> Result:
>>> {
>>> "privKey"(string) The private key in wif format.
>>> "address"(string) The address in p2pkh or p2sh-p2wpkh
>>>   format.
>>> }
>>>
>>> Examples:
>>> > bitcoin-cli genexternaladdress
>>>
>>> 
>>>
>>> This API is simple to implement and use.  It provides enough
>>> functionality for any moderately skilled developer to create their own
>>> paper wallet creation script using any scripting language, or even for
>>> advanced users to perform using bitcoin-cli or debug console.
>>>
>>> If consensus here is in favor of including such an API, I will be happy
>>> to take a crack at implementing it and submitting a pull request.
>>>
>>> If anyone has reasons why it is a BAD IDEA to include such an RPC call
>>> in bitcoind, I'm curious to hear it.
>>>
>>> Also, I welcome suggestions for a better name, or maybe there could be
>>> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
>>> instead.
>>>
>>>
>>>  further work 
>>>
>>>
>>> Further steps could be taken in this direction, but are not necessary
>>> for a useful first-step.  In particular:
>>>
>>> 1. an RPC call to generate an external HD wallet seed.
>>> 2. an RPC call to generate N key/address pairs from a given seed.
>>> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
>>> generation (and printing?) for end-users, complete with nice graphics,
>>> qr codes, etc.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> bitcoin-dev 

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

[Sjors Provoost via bitcoin-dev]

A 12-24 word BIP39 mnemonic is easy to write down and has the benefit of not 
needing to trust a printer.

However without also supporting BIP43/44/49 this would probably cause 
confusion. Supporting these would be a larger project as well. Although widely 
used, the standards are still Proposed / Draft. There's  might be room for 
improvement [0].

Sjors

[0] https://github.com/satoshilabs/slips/issues/103

> Op 29 sep. 2017, om 20:07 heeft Andrew Johnson via bitcoin-dev 
>  het volgende geschreven:
> 
> One consideration of exposing this in QT is that it may encourage users to 
> generate paper wallets(which are generally used and recommended for cold 
> storage) from online machines, rendering them moreso lukewarm rather than 
> cold, since the keys weren't generated in an air-gapped environment.  When 
> using bitaddress.org  locally(we are all only using 
> it locally and not directly from the online webpage, right? ;) ) you've at 
> least made the effort to seek out the repo, clone it locally, and use it on 
> an offline machine and not retain any data from that session.
> 
> If we include this as a function in the reference implementation, how many 
> people are going to be making paper wallets with the intention of cold 
> storage on a machine that's potentially compromised?  As adoption(hopefully) 
> continues to increase the number of less than tech savvy people using bitcoin 
> will increase.
> 
> I'd suggest that any UI in QT include some sort of a modal dialog that 
> informs the user that this is not a secure cold storage address unless it was 
> created on an offline machine and printed on a non-networked printer, and the 
> prompt must be accepted and dismissed before the wallet will provide the 
> requested keys.
> 
> 
> On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev 
>  > 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].
> 
> -- rationale --
> 
> bitcoin-core is the most trusted and most secure bitcoin implementation.
> 
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org .  This requires placing trust in an 
> additional body of
> code from a less-trusted and less peer-reviewed source.  Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
> 
> In the case of a website generator, the code must be audited again each
> time it is downloaded.  I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
> 
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
> 
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
> 
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.
> 
> As such, I'm throwing out the following half-baked proposal as a
> starting point for discussion:
> 
> 
> -
> 
> genexternaladdress ( "type" )
> 
> Returns a new Bitcoin address and private key for receiving
> payments. This key/address is intended for external usage such as
> paper wallets and will not be used by internal wallet nor written to
> disk.
> 
> Arguments:
> 1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
> default: p2sh-p2wpkh
> 
> Result:
> {
> "privKey"(string) The private key in wif format.
> "address"(string) The address in p2pkh or p2sh-p2wpkh
>   format.
> }
> 
> 
> Examples:
> > bitcoin-cli genexternaladdress
> 
> 
> 
> 
> This API is simple to implement and use.  It provides enough
> functionality for any moderately skilled developer to create their own
> paper wallet creation script using any scripting language, or even for
> advanced users to perform using bitcoin-cli or debug console.
> 
> If consensus here is in favor of including such an API, I will be happy
> to take a crack at implementing it and submitting a pull request.
> 
> If anyone has reasons why it is a BAD IDEA to include such an RPC call
> in bitcoind, I'm curious to hear it.
> 
> Also, I welcome suggestions for a better name, or maybe there could be
> some improvements to the param(s), such as 

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

[Dan Libby via bitcoin-dev]

It seems to me that the same statement can be made for *any* key storage
mechanism depending on one's security/threat model, including
bitcoin-core's internal wallet storage.  There certainly are cases where
a paper (or metal) offline wallet makes a lot of sense, particularly for
long-term offline storage... something that electronic media pretty much
sucks at.

Though if you care to elaborate I'd be interested to learn of your
specific critiques, if you have any beyond the generic statements here:
https://en.bitcoin.it/wiki/Paper_wallet

Regardless, the APIs I've proposed have uses beyond paper wallets.  It
can also be used by third party wallets, or any number of reasons that
individuals or devs might have to generate keys.



On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> Paper wallets are a safety hazard, insecure, and generally not advisable.
> 
> 
> On Friday 29 September 2017 5:29:17 PM Dan Libby via bitcoin-dev 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].
>>
>> -- rationale --
>>
>> bitcoin-core is the most trusted and most secure bitcoin implementation.
>>
>> Yet today (unless I've missed something) paper wallet generation
>> requires use of third party software, or even a website such as
>> bitaddress.org.  This requires placing trust in an additional body of
>> code from a less-trusted and less peer-reviewed source.  Ideally, one
>> would personally audit this code for one's self, but in practice that
>> rarely happens.
>>
>> In the case of a website generator, the code must be audited again each
>> time it is downloaded.  I cannot in good faith recommend to anyone to
>> use such third party tools for wallet generation.
>>
>> I *would* recommend for others to trust a paper wallet that uses
>> address(es) generated by bitcoin-core itself.
>>
>> At least for me, this requirement to audit (or implicitly trust) a
>> secondary body of bitcoin code places an additional hurdle or
>> disincentive on the use of paper wallets, or indeed private keys
>> generated outside of bitcoin-core for any purpose.
>>
>> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
>> or getrawchangeaddress for this purpose, because the associated private
>> keys are added to the bitcoin-core wallet and cannot be removed... or in
>> the case of hd-wallets are deterministically derived.
>>
>> As such, I'm throwing out the following half-baked proposal as a
>> starting point for discussion:
>>
>>
>> -
>>
>> genexternaladdress ( "type" )
>>
>> Returns a new Bitcoin address and private key for receiving
>> payments. This key/address is intended for external usage such as
>> paper wallets and will not be used by internal wallet nor written to
>> disk.
>>
>> Arguments:
>> 1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
>> default: p2sh-p2wpkh
>>
>> Result:
>> {
>> "privKey"(string) The private key in wif format.
>> "address"(string) The address in p2pkh or p2sh-p2wpkh
>>   format.
>> }
>>
>> Examples:
>> > bitcoin-cli genexternaladdress
>>
>> 
>>
>> This API is simple to implement and use.  It provides enough
>> functionality for any moderately skilled developer to create their own
>> paper wallet creation script using any scripting language, or even for
>> advanced users to perform using bitcoin-cli or debug console.
>>
>> If consensus here is in favor of including such an API, I will be happy
>> to take a crack at implementing it and submitting a pull request.
>>
>> If anyone has reasons why it is a BAD IDEA to include such an RPC call
>> in bitcoind, I'm curious to hear it.
>>
>> Also, I welcome suggestions for a better name, or maybe there could be
>> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
>> instead.
>>
>>
>>  further work 
>>
>>
>> Further steps could be taken in this direction, but are not necessary
>> for a useful first-step.  In particular:
>>
>> 1. an RPC call to generate an external HD wallet seed.
>> 2. an RPC call to generate N key/address pairs from a given seed.
>> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
>> generation (and printing?) for end-users, complete with nice graphics,
>> qr codes, etc.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Dan Libby

Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359
___
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]

One additional thought:

It should be useful to also define a multi-sig generation RPC.

This would facilitate multi-sig paper wallets stored in different
physical locations, amongst other use-cases.

Something like:

-

genexternalmultisigaddress ( "m", "n", "type" )

Returns a new Bitcoin address and n number of private key(s).
This address and associated keys is intended for external usage such
as paper wallets and will not be used by internal wallet nor written
to disk.

Arguments:
1. "m"   (integer, required) The number of required signers
 to send funds.
2. "n"   (integer, required) The number of authorized
 signers
3. "type"(string, optional)  one of: p2sh-p2pkh, p2sh-p2wpkh
 default: p2sh-p2wpkh

Result:
{
"address",   (string) The address in p2pkh or p2sh-p2wpkh
  format.
"privkeys": [
(string) The private key in wif format.
]
}


Examples:
> bitcoin-cli genexternalmultisigaddress 2 3

-



On 09/29/2017 10:29 AM, Dan Libby via bitcoin-dev 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].
> 
> -- rationale --
> 
> bitcoin-core is the most trusted and most secure bitcoin implementation.
> 
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org.  This requires placing trust in an additional body of
> code from a less-trusted and less peer-reviewed source.  Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
> 
> In the case of a website generator, the code must be audited again each
> time it is downloaded.  I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
> 
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
> 
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
> 
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.
___
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 11:07 AM, Andrew Johnson wrote:
> One consideration of exposing this in QT is that it may encourage users
> to generate paper wallets(which are generally used and recommended for
> cold storage) from online machines, rendering them moreso lukewarm
> rather than cold, since the keys weren't generated in an air-gapped
> environment.  

true that.  Though there's nothing stopping a diligent person from
installing bitcoin-core on a dedicated offline machine.  The blockchain
wouldn't need to be synced at all for key generation purposes.

> When using bitaddress.org 
> locally(we /are /all only using it locally and not directly from the
> online webpage, right? ;) ) you've at least made the effort to seek out
> the repo, clone it locally, and use it on an offline machine and not
> retain any data from that session.

yeah, so I noticed this issue about Paper Wallet generation not being
possible with bitcoin-core exactly because I was recommending to a
non-technical user to use paper wallets, but then I also had to point
out that really bitaddress code should be downloaded, audited, etc,
before use.  Things that are actually impossible for a non-technical user.

So I figured that instead I would make a simple script for them that
would use bitcoin-core to generate the addresses... and that's when it
dawned on me that it won't actually work with present day RPCs that are
all tied to internal wallet.

hence, this proposal.

> I'd suggest that any UI in QT include some sort of a modal dialog that
> informs the user that this is not a secure cold storage address unless
> it was created on an offline machine and printed on a non-networked
> printer, and the prompt must be accepted and dismissed before the wallet
> will provide the requested keys.

yes, agreed.
___
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

[Andrew Johnson via bitcoin-dev]

One consideration of exposing this in QT is that it may encourage users to
generate paper wallets(which are generally used and recommended for cold
storage) from online machines, rendering them moreso lukewarm rather than
cold, since the keys weren't generated in an air-gapped environment.  When
using bitaddress.org locally(we *are *all only using it locally and not
directly from the online webpage, right? ;) ) you've at least made the
effort to seek out the repo, clone it locally, and use it on an offline
machine and not retain any data from that session.

If we include this as a function in the reference implementation, how many
people are going to be making paper wallets with the intention of cold
storage on a machine that's potentially compromised?  As
adoption(hopefully) continues to increase the number of less than tech
savvy people using bitcoin will increase.

I'd suggest that any UI in QT include some sort of a modal dialog that
informs the user that this is not a secure cold storage address unless it
was created on an offline machine and printed on a non-networked printer,
and the prompt must be accepted and dismissed before the wallet will
provide the requested keys.


On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby 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].
>
> -- rationale --
>
> bitcoin-core is the most trusted and most secure bitcoin implementation.
>
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org.  This requires placing trust in an additional body of
> code from a less-trusted and less peer-reviewed source.  Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
>
> In the case of a website generator, the code must be audited again each
> time it is downloaded.  I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
>
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
>
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
>
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.
>
> As such, I'm throwing out the following half-baked proposal as a
> starting point for discussion:
>
>
> -
>
> genexternaladdress ( "type" )
>
> Returns a new Bitcoin address and private key for receiving
> payments. This key/address is intended for external usage such as
> paper wallets and will not be used by internal wallet nor written to
> disk.
>
> Arguments:
> 1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
> default: p2sh-p2wpkh
>
> Result:
> {
> "privKey"(string) The private key in wif format.
> "address"(string) The address in p2pkh or p2sh-p2wpkh
>   format.
> }
>
>
> Examples:
> > bitcoin-cli genexternaladdress
>
>
> 
>
> This API is simple to implement and use.  It provides enough
> functionality for any moderately skilled developer to create their own
> paper wallet creation script using any scripting language, or even for
> advanced users to perform using bitcoin-cli or debug console.
>
> If consensus here is in favor of including such an API, I will be happy
> to take a crack at implementing it and submitting a pull request.
>
> If anyone has reasons why it is a BAD IDEA to include such an RPC call
> in bitcoind, I'm curious to hear it.
>
> Also, I welcome suggestions for a better name, or maybe there could be
> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
> instead.
>
>
>  further work 
>
>
> Further steps could be taken in this direction, but are not necessary
> for a useful first-step.  In particular:
>
> 1. an RPC call to generate an external HD wallet seed.
> 2. an RPC call to generate N key/address pairs from a given seed.
> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
> generation (and printing?) for end-users, complete with nice graphics,
> qr codes, etc.
>
>
>
>
>
>
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Andrew Johnson

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

[Aymeric Vitte via bitcoin-dev]

Everybody knows that https is broken and insecure, and everybody knows
that it's still better than nothing

Just reacting here because there is worse: you are quoting Kraken, did
not check for Coinbase but Kraken is proxying all of its https traffic
via Cloudflare, including the API traffic

This is crazy but that's how things are, that's what everybody is doing,
that's what we have

The https principles are obsolete, the concept of certificates tied to a
domain is a complete stupidity, because there are no concept of domains
in bitcoin for example (and webrtc, Tor, bittorrent, p2p systems, etc)
and should evolve to something like certificates tied to an entityID
managed by something like a blockchain system, and not a stupid domain or CA

Therefore specifying things for bitcoin à la web is not a good idea,
browsers can do far better than standard/usual web, and the "like
everybody is doing" argument is not a valid one


Le 29/09/2017 à 15:14, Tomas via bitcoin-dev a écrit :
> On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
>> 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.
> By that reasoning, we also shouldn't go to https://coinbase.com or
> https://kraken.com to buy any bitcoins? As a MITM can redirect the site
> _if_ they obtain the coinbase or kraken certificate.
>
> Obviously, HTTPS is secured under the assumption that certificates are
> secure.  
>
> Using the payment protocol simply means paying to a secure endpoint (eg
> https://tomasvdw.nl/pay) instead of an address.
>
>>  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).
> So we should not use HTTPS for secure transfer because the
> implementation may not be good enough? This incorrectly conflates
> implementation with specification. There is nothing stopping a developer
> from using a proper implementation.
>
>> 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.
> Currently it is widely used by merchants, but not yet for light clients
> _receiving_ money. If it becomes more wide spread,   it offers a range
> of advantages as  the bitcoin-address of the URI can and should be
> deprecated (made impossible with "h="). A payment address just becomes a
> secure endpoint.
>
> This means no more address reuse is possible. Also, it drops the need
> for mempool synchronization among non-miners, solely as a "notification"
> mechanism. In addition it means light clients know exactly when a
> transaction is coming in, so they can efficiently rely on client-side
> filtering a small set of blocks, improving their privacy.
>
> In my opinion, the payment protocol is key to scaling.
>
>> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
>> made
>> to replace it.
> Sorry, but maybe you  could explain better how secure communication over
> HTTPS is "very dangerous"? I think some websites would like to know :)
>
> Tomas van der Wansem
> bitcrust
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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

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

[Dan Libby via bitcoin-dev]

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].

-- rationale --

bitcoin-core is the most trusted and most secure bitcoin implementation.

Yet today (unless I've missed something) paper wallet generation
requires use of third party software, or even a website such as
bitaddress.org.  This requires placing trust in an additional body of
code from a less-trusted and less peer-reviewed source.  Ideally, one
would personally audit this code for one's self, but in practice that
rarely happens.

In the case of a website generator, the code must be audited again each
time it is downloaded.  I cannot in good faith recommend to anyone to
use such third party tools for wallet generation.

I *would* recommend for others to trust a paper wallet that uses
address(es) generated by bitcoin-core itself.

At least for me, this requirement to audit (or implicitly trust) a
secondary body of bitcoin code places an additional hurdle or
disincentive on the use of paper wallets, or indeed private keys
generated outside of bitcoin-core for any purpose.

Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
or getrawchangeaddress for this purpose, because the associated private
keys are added to the bitcoin-core wallet and cannot be removed... or in
the case of hd-wallets are deterministically derived.

As such, I'm throwing out the following half-baked proposal as a
starting point for discussion:


-

genexternaladdress ( "type" )

Returns a new Bitcoin address and private key for receiving
payments. This key/address is intended for external usage such as
paper wallets and will not be used by internal wallet nor written to
disk.

Arguments:
1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh

Result:
{
"privKey"(string) The private key in wif format.
"address"(string) The address in p2pkh or p2sh-p2wpkh
  format.
}


Examples:
> bitcoin-cli genexternaladdress




This API is simple to implement and use.  It provides enough
functionality for any moderately skilled developer to create their own
paper wallet creation script using any scripting language, or even for
advanced users to perform using bitcoin-cli or debug console.

If consensus here is in favor of including such an API, I will be happy
to take a crack at implementing it and submitting a pull request.

If anyone has reasons why it is a BAD IDEA to include such an RPC call
in bitcoind, I'm curious to hear it.

Also, I welcome suggestions for a better name, or maybe there could be
some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
instead.


 further work 


Further steps could be taken in this direction, but are not necessary
for a useful first-step.  In particular:

1. an RPC call to generate an external HD wallet seed.
2. an RPC call to generate N key/address pairs from a given seed.
3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
generation (and printing?) for end-users, complete with nice graphics,
qr codes, etc.










___
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

[Tomas via bitcoin-dev]

On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
> 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.

By that reasoning, we also shouldn't go to https://coinbase.com or
https://kraken.com to buy any bitcoins? As a MITM can redirect the site
_if_ they obtain the coinbase or kraken certificate.

Obviously, HTTPS is secured under the assumption that certificates are
secure.  

Using the payment protocol simply means paying to a secure endpoint (eg
https://tomasvdw.nl/pay) instead of an address.

>  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).

So we should not use HTTPS for secure transfer because the
implementation may not be good enough? This incorrectly conflates
implementation with specification. There is nothing stopping a developer
from using a proper implementation.

> 
> 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.

Currently it is widely used by merchants, but not yet for light clients
_receiving_ money. If it becomes more wide spread,   it offers a range
of advantages as  the bitcoin-address of the URI can and should be
deprecated (made impossible with "h="). A payment address just becomes a
secure endpoint.

This means no more address reuse is possible. Also, it drops the need
for mempool synchronization among non-miners, solely as a "notification"
mechanism. In addition it means light clients know exactly when a
transaction is coming in, so they can efficiently rely on client-side
filtering a small set of blocks, improving their privacy.

In my opinion, the payment protocol is key to scaling.

> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
> made
> to replace it.

Sorry, but maybe you  could explain better how secure communication over
HTTPS is "very dangerous"? I think some websites would like to know :)

Tomas van der Wansem
bitcrust
___
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

[Mark Friedenbach via bitcoin-dev]

This is correct. Under assumptions of a continuous mempool model however this 
should be considered the outlier behavior, other than a little bit of empty 
space at the end, now and then. A maximum fee rate calculated as a filter over 
past block rates could constrain this outlier behavior from ever happening too.

> On Sep 29, 2017, at 3:43 AM, Daniele Pinna  wrote:
> 
> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is 
> incentivized to limit the amount of transactions in a block to capture the 
> maximum fee of the ones included?
> 
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If I 
> were to submit a transaction paying 1 btc in maximal money fees, then the 
> miner would be incentivized to include my transaction alone to avoid that 
> lower fee paying transactions reduce the amount of fees he can earn from my 
> transaction alone. This would mean that I could literally clog the network by 
> paying 1btc every ten minutes.
> 
> Am I missing something?
> 
> Daniele 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Peter Todd via bitcoin-dev]

On Fri, Sep 29, 2017 at 02:45:32PM +0200, Andreas Schildbach via bitcoin-dev 
wrote:
> On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote:
> 
> >>> I'm well aware. As the payment protocol hasn't caught on - and doesn't 
> >>> fully
> >>> overlap all the usecases that addresses do anyway - I think we should 
> >>> consider
> >>> bringing this important feature to Bitcoin addresses too.
> >>
> >> Hasn't caught on? It is used for virtually all merchant transactions,
> >> plus person to person transactions between Bitcoin Wallet users.
> > 
> > "Virtually all"?
> > 
> > I regularly pay with Bitcoin, and I haven't seen the payment protocol used 
> > in
> > ages.
> 
> I regularly pay with Bitcoin, and I haven't seen the payment protocol
> not being in use in ages.
> 
> > Can you name some users of it?
> 
> 15+ Mio Coinbase users

Lol, interesting mistake I made w/ Coinbase: my mobile wallets are all setup in
ways that don't support the payment protocol w/ Coinbase, probably because come
to think of it they were (still are?) rejecting payment protocol requests over
proxies and Tor. And on my desktop setups payment protocol URLs don't work for
various reasons, and I'd forgotten I'd manually disabled them ages ago.

Just checked and Bitfinex, BTCC, and Shapeshift all don't seem to use the
payment protocol.

Other than BitPay and Coinbase, do you have an example of a service supporting
the payment protocol?

> ~10 Mio BitPay users
> 8 Mio Bitcoin Wallet users
> Plus Bitcoin Core, Electrum, etc (sorry no numbers)
> 
> Probably the only usecase for naked addresses is paper wallets, right?
> I'm not sure if paper wallets can expire.

User-to-user payments pretty much always use naked addresses.

-- 
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] Rebatable fees & incentive-safe fee markets

[Alex Morcos via bitcoin-dev]

I had the same concern, or a miner could fill the remainder of the block
with their own high fee paying transactions if blocks were required to be
full.

On Fri, Sep 29, 2017 at 7:55 AM Daniele Pinna via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If
> I were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele
> ___
> 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] Address expiration times should be added to BIP-173

[Andreas Schildbach via bitcoin-dev]

On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote:

>>> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
>>> overlap all the usecases that addresses do anyway - I think we should 
>>> consider
>>> bringing this important feature to Bitcoin addresses too.
>>
>> Hasn't caught on? It is used for virtually all merchant transactions,
>> plus person to person transactions between Bitcoin Wallet users.
> 
> "Virtually all"?
> 
> I regularly pay with Bitcoin, and I haven't seen the payment protocol used in
> ages.

I regularly pay with Bitcoin, and I haven't seen the payment protocol
not being in use in ages.

> Can you name some users of it?

15+ Mio Coinbase users
~10 Mio BitPay users
8 Mio Bitcoin Wallet users
Plus Bitcoin Core, Electrum, etc (sorry no numbers)

Probably the only usecase for naked addresses is paper wallets, right?
I'm not sure if paper wallets can expire.

___
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

[Omar Shibli via bitcoin-dev]

Thank you for sharing, this is indefinitely valuable.

I think that risk could be mitigated if instead of ignoring the bitcoin
address/amount/..., the wallet use this address for integrity checks.
Furthermore, I think this BIP could be improved by actually applying the
homomorphic property and deriving the bitcoin address from merchant pub key
and the hash itself. that would allow both the customer and merchant to be
able generate address independently.

On Fri, Sep 29, 2017 at 5:55 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> ___
> 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] Address expiration times should be added to BIP-173

[Sjors Provoost via bitcoin-dev]

Op 29 sep. 2017, om 05:18 heeft Peter Todd  het volgende 
geschreven:
> 
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev 
> wrote:
>> Peter Todd wrote:
>> Perhaps outside the scope of BIP173, but what about baking it into the 
>> protocol? That way a transaction that's sent too late, simply won't get 
>> confirmed. This removes the need for refund logic or asking a customer to 
>> pay just a few extra cents. You could also disallow a second payment.
>> 
>> Two downsides I can think of:
>> * privacy, as differences in expiration policy would be visible on chain
>> * miners might be able to game it in their interaction with brokers
> 
> This has been discussed many times before; there are *severe* downsides to
> making it possible for transactions to become invalid after the fact.

I've heard of that general principe, but I'm having trouble finding a good 
resource that describes it more precisely.

Is it a peer to peer or mempool issue? E.g a transaction might be accepted into 
the mempool and relayed at one point in time and suddenly become invalid before 
they're committed to a block? Or that a node receives a transaction, thinks 
it's invalid because the address already expired, but then receives an older 
block later which contains that transaction?

Once in a block, I don't see how it would become invalid later. But as a miner 
tries to find a block and updates the timestamp, they would have toss the 
transaction out at some point.

Another objection I can think of, is that the soft fork introducing this change 
would have to use a transaction type that's non-standard at the moment. This 
would make it difficult for a non-upgraded node to broadcast such a 
transaction. The recipient would have to know if the sender has upgraded before 
communicating an address, which sounds impractical at best.

>>> Being just an expiration time, seconds-level resolution is unnecessary, and
>>> may give the wrong impression. I'd suggest either:
>>> 
>>> 1) Hour resolution - 2^24 hours = 1914 years
>>> 2) Month resolution - 2^16 months = 5458 years
>> 
>> So that's 4.8 characters for hours, or 3.2 for years, plus checksum space? 
>> The shorter the better. Perhaps one or two bits can be used to specify an 
>> exponent; a large range seems more useful than high precision. For instance 
>> a merchant doesn't care if the customer pays within 10:00:00 minutes or 
>> 10:00:01 minutes and you wouldn't care if your address is valid 50 years or 
>> 50 years and 3 minutes. This point may be mute if minute level resolution is 
>> not practical.
> 
> Note that "large range" is a requirement driven by the fact that expiry times
> will inevitably be specified absolutely, not relatively: when the range runs
> out you need to upgrade the standard. Better to use another character and use 
> a
> range that won't run out any time soon.
> 
> This wouldn't create a need for more checksum space.

You're right, relative time makes no sense. So it would take 5 characters to 
get roughly two minute resolution that lasts for 100 years.

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] Rebatable fees & incentive-safe fee markets

[Daniele Pinna via bitcoin-dev]

Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is
incentivized to limit the amount of transactions in a block to capture the
maximum fee of the ones included?

As an example, mined blocks currently carry ~0.8 btc in fees right now. If
I were to submit a transaction paying 1 btc in maximal money fees, then the
miner would be incentivized to include my transaction alone to avoid that
lower fee paying transactions reduce the amount of fees he can earn from my
transaction alone. This would mean that I could literally clog the network
by paying 1btc every ten minutes.

Am I missing something?

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

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Andreas Schildbach via bitcoin-dev]

On 09/29/2017 03:45 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 12:09:59PM +0200, Andreas Schildbach via bitcoin-dev 
> wrote:
>> This feels redundant to me; the payment protocol already has an
>> expiration time.
> 
> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
> overlap all the usecases that addresses do anyway - I think we should consider
> bringing this important feature to Bitcoin addresses too.

Hasn't caught on? It is used for virtually all merchant transactions,
plus person to person transactions between Bitcoin Wallet users.


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