1 2017-10-31 05:14:40	0|weuniverse|Join
  2 2017-10-31 09:38:27	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11585: addrman: Add missing lock in Clear() (CAddrMan) (06master...06missing-lock-in-addrman-clear) 02https://github.com/bitcoin/bitcoin/pull/11585
  3 2017-10-31 11:59:52	0|jtimon_|wasn't there a communicate that bitcoin core will never release non free software somewhere?
  4 2017-10-31 12:11:23	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bb9ab0fccfba...8335cb478183
  5 2017-10-31 12:11:24	0|bitcoin-git|13bitcoin/06master 142530bf2 15practicalswift: net: Add missing lock in ProcessHeadersMessage(...)...
  6 2017-10-31 12:11:24	0|bitcoin-git|13bitcoin/06master 148335cb4 15Wladimir J. van der Laan: Merge #11578: net: Add missing lock in ProcessHeadersMessage(...)...
  7 2017-10-31 12:12:16	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11578: net: Add missing lock in ProcessHeadersMessage(...) (06master...06ProcessHeadersMessage) 02https://github.com/bitcoin/bitcoin/pull/11578
  8 2017-10-31 12:33:39	0|Cirolaus_|just let you guys now that you can earn bitcoin by gaming (not affiliate link) https://coinleague.cc
  9 2017-10-31 14:46:34	0|promag|sipa: friendly ping #11563
 10 2017-10-31 14:46:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/11563 | Improve CheckBlockIndex performance by promag · Pull Request #11563 · bitcoin/bitcoin · GitHub
 11 2017-10-31 15:37:20	0|kanzure|for manually testing hard-fork scenarios (when hard-fork clients don't supply adequate test infrastructure), it should be sufficient to have two regtests that have common history and then are kept separated, right?
 12 2017-10-31 15:43:55	0|sipa|kanzure: invalidateblock is your friend
 13 2017-10-31 15:44:10	0|kanzure|ah that could work for this.
 14 2017-10-31 15:44:23	0|kanzure|thank you
 15 2017-10-31 15:53:34	0|kanzure|also: there should be a walletnotify that triggers a notification with pre-configured memo field after configurable n blocks.
 16 2017-10-31 15:53:57	0|kanzure|which should solve basically all of the payments integration use cases
 17 2017-10-31 15:56:13	0|promag|you mean alertnotify?
 18 2017-10-31 15:56:44	0|sipa|that's for alerts
 19 2017-10-31 15:56:51	0|sipa|not for payments
 20 2017-10-31 15:57:06	0|promag|walletnotify only notifies txid right?
 21 2017-10-31 15:57:31	0|sipa|yes
 22 2017-10-31 15:59:14	0|promag|then I don't understand what kanzure is saying
 23 2017-10-31 15:59:37	0|sipa|he wants a notification only when it gets a spefific number of confirmations
 24 2017-10-31 15:59:55	0|sipa|that's configurable per address/label
 25 2017-10-31 16:00:30	0|promag|why?
 26 2017-10-31 16:00:59	0|kanzure|haha what do you mean why?
 27 2017-10-31 16:01:06	0|promag|having that may cause lots of notifications
 28 2017-10-31 16:01:18	0|kanzure|yes i agree it will cause lots of notifications (due to lots of internal reasons)
 29 2017-10-31 16:01:25	0|kanzure|but having many notifications is better than no notifications
 30 2017-10-31 16:01:35	0|promag|but there is a notification: blocknotify
 31 2017-10-31 16:01:38	0|kanzure|walletnotify on first confirmation isn't useful-- you need the notification to be triggered after n notifications
 32 2017-10-31 16:01:42	0|kanzure|blocknotify is not the same thing
 33 2017-10-31 16:02:01	0|kanzure|think about your typical idiot web developer-- the simplest possible solution is a notification when the payment is well-confirmed
 34 2017-10-31 16:02:02	0|promag|because of forks?
 35 2017-10-31 16:02:08	0|sipa|the idea is that you can check number of confirmations of all your oending transactions after each block
 36 2017-10-31 16:02:17	0|sipa|as those are the only times ehen confirmationd can change
 37 2017-10-31 16:02:51	0|kanzure|yes but that's more work for the web developer-- if you give them a notification, it's almost zero additional work, and it's easier than setting up stripe
 38 2017-10-31 16:04:25	0|sipa|kanzure: there are other complications... you need to keep track of your oayments and their confirmation status, what theybwere for, make sure that is in safe storage (so that after a system failure, you don't end up with payments without knowing what order they are for, ...)
 39 2017-10-31 16:05:01	0|sipa|but yes, having a notification for a specific number of confirmations would be useful - except this now also needs backups inside core
 40 2017-10-31 16:05:03	0|promag|been there, and walletnotify is not a good solution, you can easily lost notifications, you can have lots of pending transactions, etc.. the overhead can be huge IMO
 41 2017-10-31 16:05:23	0|kanzure|lost notifications are a problem, and yes wallet backup procedures become more important, but they were important anyway
 42 2017-10-31 16:06:07	0|promag|I always thought of a thing like postgres wal, that can be replayed
 43 2017-10-31 16:06:16	0|sipa|i think the only correct solution is that you keep track of confirmations yourself, and after every walletnofiy/blocknotofy you check your outstanding payments again
 44 2017-10-31 16:06:33	0|sipa|even ignore the txid passed in walletnotify
 45 2017-10-31 16:06:40	0|kanzure|sipa: the exercise was how to minimize the total integration complexity for a web merchant
 46 2017-10-31 16:06:46	0|sipa|listsinceblock can help reduce bandwidth
 47 2017-10-31 16:06:58	0|promag|IIRC walletnotify notifies 1 -> 0 confirmation change right?
 48 2017-10-31 16:07:06	0|kanzure|only on 0 and 1 conf
 49 2017-10-31 16:07:07	0|sipa|kanzure: yes, and i don't have a good way of doing that that doesn't result in more risks
 50 2017-10-31 16:07:37	0|kanzure|sipa: more risk is probably okay, since the total cost of the integration is so low, more resources can be spent by the integrator on e.g. backup procedures.
 51 2017-10-31 16:07:55	0|sipa|backup procedures may not be enough
 52 2017-10-31 16:08:21	0|sipa|if your solution relies on bitcoind persisting the requested notifications
 53 2017-10-31 16:08:42	0|sipa|as that effectively requires a backup system integrated into bitcoond
 54 2017-10-31 16:08:48	0|promag|what I think is the best for the moment is to keep track of new blocks, and check pending transactions confirmations (without doing too much RPC)
 55 2017-10-31 16:09:21	0|kanzure|promag: my exercise was "what is the 5 minute integration" and walletnotify after 6 blocks would do the trick, even with extremely high risk
 56 2017-10-31 16:09:47	0|sipa|and if you don't rely on that, your web developer needs to deal with restarts and lost notifications anyway, at which poijt as simple "check all unconfirmed txn after every block" will be easier and safer
 57 2017-10-31 16:09:49	0|kanzure|check pending transactions on each blocknotify would involve persisting and doing read-write on that data outside of bitcoind, this is going to take more than 30 seconds for an idiot to implement
 58 2017-10-31 16:10:11	0|sipa|kanzure: *every* solution will require persisiting information outside bitcoind
 59 2017-10-31 16:10:30	0|sipa|how else will you know what your orders are that are being paid, at the least
 60 2017-10-31 16:10:36	0|kanzure|i think it can be minimized and greatly reduced
 61 2017-10-31 16:10:45	0|kanzure|to only one write requirement somewhere. and minimal reads.
 62 2017-10-31 16:11:08	0|kanzure|anyway, i don't have a specific proposal
 63 2017-10-31 16:11:47	0|sipa|we've discussed this many times, but persistance of such notification requests is a pain
 64 2017-10-31 16:11:56	0|sipa|and effectively not something we can do safely now
 65 2017-10-31 16:11:58	0|promag|IMO there is no 5 min integration
 66 2017-10-31 16:12:36	0|sipa|this is part of the reason why accounts aren't safe to use, as well
 67 2017-10-31 16:13:05	0|sipa|you can't guarantee that a backup will happen between the creation of an account address and the receipt of the payment
 68 2017-10-31 16:13:18	0|kanzure|why not? tell the user to do the backup.
 69 2017-10-31 16:13:33	0|sipa|when?
 70 2017-10-31 16:13:37	0|kanzure|whenever you please
 71 2017-10-31 16:13:45	0|sipa|no, not whenever you olease
 72 2017-10-31 16:13:47	0|kanzure|there should be a backupwallet hook
 73 2017-10-31 16:14:30	0|sipa|if you crash after handing out the address, and before making a backup, you lost a customer
 74 2017-10-31 16:15:08	0|kanzure|then you should only return from getnewaddress after the backup is complete..
 75 2017-10-31 16:15:38	0|sipa|yes, which would require a built-in backup solution in bitcoind, which we don't have
 76 2017-10-31 16:16:18	0|sipa|and generally, since you need to store payment information outside anyway, why bother duplicating the complication
 77 2017-10-31 16:18:04	0|sipa|i think a paymemt watching layer in python with sql integration or so would be very useful
 78 2017-10-31 16:19:12	0|sipa|which deals with persisted orders, recovery after restart/crash, RPCs with bitcoind, ....
 79 2017-10-31 16:20:29	0|promag|you can use multiple nodes to scale or even have redundancy with watchonly
 80 2017-10-31 16:24:17	0|promag|sipa, is it worth improving CheckBlockIndex
 81 2017-10-31 16:24:19	0|promag|?
 82 2017-10-31 16:50:17	0|kanzure|sipa: that layer would be immensely useful, and would also abolish many merchant's requirement for a payment integrator api service thing. e.g. provides them a reason to run a full node.
 83 2017-10-31 16:51:31	0|sipa|promag: no opinion
 84 2017-10-31 16:51:42	0|sipa|benchmarks help
 85 2017-10-31 18:43:12	0|cfields|uhmm
 86 2017-10-31 18:43:29	0|cfields|BlueMatt: ping
 87 2017-10-31 18:43:35	0|sipa|*drumroll*
 88 2017-10-31 18:43:53	0|cfields|BlueMatt: i think 57edc0b0 is pretty busted?
 89 2017-10-31 18:44:16	0|BlueMatt|yo?
 90 2017-10-31 18:44:33	0|BlueMatt|why is that busted?
 91 2017-10-31 18:44:39	0|cfields|pretty sure i ACKed that too quickly :\
 92 2017-10-31 18:44:56	0|BlueMatt|cfields: well I think you mean one of the associated commits, cause that commit itself is literally only a rename
 93 2017-10-31 18:45:15	0|BlueMatt|busted how?
 94 2017-10-31 18:45:16	0|cfields|BlueMatt: grr, nm.
 95 2017-10-31 18:45:18	0|BlueMatt|there is the static seeds issue
 96 2017-10-31 18:45:33	0|cfields|dammit, it always clicks after i do the ping.
 97 2017-10-31 18:45:35	0|BlueMatt|which is fixed in #11512
 98 2017-10-31 18:45:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
 99 2017-10-31 18:45:54	0|cfields|BlueMatt: yea, nm. ignore.
100 2017-10-31 18:46:06	0|BlueMatt|k
101 2017-10-31 18:46:33	0|cfields|BlueMatt: i have several patch series that add an m_automatic_connection for addrman connections
102 2017-10-31 18:46:50	0|cfields|i couldn't unsee, thought the logic was reversed
103 2017-10-31 18:47:31	0|BlueMatt|heh
104 2017-10-31 19:31:50	0|spudowiar|Can nHashType ever be zero?
105 2017-10-31 19:35:58	0|jonasschnelli|spudowiar: 0 would be an undefined value
106 2017-10-31 19:36:28	0|spudowiar|Thanks
107 2017-10-31 19:36:59	0|jonasschnelli|spudowiar: look at BCH,... they use also it's own SIGHASH-type...
108 2017-10-31 19:37:35	0|sipa|i think 0 is totally valid
109 2017-10-31 19:37:40	0|spudowiar|ok
110 2017-10-31 19:37:45	0|sipa|but nonstandard
111 2017-10-31 19:37:51	0|spudowiar|Doing some stupid BTG support for TREZOR
112 2017-10-31 19:38:06	0|jonasschnelli|Grml.. BTG!
113 2017-10-31 19:38:18	0|spudowiar|And they decided to use SIGHASH_FORKID with non-BIP143 signatures
114 2017-10-31 19:38:23	0|spudowiar|So I need to rewrite all that
115 2017-10-31 19:39:59	0|jonasschnelli|I would prefere if Trezor would not support BTG. :) Sorry for off-topic
116 2017-10-31 19:40:16	0|jonasschnelli|(but I understand it)
117 2017-10-31 19:40:45	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11587: Fix warnings when building with -Wthread-safety-analysis (06master...06–Wthread-safety-analysis) 02https://github.com/bitcoin/bitcoin/pull/11587
118 2017-10-31 19:42:16	0|spudowiar|jonasschnelli: Believe me, so would I :P
119 2017-10-31 19:42:34	0|jonasschnelli|heh
120 2017-10-31 19:48:22	0|Alkhara|Anyone willing to answer a question 1:1 that has to do with source code but not directly for the Bitcoin project please DM me. I don't want to off-topic but you guys are probably the best source of information on this.
121 2017-10-31 19:50:01	0|sipa|Alkhara: bitcoin.stackexchange.com
122 2017-10-31 22:51:20	0|earlz|Is it possible to modify the gitian scripts to cross-compile bitcoin-qt for ARM?
123 2017-10-31 22:54:39	0|achow101|earlz: I believe you can just modify the HOSTS line here: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L37
124 2017-10-31 22:54:48	0|achow101|you can also just use the depends system and build without gitian
125 2017-10-31 22:55:00	0|achow101|(which is basically what gitian does but in a VM)
126 2017-10-31 22:55:33	0|earlz|it already builds bitcoind, etc. But it doesn't build Qt or bitcoin-qt for ARM is the problem
127 2017-10-31 22:55:53	0|earlz|I can't find where in the code it determines where to build qt or not
128 2017-10-31 23:01:54	0|earlz|ah, found it.. https://github.com/bitcoin/bitcoin/blob/master/depends/packages/packages.mk#L7
129 2017-10-31 23:02:08	0|earlz|unsure if copying that and making it qt_arm_linux_packages will help though
130 2017-10-31 23:24:14	0|jonasschnelli|earlz: Yeah... you can try to build it with a dynamic linkes qt?
131 2017-10-31 23:24:15	0|jonasschnelli|*linked