Transcript for #bitcoin-dev 2017/09/18

01:00 molz Krellan, there's a newer version
01:02 molz v0.15.0.1 but you have to compile it:
16:33 RealM9 Bitcoin is again under a spam attack
16:50 gmaxwell RealM9: stop fudding.
16:50 gmaxwell I looked last night when people first started squaking about that and it appeared to be due to txs like which are just plain aggregation tx
16:50 cluelessperson Not found.
16:51 gmaxwell what do you mean not found
18:54 digitlimit With regards to bitcoin core wallet, will I pay a transaction fee if I send bitcoin from address A to address B all in same wallet?
18:56 belcher yes digitlimit
18:56 belcher also thats a question better suited for #bitcoin
18:56 digitlimit I asked in #bitcoin no response
18:56 digitlimit thanks
19:27 sturles gmaxwell: At 7:02 AM UTC today, someone dumped 13 MB of high fee (more than double of what estimatefee 4 recommended 10 minutes before) transactions on the network in a minute.
19:28 sturles If it wasn't spam, it was certainly not very smart.
19:29 sturles Consolidation like that can be done almost for free at a slow pace.
19:30 gmaxwell sturles: their first ten transactions were at 1s/byte.
19:30 gmaxwell then they went to 100... might be a fatfinger.
19:30 sturles OK.
19:30 sturles It was 6 AM UTC, btw.
19:30 sturles Example: 865dde5929e0179e004e21c47f186a93849b18548319f8aa91f4660128d34d5b
19:31 cluelessperson 41 confirmations since 2017-09-18T07:27:14, 130 in, 2 out, 19539 Bytes, 111 sat/B fee
19:31 gmaxwell 87cd70a1859f1029d7619ca6b745232e34b8627fc7ac1e2e50a4b2705c6aba48
19:31 cluelessperson Not found.
19:31 gmaxwell lies.
19:32 sturles If you follow it, you see it was consolidated to 100 BTC, then split up again to 20, etc.
21:50 StopAndDecrypt oh shit
21:50 StopAndDecrypt pruned
21:51 StopAndDecrypt do i have to start it in pruned or can i change that in the console during sync
21:59 StopAndDecrypt again nvm
22:28 omarshibli Hey all, I'm working on a new BIP proposal - Pay to Contract
22:28 omarshibli We got feedback from Luke recently raising a serious backward compatibility issues in the proposed BIP to BIP32 and its related BIPs, based on the feedback we updated the BIP to make it clear that this BIP is not compatible with any of BIP32 related specifications.
22:28 omarshibli I think we have introduced some confusion with the non-traditional usage of HD wallets, the main mistake is that HD specification deals with wallets that are derived from a single seed and enumerable set, while in the proposed BIP wallet are derived from a single seed and non-enumerable set.
22:28 omarshibli I think we may have different options to solve this, would like to hear your thoughts about:
22:28 omarshibli 1. Stick with BIP32 derivation mechanism,
22:28 omarshibli advantages: wallet implementation easier due to code reuse.
22:28 omarshibli disadvantages: performance far my ideal, it might be not a big deal since it's off-chain computation anyway.
22:28 omarshibli 2. Create a new wallet structure that supports a bigger range of values, maybe something like this:
22:28 omarshibli m / coin' / sha256_hash_in_hex
22:28 omarshibli coin - similar to BIP44 - livenet/testnet
22:28 omarshibli sha256_hash_in_hex - sha246 hash of the contract in hex format
22:28 omarshibli examples:
22:28 omarshibli livenet: m / 0' / 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
22:28 omarshibli testnet: m / 1' / 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
22:28 omarshibli Please advice, any hint would be much appreciated.
22:30 omarshibli urgh, the message is missed up a bit, I should have copy it line by line, sorry.