01:25 < IGHOR> Hello everyone

01:25 < IGHOR> does anyone knows what Bitcoin Core doing on confirmations fork if happen? Is it replacing forked blocks or just appending new one?

06:32 < angg> .

10:40 < savantgarde> Regarding the transactions field from the result of the bitcoind RPC call listsinceblock, must one sum up the amounts of the entries for the same transaction, but with different vout values, in order to get the full amount received with a transaction?

11:02 < bitcoin-git> [bitcoin] Empact opened pull request #13226: Optimize SelectCoinsBnB by tracking the selection by index rather than by position (master...select-bnb-by-index) https://github.com/bitcoin/bitcoin/pull/13226

11:03 < zrc> Can we build a HD wallet only with JS?

15:50 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/418ae49ee1ea...ffa86af45363

15:50 < bitcoin-git> bitcoin/master 3d8ae74 practicalswift: travis: Rename the build stage "check_doc" to "lint"

15:50 < bitcoin-git> bitcoin/master ffa86af MarcoFalke: Merge #13221: travis: Rename the build stage "check_doc" to "lint"...

15:51 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13221: travis: Rename the build stage "check_doc" to "lint" (master...lint) https://github.com/bitcoin/bitcoin/pull/13221

17:02 < BlueMatt> wumpus: ping

20:28 < bitcoin-git> [bitcoin] sipa opened pull request #13228: Add script to detect circular dependencies between source modules (master...201805_circular_detect) https://github.com/bitcoin/bitcoin/pull/13228

22:59 < jtimon> can anyone remind me what used to be the latest best design on bitcoin-based (feel free to add a new opcode and/or sighash if you need it) for prvably fair lotery?

22:59 < jtimon> I had a conversation about this today and we were using "the price cannot be bigger than the block reward" as a security assumption, but IIRC I heard a better solution. If anybody can refresh my mind with a link or something that would be awesome

23:01 < jtimon> my current design includes an op_deterministic_miner_grindable_random taking the randomness from the current block (I really remember something better than this with past or future blocks or a combination, but it doesn't make sensse to me now, so I feel I'm forgetting something)

23:03 < jtimon> the basic structure is one input per "lottery ticket" and one output, let's say 0.01 input x100 and 1 1 btc-txfees output

23:05 < jtimon> with schnoor many inputs could be 1 signature, also with mast/taprrot/graftroot you can only show the winner's address

23:11 < jtimon> then the other person wasn't comfortable with relaying on a centralized server, so I assumed some loterry_mempool service bits for incomplete lottery txs with anyone can pay, but since you don't know the receipt addresses from people who haven't signed yet when creating the output script, I thought of an op_get_scriptpubkey_for_a_given_output_in_this_tx, which is coventant-like but feels very hacky and overkill and not optimal

23:12 < jtimon> I guess you could also use a decentralized protocol for coinjoin, but I never really understood those

23:13 < jtimon> this time it would be simpler since it's just one output

23:13 < jtimon> please remind me what I'm missing/forgetting