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

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 -

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

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

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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

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

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

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

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

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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

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

> 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

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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"

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 /

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

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

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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