One possible way to incentivize the existence of more Bitcoin network nodes
is by paying peers when they provide data in the blokcchain. One of the
problems is that it is not easy to tell if the peer is really providing a
useful service by storing the blockchain or it is just relying the request
to
On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik wrote:
> The problem comes with the impact of an unfocused stream of refactors to
> key code.
>
> For example, there is much less long term developer impact if refactoring
> were _accelerated_, scheduled to be performed in a one-week sprint. There
> i
I basically agree with what has been said here.
Refactoring efforts should be well-coordinated. Their short-term impact can be
quite disruptive, although if done correctly, longer-term they make it even
easier for downstream developers to add and merge changes.
By scheduling move-only changes,
Drak,
I would say that the refactoring does actually fulfill some conditions you
mention:
- move-only is almost always clearly separated out
- the refactoring is not controversial _in minimis_ - meaning, the
individual pull request is not controversial.
The problem comes with the impact of an unf
This scheme would mostly be beneficial to end users of instant exchange wallets
and would be implemented by the operators. None of the parameters would be
filled up by the user by hand. It's more of enabling different wallet operators
to communicate with each other and to be able to present to t
Something very similar was posted not too long ago.
Long and sort of it is, there is no point in saying you priced in GBP, etc,
because it can vary from exchange to exchange.
To be honest, adding more things to consider at checkout time confuses
things; why not just specify the amount of Bitcoin
September 15 2015 2:10 PM, "Luke Dashjr" wrote:
> On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote:
>
>> September 15 2015 6:04 AM, "Luke Dashjr" wrote:
>>> I think probably the whole signed message thing needs to be rethought.
>>> The most common "uses" today seem to be i
Wouldn't need to. The is of BTC to . BTC is the intermediary
currency, as is basically how it becomes in this "payment rails" method.
To the receiver, it wouldn't matter what currency the transaction came from.
On Tue, Sep 15, 2015 at 8:48 PM, Angel Leon wrote:
> might want to specify there t
might want to specify there that the rate being sent is out of USD.
http://twitter.com/gubatron
On Tue, Sep 15, 2015 at 7:10 AM, John Bailon via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> I'd like to propose a BIP for a standard URI scheme to allow wallet
> operator
On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote:
> September 15 2015 6:04 AM, "Luke Dashjr" wrote:
> > I think probably the whole signed message thing needs to be rethought.
> > The most common "uses" today seem to be insecure cases that it doesn't
> > actually work in: peo
Hello,
I'd like to propose a BIP for a standard URI scheme to allow wallet
operators that implement instant exchange or pegging to other currencies,
cryptocurrencies or asset classes to allow for interoperable communications
of rates and other pertinent information.
The idea is to include in the
September 15 2015 6:04 AM, "Luke Dashjr" wrote:
> I think probably the whole signed message thing needs to be rethought. The
> most common "uses" today seem to be insecure cases that it doesn't actually
> work in: people trying to prove ownership of bitcoins and/or that they sent
> bitcoins (curre
I also share a lot of Jeff's concerns about refactoring and have voiced
them several times on IRC and in private to Jorge, Wladamir and Greg. I
meant to do a write up but never got around to it. Jeff has quite
eloquently stated the various problems. I would like to share my thoughts
on the matter b
13 matches
Mail list logo
