On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev
wrote:
> ... Gavin just told me about setmocktime. That's fast service!
Once more functions (specially consensus-critical functions) take
nTime explicitly as parameter instead of relying on the
Once again my attempt to summerize and explain the weekly bitcoin developer
meeting in layman's terms.
Link to last weeks summerization (
https://www.reddit.com/r/Bitcoin/comments/3o7bi6/bitcoin_dev_meeting_in_laymans_terms_2015108/
)
Link to this weeks on reddit:
After spending some more time on the normalized transaction ID proposal and
reworking it to be a soft-fork (thanks sipa for helping me figuring out
how), I'd like to propose the BIP again.
As with the previous version, which was using a hard-fork, the normalized
transaction ID is computed only
On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As with the previous version, which was using a hard-fork, the normalized
> transaction ID is computed only considering the non-malleable parts of a
> transaction, i.e., stripping
My nodes are continuously running getblocktemplate and getinfo, and I also
suspected the issue is in either gbt or the rpc server.
The instance only takes a few hours to get up to that memory usage.
On Oct 18, 2015 8:59 AM, "Jonathan Toomim via bitcoin-dev" <
Yes, this has been pointed out in the PR as well. Transactions inputs must
also be normalized by replacing malleable hashes with the normalized
hashes. I will fix the spec and the implementation to reflect this :-)
Regards,
Christian
On Mon, Oct 19, 2015 at 5:24 PM Tier Nolan via bitcoin-dev <
So what exactly is used to create the normalized txid (sha256 hash of
what data)? I've read in the linked BIP draft that it will strip the
'malleable parts' but didn't understand what exactly will be used to
calculate the normalized transactions ids and how will the change apply
retro-active for
I should also mention that this is definitely not an attack coming from
connected nodes. My node experiencing the issue is only connected to 3
other nodes, all of which I control (via connect=).
--Adam
On Mon, Oct 19, 2015 at 12:17 PM, Multipool Admin
wrote:
> My nodes are