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 par
>
> 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
I am not sure that this discussion is really off topic for this list,
this is a real issue, 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 sec
> 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
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.
t
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 Argon
> 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
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
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
14 matches
Mail list logo
