currencyCode and cryptoCurrencyCode seem to assume that merchants will
always want to sell for fiat. But a merchant might want to sell for
another cryptocurrency instead.
Why not make it more generic, like buySymbol and sellSymbol?
> "currencyCode" : "CAD",
>
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.
s 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
er 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].
>>
>> -- ration
amples:
> 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
> ca
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
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
On 09/15/2017 01:40 PM, Simone Bronzini wrote:
> Since a soft-fork is a restriction of the consensus rules, I think the
> only way to have an un-soft-forkable cryptocurrency is creating a
> cryptocurrency where no transaction is valid.
>
> Imagine I build a very minimal cryptocurrency where in
have to always hardfork.
>
> On 13 September 2017 at 10:50, Dan Libby via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Hi, I am interested in the possibility of a cryptocurrency software
>
On 09/15/2017 02:14 AM, Adam Back wrote:
> However most types of soft fork are opt-in...
my concern is that the community can be manipulated via political means.
marketing, social media, payoffs, fud, etc, etc, etc. And essentially
degrades to tyranny of the majority.
So if there is any way
Ok, this is good stuff. thanks for the thoughtful reply.
Regarding anyone-can-spend:
all of the examples you gave do not satisfy isStandard. So if our
hypothetical cryptocurrency were to restrict all transactions to
isStandard at the consensus layer, would that not effectively prevent
Hi, I am interested in the possibility of a cryptocurrency software
(future bitcoin or a future altcoin) that strives to have immutable
consensus rules.
The goal of such a cryptocurrency would not be to have the latest and
greatest tech, but rather to be a long-term store of value and to offer
On 08/30/2017 12:24 AM, shiva sitamraju via bitcoin-dev wrote:
> What would happen if you recover a wallet using seed words ?
> 1. Since there is no difference in seed words between segwit/non
> segwit, the wallet would discover both m/44' and m/49' accounts
> 2. Note that we cannot ask the
Hampus, thanks for the explanation!
On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
> Yes.
> So you have two choices to be fully secure:
> 1. Validate using the new rules of the network (in other words, run a
> SegWit node)
> 2. Avoid any chain of transaction that contains a SegWit transaction
On 07/13/2017 09:35 AM, Jameson Lopp wrote:
>
>
> On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> On 07/13/2017 06:39 AM, Hampus Sjöberg
On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
>> I believe that a good reason not to wish your node to be segwit
> compliant is to avoid having to deal with the extra bandwidth that
> segwit could require. Running a 0.14.2 node means being ok with >1MB
> blocks, in case segwit is
On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote:
> I think that terminology isn't quite precise. I think your options are:
>
> - if you're a miner or run a mining pool, you can *signal* (or not
>signal) support for segwit activation; you do this by controlling
>the block
Hi!
Up to now, I have purposefully been running bitcoin releases prior to
0.13.1 as a way to avoid the (possible) segwit activation, at least
until such time as I personally am comfortable with it.
At this time, I would like to have some of the more recent features, but
without the possibility
18 matches
Mail list logo
