On Monday, October 5, 2015, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As Greg explained to you repeatedly, a softfork won't cause a
>> non-upgraded full node to start accepting blocks that create more
>> subsidy than is valid.
>>
>
> It was an example. Adam Back'
That's suboptimal for Europe etc., starting at midnight in the UK, 1 AM in
CET, 2 AM in EET (an hour earlier once DST ends).
On Wednesday, September 23, 2015, Vincent Truong via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> All,
>
> Current meeting time visualised globally.
>
> ht
A smaller block size would make this a soft fork, as unupgraded nodes would
consider the new blocks valid. It would only make things that were allowed
forbidden, which is the definition of a soft fork. For a hard fork, you
need to allow something that was previously invalid.
On Tuesday, August 18,
My interpretation is that he's saying Satoshi wouldn't be welcome to return
as Satoshi, because whatever he did/said would inevitably end up being
treated with authority, which shouldn't be the case.
On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation
If this proposal has less than half of the total hashpower (or is it even
less than 75%? Haven't quite thought it through completely) supporting it,
I can see the following happening if the sum of supporters and people who
want to screw the supporters out of money is at least 75%:
Non-supporters cr
RTFM: `help lockunspent`. The boolean parameter is whether or not the UTXO
should be available.
On Thu, Jul 30, 2015 at 11:43 PM, Ian Treibick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> My first post to the list, not sure this is the right place, let me know
> if it is bett