1 2016-02-26 01:00:19 <RainMan28> Hi guys, I upgraded a test node to 0.12 and see that rpc ssl support has been dropped. I see the instructions in the release notes to use stunnel, but am a little unsure as to how I can do that. I currently have an install of bitcoind acting as a server, and 3 other installs acting as clients that connect via rpcssl to it. Do I need to install stunnel on both client and server nodes?
  2 2016-02-26 01:20:08 <kanzure> joseph poon is asking for SIGHASH_NOINPUT deployment in segwit for useful lightning network reasons, http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
  3 2016-02-26 01:48:56 <RainMan28> Does Matt Corallo hang out in this channel?
  4 2016-02-26 01:50:49 <moa> RainMan28: sometimes BlueMatt is around
  5 2016-02-26 01:51:03 <RainMan28> thanks moa
  6 2016-02-26 02:50:08 <phantomcircuit> RainMan28, do NOT expose rpc to the world
  7 2016-02-26 11:26:54 <chjj> anyone having trouble connecting to the segnet seeds?
  8 2016-02-26 11:45:23 <Lauda> Any thoughts on BIP109?
  9 2016-02-26 11:53:56 <TZander> Lauda: its awesome?
 10 2016-02-26 11:54:07 <Lauda> Any implementation or something yet?
 11 2016-02-26 11:56:19 <TZander> it is implemented, yes. Don't think Core will merge it, though
 12 2016-02-26 11:56:44 <Lauda> May I get a link?
 13 2016-02-26 11:56:46 <Lauda> Why not?
 14 2016-02-26 11:57:18 <TZander> why not? I think you have been missing the last 10 months of bitcoin-drama :)
 15 2016-02-26 11:58:11 <Lauda> What has BIP109 to do with 10 months of drama?
 16 2016-02-26 12:03:41 <Luke-Jr> TZander: it isn't up to Core to merge it
 17 2016-02-26 12:03:53 <Luke-Jr> Lauda: poorly designed
 18 2016-02-26 12:04:03 <Lauda> How so?
 19 2016-02-26 12:05:03 <Luke-Jr> Lauda: basically ignores everything we've learned over the last 7 years about how to make changes to Bitcoin
 20 2016-02-26 12:05:33 <TZander> Lauda: if its not up to core, who is it up to?
 21 2016-02-26 12:05:41 <TZander> sorry, Luke-Jr ^
 22 2016-02-26 12:06:01 <Lauda> Luke-Jr 1 concrete flaw in this design?
 23 2016-02-26 12:06:02 <Luke-Jr> the timeline is unrealistic, it activates with a mere 75% of miners (and 0.000001% of economy) supporting it, it leaves old nodes insecure, doesn't really address the issues scaling is concerned with, and aims to do things that clearly don't have consensus
 24 2016-02-26 12:06:08 <Luke-Jr> TZander: the entire community
 25 2016-02-26 12:07:02 <timothy> hi, is there any risk (corruption) if a wallet.dat created with new bdb version (5.x) is opened in a bitcoin-{qt,daemon} using the "current" one (4.8.30)?
 26 2016-02-26 12:07:16 <timothy> or bitcoin-{qt,daemon} just doesn't start?
 27 2016-02-26 12:07:27 <Luke-Jr> timothy: I think the latter, but uncertain.
 28 2016-02-26 12:07:37 <Luke-Jr> timothy: just make a backup first
 29 2016-02-26 12:08:36 <Lauda> Luke-Jr I thought BIP109 was a backwards compatible relay system?
 30 2016-02-26 12:09:10 <timothy> it's not for me, I'm thinking about using the proper bdb version (4.8.30) on new archlinux packages. but old one is using 5.x. Obliusly I'll write an howto to convert the db (db_dump + 4.8.30 db_load), but I don't want users to loose bitcoins :)
 31 2016-02-26 12:09:17 <TZander> Lauda: https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki
 32 2016-02-26 12:09:26 <Lauda> ^I'm reading.
 33 2016-02-26 12:10:24 <TZander> timothy: just do a 'dumpwallet'before (preferably after creating some named receive addresses) and afterwards check if those addresses are still available.
 34 2016-02-26 12:10:55 <TZander> timothy: bdb is supposed to be upwards compatible. There is no guarentee in the direction you ar going.
 35 2016-02-26 12:12:16 <Luke-Jr> Lauda: there is absolutely nothing backward compatible about BIP 109
 36 2016-02-26 12:12:30 <Luke-Jr> timothy: ah, makes sense
 37 2016-02-26 12:12:45 <Lauda> Seems somebody is spreading false information then.
 38 2016-02-26 12:13:03 <Luke-Jr> TZander: I wouldn't rely on dumpwallet.
 39 2016-02-26 12:14:13 <Lauda> Luke-Jr seems there was a confusion as there are two BIP109's..
 40 2016-02-26 12:14:46 <Lauda> I was talking about
 41 2016-02-26 12:14:51 <Lauda> https://gist.github.com/erasmospunk/23040383b7620b525df0
 42 2016-02-26 12:15:04 <Luke-Jr> ah
 43 2016-02-26 12:15:55 <Luke-Jr> "I don't follow the Specification section. It doesn't appear to be actually doing anything that would improve scaling, and looks to hugely increase node bandwidth requirements and use." https://www.reddit.com/r/Bitcoin/comments/3xhqze/bip_109_efficient_block_relay_format_mempool_soft/cy4y3jl
 44 2016-02-26 12:17:40 <Lauda> Thanks.
 45 2016-02-26 12:18:43 <Lauda> That's why I was confused and it didn't make sense. I do agree with the bad design of BIP109 (Gavin).
 46 2016-02-26 12:20:21 <Luke-Jr> Lauda: bip-soft-blocks will get a new number when/if they submit it
 47 2016-02-26 12:20:38 <Lauda> Great.
 48 2016-02-26 12:31:59 <timothy> it seems backwardcompatible, bitcoin-qt build with 4.8.30 version loads without any problem a db created by 5.3.28
 49 2016-02-26 12:32:03 <timothy> wallet.dat:     Berkeley DB (Btree, version 9, native byte-order)
 50 2016-02-26 12:32:05 <timothy> wallet.dat.bak: Berkeley DB (Btree, version 9, native byte-order)
 51 2016-02-26 12:32:16 <timothy> and file returns the same "version"
 52 2016-02-26 12:32:42 <timothy> I'll have to test it on x86 and arm too
 53 2016-02-26 12:33:17 <Luke-Jr> really? that's unexpected
 54 2016-02-26 12:33:23 <Luke-Jr> maybe an Arch thing?
 55 2016-02-26 12:34:04 <timothy> I can't see any patch about new bdb
 56 2016-02-26 12:34:05 <timothy> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/db
 57 2016-02-26 12:34:44 <Luke-Jr> the patch would be on the old ver I'd think
 58 2016-02-26 12:35:34 <Luke-Jr> timothy: note that 0.12 bundles [lib] UniValue; you'll need my syslibs patches if you want to debundle it
 59 2016-02-26 12:36:18 <timothy> Luke-Jr: I didn't patch old version, I mainly followed doc/build-unix.md
 60 2016-02-26 12:36:36 <timothy> aka "vanilla" static version + CPPFLAGS and LDFLAGS
 61 2016-02-26 12:36:39 <Luke-Jr> timothy: I think this is the first version with a non-consensus-critical lib bundled
 62 2016-02-26 12:36:42 <Luke-Jr> just FWIW
 63 2016-02-26 12:37:03 <Luke-Jr> although you may want to package Knots when I release it; no idea how Arch handles things like that though
 64 2016-02-26 12:37:39 <timothy> we avoid to patch think when it's no necessary. so if you bundle a library we keep the bundled version
 65 2016-02-26 12:37:47 <timothy> (guidelines of course)
 66 2016-02-26 12:38:17 <Luke-Jr> interesting, most distros avoid that
 67 2016-02-26 12:38:21 <timothy> drizzt@liara ~ % strings `which bitcoin-qt` | grep 'Berkeley DB [45]'
 68 2016-02-26 12:38:22 <timothy> Berkeley DB 4.8.30: (April  9, 2010)
 69 2016-02-26 12:38:31 <timothy> so I'm really using bdb 4.8.30
 70 2016-02-26 12:40:30 <Luke-Jr> sure bdb 5 made the file?
 71 2016-02-26 12:40:47 <timothy> sure
 72 2016-02-26 12:42:57 <timothy> drizzt@liara .bitcoin % ~/trunk/src/db4/bin/db_dump wallet.dat.bak | db_load new.dat
 73 2016-02-26 12:42:58 <timothy> drizzt@liara .bitcoin % ~/trunk/src/db4/bin/db_verify new.dat && echo OK
 74 2016-02-26 12:43:00 <timothy> OK
 75 2016-02-26 12:43:07 <timothy> (for example)
 76 2016-02-26 12:43:24 <timothy> but I'm sure the original wallet.dat was created by 5.3.28
 77 2016-02-26 13:27:29 <TZander> timothy: for what its worth, I never really had any issues with changing versions.  We don't exactly use a lot of database features, so less opportunity to go wrong :)
 78 2016-02-26 14:49:03 <timothy> [semi-OT] is there any FAQ-collector about the blockchain size debate? I always have to explain this to people
 79 2016-02-26 15:54:55 <Chris_Stewart_5> SIGHASH_ANYONECANPAY is used in conjunction with the other three hash types?
 80 2016-02-26 20:49:54 <kanzure> timothy: there's no faq-collector to my knowledge, but i have a very large number of links on many topics, which i can provide to you if you were interested in compiling a faq (or actually, even if you weren't interested in doing that)
 81 2016-02-26 21:25:20 <slaughlin> I am trying to enable many people to send bitcoin to a particular wallet. A sender would visit a web page which displays an address associated with the destination w
 82 2016-02-26 21:25:22 <slaughlin> allet. By virtue of the nature of the web, many people could of course be viewing this web page at the same time. Would it be appropriate for me to generate a new ad
 83 2016-02-26 21:25:24 <slaughlin> dress each time this web page is viewed?
 84 2016-02-26 21:25:51 <slaughlin> (apologies for the formatting)
 85 2016-02-26 21:26:26 <slaughlin> I see that other services do not generate a new address each time the page is rendered.
 86 2016-02-26 21:28:30 <slaughlin> For example, changetip displays the same address each time the page is rendered. When that address is used, changetip will create a new address, but not until that point in time.
 87 2016-02-26 21:29:47 <slaughlin> For changetip's approach, I think addresses will inevitably be reused, and I know that is less than ideal.
 88 2016-02-26 21:30:41 <slaughlin> But it seems to me that the only way to ensure that addresses are not reused would be to generate and display a new address each time the page is rendered
 89 2016-02-26 21:31:43 <slaughlin> Of course that could potentially mean generating thousands/millions of addresses that will never be used
 90 2016-02-26 21:32:33 <slaughlin> I'm new here and have no idea how active this channel is, but any input would be greatly appreciated, thanks.
 91 2016-02-26 21:36:58 <sturles> Addresses is not a limited resource.  You can generate as many as you want.  The rest og the network will never know unless the address is used.
 92 2016-02-26 21:39:54 <Luke-Jr> slaughlin: if the same address is ever given twice for two different transactions, it is a bug
 93 2016-02-26 21:50:27 <slaughlin> sturles: Great, thank you for that verification.
 94 2016-02-26 21:51:59 <slaughlin> Luke-Jr: Thanks, that certainly seems to be the consensus of all the resources I've been reading. Unless I'm missing something, ChangeTip is certainly exhibiting this bug.
 95 2016-02-26 21:53:15 <slaughlin> They seem to be making the assumption that tips will come in gradually/infrequently enough that the address will always be refreshed and unique
 96 2016-02-26 21:53:47 <slaughlin> There's no way that holds true all the time, though.
 97 2016-02-26 22:48:26 <wallet42> i see all these DEPRECATED warning on account functions
 98 2016-02-26 22:48:45 <wallet42> is the whole account feature beeing removed? when?
 99 2016-02-26 22:48:54 <wallet42> what is the recommended alternative?
100 2016-02-26 22:56:11 <helo> wallet42: the alternative depends what you're using it for, but most inquiries like this are from small businesses/operations that are trying to track customer funds using the accounts feature, and that is better served by tracking customer balances in a relational database