1 2014-07-13 02:02:00 <fredo89> hi
 2 2014-07-13 02:02:26 <fredo89> who know primedice ?
 3 2014-07-13 07:43:40 <michagogo> Luke-Jr: it would be much less confusing to people like cronus if you just explain that you're talking about when a output sent to that address is spent.
 4 2014-07-13 07:43:45 <michagogo> 17:23:15 <CodeShark> when sending a transaction, you provide a challenge script. to claim the value, someone needs to provide a solution script. in other words, when you append the solution script to the challenge script and run it, it must evaluate to true
 5 2014-07-13 07:43:58 <michagogo> CodeShark: erm, almost. It used to work like that.
 6 2014-07-13 07:44:31 <michagogo> Well, it was the other way around -- you appended the challenge script to the solution script
 7 2014-07-13 07:45:23 <michagogo> These days, though, it's not appended
 8 2014-07-13 07:45:32 <michagogo> The scriptSig is executed
 9 2014-07-13 07:45:55 <michagogo> And then the stack from running the scriptSig is carried over as the starting state of the scriptPubKey
10 2014-07-13 07:46:56 <michagogo> So the scriptSig is basically setting the stage for a successful execution of the scriptPubKey
11 2014-07-13 07:47:23 <michagogo> Which is why, in general, scriptSigs will only be data pushes
12 2014-07-13 07:48:43 <michagogo> 17:28:02 <earlz> I still don't completely understand how p2sh works at a technical level heh
13 2014-07-13 07:49:09 <michagogo> Essentially, there's a special format of scriptPubKey
14 2014-07-13 07:49:51 <michagogo> That format looks like it should just mean "show me the data that hashes to this hash", but it's special-cased
15 2014-07-13 07:53:29 <michagogo> When that template is seen, it does do that -- it checks that the top item on the stack does hash to that hash, but it doesn't stop there. It then takes that top item and treats *that* as the scriptPubKey and checks the rest of the scriptSig against that.
16 2014-07-13 08:18:50 <mn3monic> !tip tbtc mi4sYxU4rMrYWegZxcFXgZrEpmz6k9FJYk thnx :-)
17 2014-07-13 08:18:51 <gribble> Error: "tip" is not a valid command.
18 2014-07-13 08:18:56 <mn3monic> !help
19 2014-07-13 08:18:57 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
20 2014-07-13 09:28:11 <gribble> TP's TestNet Faucet: <http://tpfaucet.appspot.com/>; Testnet - Bitcoin: <https://en.bitcoin.it/wiki/Testnet>; Mojocoin Testnet3 Faucet: <http://faucet.xeno-genesis.com/>
21 2014-07-13 09:28:11 <michagogo> mn3monic: ,,(google bitcoin testnet faucet)
22 2014-07-13 09:56:55 <sl01> iddo: are recomputations of HD addresses really that expensive ?
23 2014-07-13 10:05:10 <iddo> sl01: see all the quoted posts in post #143 etc.
24 2014-07-13 10:51:16 <michagogo> Eh?
25 2014-07-13 10:52:11 <michagogo> Who's closer?
26 2014-07-13 16:14:25 <cronus> leaving bitcoind running seems to eventually use up almost all of my ram by filling the disk cache with the blockchain? Is there a way for it to not do this?
27 2014-07-13 16:15:44 <cronus> jk http://www.linuxatemyram.com/
28 2014-07-13 16:17:10 <sipa> cronus: disk cache is volatile
29 2014-07-13 16:17:26 <sipa> if something else needs it, it will remove those cached blocks
30 2014-07-13 16:17:44 <sipa> ah
31 2014-07-13 16:17:49 <sipa> didn't check the link :)
32 2014-07-13 16:51:05 <xenog> I believe I found a bug in AddTimeData
33 2014-07-13 16:51:12 <xenog> src/timedata.cpp
34 2014-07-13 16:52:22 <xenog> vTimeOffsets is established to contain up to 200 elements, and after the CMedianFilter data structure named vTimeOffsets is contains 200 elements, whenever a new element gets added, the oldest one gets removed
35 2014-07-13 16:53:26 <xenog> that means that the vTimeOffsets structure will always have 200 elements after this point, and never "vTimeOffsets.size() % 2 == 1" will be true in the future, therefore freezing the value of nTimeOffset to that when the data structure had 199 elements
36 2014-07-13 16:54:24 <xenog> I haven't found any code that removes elements from the vTimeOffsets data structure, therefore I must assume that this is a bug
37 2014-07-13 16:55:12 <xenog> I'll report the issue since it seems no core developer is currently around to discuss this
38 2014-07-13 17:04:52 <xenog> https://github.com/bitcoin/bitcoin/issues/4521
39 2014-07-13 17:39:34 <maaku> xenog: make an issue
40 2014-07-13 17:43:17 <michagogo> maaku: uh, he did, and linked to it
41 2014-07-13 18:11:11 <sipa> ;;nethash
42 2014-07-13 18:11:13 <gribble> 133935891.872
43 2014-07-13 19:33:00 <syntheticsky> anyone interested in creating a new altcoin around the concept of AI (artificial intelligence), please /join #syntheticsky
44 2014-07-13 19:37:45 <justanotheruser> syntheticsky: OT
45 2014-07-13 20:16:07 <iwilcox> Berkeley DB is only used for wallet.dat, right?
46 2014-07-13 20:16:19 <kazcw> yeah
47 2014-07-13 20:16:54 <sipa> yes
48 2014-07-13 20:17:26 <iwilcox> Thanks.  Context is editing some Debian build instructions; would be nice to mention the old db version is an unnecessary complication if you're disabling wallet support on your build, so I thought I'd check.
49 2014-07-13 20:18:51 <sipa> feel free to mention that
50 2014-07-13 20:19:04 <sipa> --disable-wallet at compile time indeed removes the BDB dependency
51 2014-07-13 20:23:50 <Forex> maaku: how is trustless exchange coming along?
52 2014-07-13 21:18:11 <super3> hello
53 2014-07-13 21:53:26 <deego> Hi. I have a satoshi spam transaction in my satoshi wallet (the guy who sends 1 satoshi to everyone.) It has had 300 confirmations, yet greyed out. I'm wondering why it should be greyed out.
54 2014-07-13 21:55:15 <deego> It says (XXX confirmations, but doesn't say: Broadcast through 8 nodes) after that.
55 2014-07-13 21:57:05 <deego> I guess I just hope the satoshi client knows how to ignore these gracefully, and that it won't cause a problem when i'm trying any sends in future.. :)
56 2014-07-13 22:03:33 <sipa> deego: the cost more in fees to spend than they're worth, so why would you use them?
57 2014-07-13 22:03:37 <sipa> *they
58 2014-07-13 22:08:40 <deego> sipa: oh, i don't want to use them.
59 2014-07-13 22:09:03 <deego> i'm just (1) curious about grey (2) hope it doesn't cause problem.s
60 2014-07-13 22:09:47 <sipa> i assume that's why they're grey
61 2014-07-13 22:09:58 <deego> i see
62 2014-07-13 22:10:19 <sipa> but i'm very not up to date with bitcoin-qt
63 2014-07-13 22:10:29 <deego> that is, (3) doesn't the wallet automatically try to use them at some point? and could that cause a problem if it tries to use a grey input?
64 2014-07-13 22:10:39 <deego> i guess it knows to skip them..
65 2014-07-13 22:10:50 <deego> sipa: ok, and thanks for responidng.
66 2014-07-13 22:12:14 <sipa> i assume it will ignore them