< bitcoin-git>
bitcoin/master fa4010e MarcoFalke: travis: Print memory and number of cpus
< bitcoin-git>
bitcoin/master 67737cf MarcoFalke: Merge #16438: travis: Print memory and number of cpus
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16438: travis: Print memory and number of cpus (master...1907-travisFreeProc) https://github.com/bitcoin/bitcoin/pull/16438
< fanquake>
Raystonn: I'm working on porting one of our C based tools to Rust. The library (libdmg-hfsplus) is unmaintained, and broken such that we need to use genisoimage to first create an ISO, then convert that to a DMG.
< fanquake>
Ideally we can replace both with a single tool. It'd also mean we can drop some of our "hacks" and generate DMGs closer to what you'd expect to see out of hdiutil.
< fanquake>
ariard: would you like anything put into high-priority? One of the base PRs for some of your locking changes?
< ariard>
fanquake: hey, #15713 has already been reviewed a lot by jnewbery, I think it's ready for another round, that's the first step for the locking changes
< bitcoin-git>
[bitcoin] ajtowns opened pull request #16439: RPC: support "@height" in place of blockhash for getblock etc (master...201907-getblock-at-height) https://github.com/bitcoin/bitcoin/pull/16439
< kallewoof>
If I wanna turn a CKey into a CTxDestination, is ExtractDestination(GetScriptForRawPubKey(key.GetPubKey()), dest) the right approach? It looks weird, e.g. GetScriptForRawPubKey() gives a P2PK script...
< bitcoin-git>
[bitcoin] kallewoof opened pull request #16440: BIP-322: Generic signed message format (master...feature-generic-signed-message-format) https://github.com/bitcoin/bitcoin/pull/16440
< Raystonn>
fanquake: Just saw the message regarding the port of libdmg-hfsplus to rust. That's great. Are there any other tools or other unmaintained modules that you think could use the same treatment? I'm tempted to port everything to rust just to see what flaws it can help us find in Core. But so much work in a complex moving target.
< ryanofsky>
dongcarl, wumpus: question about bip-0155. I don't see a size field. So if we add a new network type, and serialize a list of addresses, can old software deserialize the full list and only ignore new addresses?
< dongcarl>
ryanofsky: From my understanding we're not going to send addrv2 messages to old peers
< ryanofsky>
by "old software" i mean software that understands addrv2, but doesn't understand new address types that we could add later
< ryanofsky>
if there's a size field, that software could skip unknown address types in a list and ignore them. question is if that's possible in the proposal without a size field
< sipa>
oh, i assumed there was some form of size field
< sipa>
ryanofsky: addr is serialized as a byte vector
< sipa>
which has an implicit length byte
< ryanofsky>
ah, missed that part, thanks
< ryanofsky>
and i see dongcarl basically asked the opposite question yesterday. just catching up now
< dongcarl>
I think the "size" can be specified either at the addr-field level (as in the spec) or at the "address"-level... I'll try both out when implementing and see which one is simpler. If people have a preference with a rationale that would also be nice
< dongcarl>
s/"address"/"address-entry"/
< sipa>
dongcarl: i suspect it's easiest as specified in the bip
< sipa>
just treat the addr field as a std::vector<uint8_t> and convert it from/to internal format
< ryanofsky>
yeah, field level as specified is probably easier to implement. entry level probably doesn't have an advantage because there are already other fields that could be used to extend entry format in the future
< ryanofsky>
one thing i might change is "Network port. If not relevant for the network this MUST be 0."
< ryanofsky>
if port is not relevant for the networkID, could just not serialize the port field
< ryanofsky>
but this would argue for entry-level rather than field-level size i guess...
< sipa>
yup, exactly
< sipa>
could also merge the port field into the address
< sipa>
with network type specific semantics on how to split them
< jnewbery>
Is there any reason for CMerkleTx to exist (separate from CWalletTx)? It's been there since it was in main.cpp in the first git commit, but it's now in wallet.h and is _only_ used as the base class for CWalletTx, so it seems redundant.
< sipa>
it used to be the case that for every CWalletTx , a CMerkleTx was stoeea for each unconfirmed dependency or so
< sipa>
*stored
< jnewbery>
That doesn't seem to be the case any more
< sipa>
indeed; i believe they're redundant now
< jnewbery>
yeah, looks like it was called vtxPrev, removed in 93a18a3650292afbb441a47d1fa1b94aeb0164e3
< jnewbery>
I guess we'd still need the deserialization logic, to be able to read old wallet files
< sipa>
oh, good point
< jnewbery>
but we could have a very small class with just serialize/deserialize functions and move all the other functions into CWalletTx
< MarcoFalke>
Oh, maybe not, because it is only used by the wallet
< * MarcoFalke>
off
< jnewbery>
yeah, I imagine adding some class DummyMerkleTx or similar in wallet.h that just deals with [de]serialization, and moving all the actual CMerkleTx code into CWalletTx
< amiti>
hi! I have been thinking about improvements to rebroadcast logic. Instead of nodes only rebroadcasting wallet txns, nodes will rebroadcast all txns it believes should have been in the last block. The goal is to improve privacy by making it harder to discern the transaction source.
< bitcoin-git>
[bitcoin] jamesob opened pull request #16443: refactor: have CCoins* data managed under CChainState (master...2019-07-au-coins-under-chainstate) https://github.com/bitcoin/bitcoin/pull/16443
< bitcoin-git>
bitcoin/master fad2502 MarcoFalke: init: Use InitError for all errors in bitcoind/qt
< bitcoin-git>
bitcoin/master fa6f402 Russell Yanofsky: Call node->initError instead of InitError from GUI code
< bitcoin-git>
bitcoin/master 67923d6 MarcoFalke: Merge #16366: init: Use InitError for all errors in bitcoind/qt
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16366: init: Use InitError for all errors in bitcoind/qt (master...1907-initErrorGui) https://github.com/bitcoin/bitcoin/pull/16366