On 7 March 2017 at 08:23, Gareth Williams wrote:
> What you're describing is a hashpower activated soft fork to censor
> transactions, in response to a user activated soft fork that the majority of
> hashpower disagrees with.
Well, they'd be censoring transactions to prevent the thing from
acti
What you're describing is a hashpower activated soft fork to censor
transactions, in response to a user activated soft fork that the majority of
hashpower disagrees with.
It is always possible for a majority of hashpower to censor transactions they
disagree with. Users may view that as an attac
On 03/06/2017 06:37 AM, Tim Ruffing via bitcoin-dev wrote:
> And is the historical rate thing really necessary
> for typical applications?
Yes, it is. Basically all incoming transactions are historical, as your
wallet is likely not online when it happens.
___
On Mon, 2017-03-06 at 17:30 -0500, Tim Ruffing via bitcoin-dev wrote:
>
> That works but a standardized way of indicating that piece of
> information to the client is useful. Then the client can display a
> "connection status" to the user, e.g., an "possible out-of-date"
> warning like the warning
On Mon, 2017-03-06 at 22:14 +, Luke Dashjr wrote:
> It would be a privacy leak to request only the specific timestamps,
> but I
> suppose many wallets lack even basic privacy to begin with.
>
> To address the bounds issue, I have specified that when from/to don't
> have an
> exact record, th
On Monday, March 06, 2017 10:02:53 PM Tim Ruffing via bitcoin-dev wrote:
> For longpolling, maybe we would like to have the possibility to request
> some periodic message from the server. Otherwise clients cannot
> distinguish between the situations 1. "value is still in the requested
> bounds (min
On Monday, March 06, 2017 9:54:16 PM Tim Ruffing wrote:
> Having the rate at the time of payment is indeed very useful, yes.
> However that requires just a single value per payment, and there is no
> query that tells the server "give me the value closest to timestamp t"
> or similar.
> Of course th
On Mon, 2017-03-06 at 16:54 -0500, Tim Ruffing via bitcoin-dev wrote:
>
> > Pushing is what longpolling does.
> >
>
> That makes a lot of sense, yes.
>
Forgot one thing:
For longpolling, maybe we would like to have the possibility to request
some periodic message from the server. Otherwise clie
On Mon, 2017-03-06 at 07:09 +, Luke Dashjr wrote:
> On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev
> wrote:
> > But ignoring this, the server should be authenticated at a
> > minimum. Otherwise manipulating exchange rates seems to be a nice
> > way for the attacker on the wire
On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
wrote:
> User activated soft forks, or perhaps more accurately called 'economically
> forced soft forks' are a tool to use if the miners are in clear opposition
> to the broader economy.
I don't think they work for that, at least not for new
On Mar 5, 2017 6:48 PM, "Eric Voskuil" wrote:
Independent of one's opinion on the merits of one fork or another, the
state of centralization in Bitcoin is an area of great concern. If "we" can
sit down with 75% of the economy and/or 90% of the hash power (which of
course has been done) and negot
I like the BIP. It can reduce workload during implementation on both sides of
the API and it allows to show the user more data without implementing tons of
proprietary APIs.
It’s not directly Bitcoin specific (example: BIP32 is also not Bitcoin
specific), but I think a BIP is the right way for
12 matches
Mail list logo
