I must remind everyone of Mike Hearn's proposal not many years ago, which
ought to be on everyone's mind right now. "Every soft fork should be a hard
fork, and that soft forks are inherently dangerous because old nodes are
tricked to not know what the new nodes are doing" (paraphrased). Whether
tap
Dormant threshold is way too low. There's many news articles about people
forgetting that they used to mine bitcoins and then suddenly remembered.
This will continue to happen for much longer than 8 years as people
rediscover bitcoin when it goes further mainstream. You can't expect them
to have ru
eatures effectively don't exist,
> regardless of how many nodes have upgraded to handle the feature.
>
> Any new transaction feature should get a new "type" number. A new
> transaction feature can't happen until the nodes support it.
>
> On 12/8/15, Vincent Truon
So I have been told more than once that the version announcement in blocks
is not a vote, but a signal for readiness, used in isSupermajority().
Basically, if soft forks (and hard forks) won't activate unless a certain %
of blocks have been flagged with the version up (or bit flipped when
versionbi
(I haven't been following this development recently so apologies in advance
if I've made assumptions about RBF)
If you made CPFP consensus critical for all Full-RBF transactions, RBF
should be safer to use. I see RBF as a necessity for users to fix mistakes
(and not for transaction prioritisation)
All,
Current meeting time visualised globally.
http://everytimezone.com/#2015-9-24,420,4ia
jl,
I think I found a good compromise: if the US want to accommodate Asia and
willing to sacrifice preference, 23:00 to 00:00 UTC might work.
http://everytimezone.com/#2015-9-24,660,4ia
It isn't easy to
This way lets us protect from 51% overwrites for a whole year:
1. Hash utxo set as is today, H1, and store it in a block.
2. At the same time, store a copy of the utxo set for H1 on disk, D1
3. After 1 year, create D2, then wait for H2 (if a fork happens then
recreate D2 and see which wins)
4. The
Would this alter the way txns will be prioritised in order to try to win?
You would always pick txns with the best BTCDD to maximize your chances of
being the block to build on.
I see this as potentially being a bad outcome for bitcoin's fungibility.
On Sep 12, 2015 5:26 AM, "Dave Scotese via bitc
"Fast transactions"
Fast transactions implies it is slower than Visa, and Visa is 'instant' by
comparison from the spender's POV. Bitcoin is still very instant because
wallets still send notifications/pings when transactions are first seen,
not when it goes into a block. We shouldn't mislead people
