On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net wrote:
Meanwhile, what I said *is* correct. New version numbers result in only
a log print. Being hard forked off results in both log prints *and* the
-alertnotify being run:
That is easy to change; I'll submit a pull request. It is
That is easy to change; I'll submit a pull request.
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for
Before starting to implement a patch for a specific need, I would like
to be sure that it was not written already and available somewhere.
This list is probably my best chance.
I would like to add an optional parameter block_heigh to -rescan,
from which the rescan would then start. When
On 06/10/2014 08:43 p.m., Tom Harding wrote:
On 10/5/2014 4:00 PM, Sergio Lerner wrote:
If everyone acts rationally in his own interest, then the best choice
for the remaining miners is to try to mine a competing block at the
same height n including the high-fee transaction, to collect the
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote:
Using the my previous terminology, automatic fee-sharing (ORBS) is a
solution to the freeze problem (FRONT) but opens the windows to
CHAKIDO double-spending. and CHAKIDO double-spending is a much worse
On 07/10/2014 04:16 p.m., Gregory Maxwell wrote:
Then I spend the output of the fraudulent spend nlocked
one block higher, and spend the output of that one again, nlocked one
block higher, and so on... each step paying fees.
Yes, you're right. I didn't consider that case. But the problem is
On 10/7/2014 8:50 AM, Gavin Andresen wrote:
I don't have any opinion on the hard- versus soft- fork debate. I
think either can work.
Opinion: if a soft work works, it should be preferred, if for no other
reason than once a hard-fork is planned, the discussion begins about
what else to
Mail list logo