> 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
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"
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 assu
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 t
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 wr
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 /
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
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 Bit
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 we
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
us
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 i
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 some
On Fri, Sep 29, 2017 at 12:45 PM, Andreas Schildbach via bitcoin-dev
wrote:
> 15+ Mio Coinbase users
Who's payment protocol SSL cert was expired for months without even
generating a post on reddit. Not exactly convincing there.
The fact that someone supports it doesn't mean its being used.
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 S
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 eve
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 t
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
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.
>>
>> Has
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 deri
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 se
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
On Fri, Sep 29, 2017 at 10:44:11AM +0200, Andreas Schildbach via bitcoin-dev
wrote:
> 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
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 - a
23 matches
Mail list logo
