1 2016-01-12 14:49:36 <Diablo-D3> http://blogs.msdn.com/b/rds/archive/2016/01/11/remote-desktop-protocol-rdp-10-avc-h-264-improvements-in-windows-10-and-windows-server-2016-technical-preview.aspx
  2 2016-01-12 19:08:44 <lorenzoasr> hi, i'm using regtest to do some tests. If I send a transaction using "sendtoaddress" rpc command the transaction that has been created has the "locktime" field != 0, is this behavior normal ?
  3 2016-01-12 19:08:59 <sipa> yes, anti fee sniping
  4 2016-01-12 19:10:59 <lorenzoasr> thank you for reply. Never heard "fee sniping", is there some documentation about ?
  5 2016-01-12 19:12:57 <lorenzoasr> https://github.com/bitcoin/bitcoin/pull/2340
  6 2016-01-12 19:13:02 <lorenzoasr> ok found something interesting
  7 2016-01-12 19:34:37 <instagibbs> zookolaptop, (moved here) anyways, my original point was simply that his concerns had really nothing to do with soft/hard, but forking in general.
  8 2016-01-12 19:35:27 <Chris_Stewart_5> Could you have a p2sh output and a p2pkh output on a single address?
  9 2016-01-12 19:37:40 <zookolaptop> instagibbs: whose concerns?
 10 2016-01-12 19:39:29 <Luke-Jr> Chris_Stewart_5: outputs are not on addresses at all
 11 2016-01-12 20:04:31 <arubi> trying to understand how older clients parse 'extended transactions', specifically segwit kind, more specifically how is the head treated (dummy byte, flags).  at first glance, it seems like a zero input transaction?  documentation\file name where I can read about this will be helpful.
 12 2016-01-12 20:06:45 <arubi> maybe a segwit aware client won't bother relaying these type of transactions to older versions?  not sure.  thanks.
 13 2016-01-12 20:09:44 <Luke-Jr> arubi: correct, older versions never see the full tx
 14 2016-01-12 20:10:25 <arubi> thanks Luke-Jr.
 15 2016-01-12 20:11:21 <arubi> Luke-Jr, is "bool fHaveWitness" related?  is this the way the node decides whether to tell a peer about segwit transactions or not?
 16 2016-01-12 20:11:36 <Luke-Jr> I am not familiar with the code changes.
 17 2016-01-12 20:12:05 <arubi> ah, okay.  was just hunting sipa's branch.  thanks again
 18 2016-01-12 20:14:54 <Chris_Stewart_5> Luke-Jr: how is the 'addresses' field derived for json formats when you use 'getrawtransaction' with the 1 parameter to display it in json
 19 2016-01-12 20:16:01 <instagibbs> zookolaptop, wangchun
 20 2016-01-12 20:16:03 <instagibbs> 's
 21 2016-01-12 20:16:18 <Chris_Stewart_5> i.e. ./bitcoin-cli -testnet getrawtransaction ea82b8377f5918aa86f2d2dfaecbe788fc11596215f0f79603a51fed02ffc59e 1
 22 2016-01-12 20:17:18 <arubi> Chris_Stewart_5, an address is just a representation of a scriptpubkey.  if it's a p2pkh, it's "1..", if it's p2sh, it's "3..."
 23 2016-01-12 20:18:30 <Luke-Jr> arubi: that's not correct
 24 2016-01-12 20:18:49 <arubi> er, sorry then.
 25 2016-01-12 20:19:09 <Chris_Stewart_5> arubi: So I was looking at this document and isn't an address just generated off of multiple pub keys?
 26 2016-01-12 20:19:19 <Chris_Stewart_5> or just one in the case of p2pkh
 27 2016-01-12 20:19:21 <Chris_Stewart_5> https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
 28 2016-01-12 20:19:33 <arubi> I was certain how an address looks like to your own node is just a product of the code you're running, and how it interprets the scriptpubkey
 29 2016-01-12 20:19:47 <Luke-Jr> addresses are opaque
 30 2016-01-12 20:20:09 <arubi> they are?  I had the wrong idea then
 31 2016-01-12 20:20:52 <arubi> Chris_Stewart_5, a version 1 can't have multiple (public) keys to it,  at least I'm almost sure
 32 2016-01-12 20:23:50 <Luke-Jr> arubi: without getting pedantic, at least :P
 33 2016-01-12 20:24:49 <arubi> Luke-Jr, I really thought about this before I said it :), aren't there less public keys than acceptable 32 bit numbers that are private keys?
 34 2016-01-12 20:25:23 <arubi> I mean, isn't the modulo bigger than the order?  you can see math is just a hobby for me :)
 35 2016-01-12 20:25:59 <Luke-Jr> I don't know math language :p
 36 2016-01-12 20:26:09 <arubi> haha, you and me both.
 37 2016-01-12 20:26:10 <Luke-Jr> but every private key has a public key, so..
 38 2016-01-12 20:26:28 <arubi> yea, but maybe one private key can have two?  I'm not sure
 39 2016-01-12 20:27:00 <Chris_Stewart_5> I think there is an operation you run on private keys that can derive many public keys depending on how many times you use that operation
 40 2016-01-12 20:27:06 <Luke-Jr> well, certainly for HD wallets they do (the seed in this case is the actual private key)
 41 2016-01-12 20:28:06 <arubi> yea but actual [priv -> ecmul -> pub].  Chris_Stewart_5 is right I think, two Y values I think
 42 2016-01-12 20:30:35 <arubi> original tangent again,  there are more public keys than rmd160 hashes. there probably are two public keys that hash to the same rmd160
 43 2016-01-12 20:31:29 <Chris_Stewart_5> also, I think how many times you actually run that operation ends up being your private key for your elliptic curve. If I remember correctly.
 44 2016-01-12 20:31:40 <sipa> an address is just a shorthand human readable notation for a specific scriptPubKey
 45 2016-01-12 20:31:50 <Chris_Stewart_5> I watched a eliptic curve crypto primer from this guy on youtube lol, the interesting part starts at 6:00 https://www.youtube.com/watch?v=dCvB-mhkT0w&list=PLkLgTq6RIpMTbIUxSfnMxCLEVa3Uuwk-9
 46 2016-01-12 20:31:57 <arubi> sipa, yes! that's what I was trying to say
 47 2016-01-12 20:32:16 <sipa> arubi: every single private key has exactly one public key
 48 2016-01-12 20:32:42 <Chris_Stewart_5> sipa: so it is always a one to one relationship between priv and pub keys?
 49 2016-01-12 20:32:49 <sipa> yes
 50 2016-01-12 20:33:00 <arubi> sipa, ah, okay.  it seemed at first there were less points than the P number (N == number of points?)
 51 2016-01-12 20:33:30 <sipa> N is around 2^256 - 2^128
 52 2016-01-12 20:33:41 <sipa> P is around 2^256 - 2^32
 53 2016-01-12 20:33:50 <sipa> there are N-1 valid private keys
 54 2016-01-12 20:34:18 <sipa> P is just the range of coordinates for public keys, not the number of public keys
 55 2016-01-12 20:34:37 <arubi> yes I thought N was the number of public keys
 56 2016-01-12 20:36:06 <arubi> sipa, "the range of coordinates", thanks.  I had an "awakening" moment there.
 57 2016-01-12 20:36:27 <Chris_Stewart_5> sipa: If an address is a human readable version for a script pub key how do you go from scriptPubKey -> address? What part of the scriptPubKey is hashed, or is it the entire thing?
 58 2016-01-12 20:36:35 <Chris_Stewart_5> I'm trying to follow this https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
 59 2016-01-12 20:37:07 <sipa> Chris_Stewart_5: it's the other way around; you can go from address to scriptPubKey, not the other way around
 60 2016-01-12 20:37:22 <sipa> not every scriptPubKey has a corresponding address
 61 2016-01-12 20:38:02 <sipa> a v0 address represents a pay-to-pubkey-hash scriot
 62 2016-01-12 20:40:17 <Chris_Stewart_5> sipa: So if I have a serialized pubkey, I cannot figure out what address is related to that pubkey?
 63 2016-01-12 20:52:22 <Luke-Jr> [20:31:40] <sipa> an address is just a shorthand human readable notation for a specific scriptPubKey <-- I disagree; this misses the abstraction and opacity mattr
 64 2016-01-12 20:53:06 <sipa> Luke-Jr: the code constructing a transaction obviously has to break the abstraction
 65 2016-01-12 20:53:15 <sipa> anything else can treat it as a black box
 66 2016-01-12 21:01:50 <Chris_Stewart_5> scriptPubKey*
 67 2016-01-12 21:26:47 <paveljanik> sipa, can you please join #bitcoin-core-dev for a second?
 68 2016-01-12 21:34:23 <CodeShark> please don't, sipa
 69 2016-01-12 21:34:56 <CodeShark> :)
 70 2016-01-12 21:35:45 <paveljanik> CodeShark, :-)
 71 2016-01-12 21:49:02 <Chris_Stewart_5> Can you derive the amount of signatures required from a scriptPubKey for a p2sh addres? Or can you only determine that information when a scriptSig is submitted?
 72 2016-01-12 21:50:45 <instagibbs> You need the redeemscript, aka the thing hashed for p2sh address
 73 2016-01-12 21:51:03 <instagibbs> doesn't need to be "submitted"
 74 2016-01-12 21:51:05 <instagibbs> just known
 75 2016-01-12 21:51:27 <Chris_Stewart_5> instagibbs: thanks
 76 2016-01-12 22:13:20 <LeMiner> Throwing this out there; How viable would it be to test the upload speed for every node in the network by connecting to nodes one by one, getting an average and correlating that into a spreadsheet to see more or less the average upload speed we currently have available per node?
 77 2016-01-12 22:13:55 <LeMiner> by requesting blocks obv.
 78 2016-01-12 22:14:41 <LeMiner> It might map some interesting data
 79 2016-01-12 22:38:50 <Cryo> from nov -> jan, hashrate has doubled.  Is there some new hardware that came out?
 80 2016-01-12 22:39:19 <Cryo> or is this part of the testing for block size differences?
 81 2016-01-12 22:40:23 <brg444> Cryo AFAIK both BW and BitFury put out significantly more efficient chips
 82 2016-01-12 22:41:29 <Cryo> ok, that would make sense. thanks.
 83 2016-01-12 23:03:01 <bsm117532> CLTV is active on mainnet right now, correct?
 84 2016-01-12 23:03:24 <AaronvanW> yes
 85 2016-01-12 23:03:44 <bsm117532> What's the status of CSV?
 86 2016-01-12 23:25:45 <Guest5203> Hi dev team. I don't know the technical side well enough, but I wondered how viable it was to have some sort of additional blockchain built into bitcoin that exists to measure block propogation. Perhaps people sign something as soon as they have recieved a full block, with a hash that proves they have. This could give useful metrics on block propogation. Perhaps some sort of small reward at random based on a hash of all the e
 87 2016-01-12 23:26:37 <Guest5203> Then the health of the network can be accurately monitored
 88 2016-01-12 23:26:39 <kanzure> Guest5203: for a description of block propagation measurements that have been made, see http://diyhpl.us/wiki/transcripts/gmaxwell-2015-11-09-mining-and-block-size-etc/ (although it's missing rusty's corpus and jtoomim's corpus)
 89 2016-01-12 23:26:56 <kanzure> (this also does not include simulators or emulators)
 90 2016-01-12 23:27:53 <jtoomim> there is also Lightsword's poolbench tool
 91 2016-01-12 23:28:02 <jtoomim> i'll let him link that if he wants to
 92 2016-01-12 23:29:05 <Lightsword> you can link to it
 93 2016-01-12 23:29:17 <jtoomim> Guest5203 kanzure http://poolbench.antminer.link/
 94 2016-01-12 23:31:05 <Luke-Jr> jtoomim: that doesn't measure network propagation though
 95 2016-01-12 23:32:06 <Luke-Jr> in fact, can't really do that accurately unless you kill the relay network for a day
 96 2016-01-12 23:32:25 <jtoomim> luke-jr that's accurate. it's just a related tool.
 97 2016-01-12 23:42:55 <Guest5203> I'll have a more detailed read of greg's presentation tomorrow, thanks for the link, looks interesting.
 98 2016-01-12 23:44:26 <Guest5203> I'm just wondering if we can use the decentralised, neutral and rewarding nature of bitcoin to obtain statistics that could be useful for minitoring network health. These numbers could be very useful when people mindlessly start talking about massive blocks if there's a "health" metric that is clearly stuggling as blocks grow.
 99 2016-01-12 23:44:35 <Guest5203> *monitoring
100 2016-01-12 23:45:01 <Guest5203> But it may be unrealistic pie in the sky
101 2016-01-12 23:50:55 <fam17> What happens if a TX sent from btcoin-qt is still unconfirmed after 50 hours? Will it ever come back?
102 2016-01-12 23:54:52 <Luke-Jr> Guest5203: blocknotify may be a practical way to do it..
103 2016-01-12 23:55:08 <Luke-Jr> fam17: as long as Core is running, it will rebroadcast until it gets mined
104 2016-01-12 23:55:42 <fam17> Thanks, yes have left the wallet open to keep trying until it goes through