< IGHOR> Hello everyone
< IGHOR> does anyone knows what Bitcoin Core doing on confirmations fork if happen? Is it replacing forked blocks or just appending new one?
< angg> .
< 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?
< 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
< zrc> Can we build a HD wallet only with JS?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/418ae49ee1ea...ffa86af45363
< bitcoin-git> bitcoin/master 3d8ae74 practicalswift: travis: Rename the build stage "check_doc" to "lint"
< bitcoin-git> bitcoin/master ffa86af MarcoFalke: Merge #13221: travis: Rename the build stage "check_doc" to "lint"...
< 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
< BlueMatt> wumpus: ping
< 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
< 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?
< 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
< 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)
< 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
< jtimon> with schnoor many inputs could be 1 signature, also with mast/taprrot/graftroot you can only show the winner's address
< 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
< jtimon> I guess you could also use a decentralized protocol for coinjoin, but I never really understood those
< jtimon> this time it would be simpler since it's just one output
< jtimon> please remind me what I'm missing/forgetting