1 2013-08-14 00:14:11 <Luke-Jr> anyone know how to decode Armory signatures?
2 2013-08-14 00:15:37 <warren> gavinandresen: is the design of smarter transaction fee written anywhere?
3 2013-08-14 00:15:42 <warren> or the guist of it?
4 2013-08-14 00:17:19 <gavinandresen> warren: nope. I'm going in a slightly different direction than what I wrote about before. No change to miners, this is just getting the client to make a better estimate about what fee or priority is required to get into one of the next few blocks.
5 2013-08-14 00:18:11 <warren> gavinandresen: based upon averages or something from past blocks?
6 2013-08-14 00:19:03 <warren> sounds like the beginnings of a market demand driven floating fee, perhaps as guidance to the user to choose their fee level based upon their appetite for delay?
7 2013-08-14 00:19:44 <gavinandresen> based on transactions in the last N blocks. (and before somebody tells me I'm being an idiot and miners will collude to increase transaction fees??? yes, I'm thinking about that)
8 2013-08-14 00:20:23 <CodeShark> wouldn't you also need to take the mempool into account?
9 2013-08-14 00:20:28 <warren> exactly
10 2013-08-14 00:20:31 <gavinandresen> warren: yes, once I've got the low-level estimation done I plan on percolating it up into a better fee-choosing GUI
11 2013-08-14 00:20:34 <warren> mempool can tell you something about current demand
12 2013-08-14 00:22:11 <gavinandresen> mempool works great if you're constantly connected, and implementing a memory-limted mempool and then re-using this code to estimate priority/fee based on memory pool should be easy
13 2013-08-14 00:22:24 <CodeShark> and even then, a mempool snapshot might not be sufficient for good heuristics - you might need to track the mempool over some time period
14 2013-08-14 00:22:51 <gavinandresen> ANYTHING is better than the hard-coded constants we have now.
15 2013-08-14 00:23:13 <CodeShark> well, hardcoded constants suck but at least they are easy to predict :)
16 2013-08-14 00:23:25 <gmaxwell> gavinandresen: well, you can fetch the mempool.
17 2013-08-14 00:23:41 <gavinandresen> gmaxwell: mmm. If you trust who you're fetching from....
18 2013-08-14 00:23:52 <gavinandresen> (yeah, yeah, can fetch from N peers....)
19 2013-08-14 00:24:02 <gmaxwell> ::nods::
20 2013-08-14 00:24:04 <warren> as SPV clients aren't privy to the mempool state (and last-N blocks of transactions?), I had been thinking about various subscription services that users could opt-in to that follow recent fee behavior to serve as guidance on the appropriate fee level to choose depending on how long they want to wait. External monitoring agencies can also examine blocks from pools to detect mining policy changes and collusion, allowing the public interesting fo
21 2013-08-14 00:24:04 <warren> dder for comment.
22 2013-08-14 00:24:36 <CodeShark> warren: SPV clients can grab the mempool off any full node
23 2013-08-14 00:25:03 <warren> and they just trust it?
24 2013-08-14 00:25:35 <CodeShark> in general they cannot ensure all the inputs connect - but there are ways around this limitation
25 2013-08-14 00:26:02 <gavinandresen> SPV clients don't know the fees associated with those transactions (unless I missed a nifty feature of the fetch-mempool functionality, which I admit I know nothing about)
26 2013-08-14 00:26:34 <CodeShark> gavinandresen: indeed, in general they cannot know the fees (another reason why the input amount should be stored in the transaction inputs)
27 2013-08-14 00:26:57 <CodeShark> but they can still construct a few transactions specifically to monitor fees
28 2013-08-14 00:27:16 <gavinandresen> NACK, no reason to put them in the inputs. Should be broadcast with the transaction, but that's a feature for another day
29 2013-08-14 00:27:27 <warren> It would be cool to have a way for all clients to monitor fee behavior to give guidance based entirely on the chain + mempool, but I suspect competing external agencies may be better able to do it with a world-wide view and better analysis capabilities than any individual node.
30 2013-08-14 00:28:01 <gavinandresen> here's where I say "okey dokey" and then go back to writing code....
31 2013-08-14 00:28:06 <gmaxwell> gavinandresen: you can get the average fees pretty easily from the coinbase.
32 2013-08-14 00:28:56 <CodeShark> the original reason I wanted them in the inputs was so that a minimal signing agent can construct a redeem script from an output and sign it without the risk of being tricked into thinking that a 100btc output was actually only 1 btc
33 2013-08-14 00:29:19 <CodeShark> the workaround being giving the signer the full transaction with that output
34 2013-08-14 00:29:27 <CodeShark> but that's a separate discussion
35 2013-08-14 03:45:47 <petertodd> gavinandresen: You going to weight the fee information by Bitcoin days destroyed?
36 2013-08-14 03:46:38 <petertodd> warren: IMO the #1 thing re: usability is to allow changing the fee after the fact - a slow transaction is a nuisance, but a stuck one really sucks.
37 2013-08-14 04:26:25 <turboroot> Can anybody expand upon this list? https://gist.github.com/turboroot/6144238
38 2013-08-14 04:26:30 <turboroot> Seems a bit short at the moment
39 2013-08-14 05:05:16 <Hadaka> b
40 2013-08-14 05:05:19 <Hadaka> whoops
41 2013-08-14 05:58:30 <Luke-Jr> turboroot: I'd suggest removing brainwallet, from the website at least <.<
42 2013-08-14 05:58:52 <Luke-Jr> turboroot: also, Armory is Python 2
43 2013-08-14 05:59:20 <Luke-Jr> turboroot: and P2Pool is twisted, which I'm not sure really counts as Python XD
44 2013-08-14 06:00:25 <Luke-Jr> turboroot: and listing BFGMiner before cgminer ;p
45 2013-08-14 06:04:05 <Luke-Jr> turboroot: the current cgminer is actually a fork of BFGMiner, fwiw
46 2013-08-14 06:16:20 <gmaxwell> turboroot: careful to take luke's suggestions with a grain of salt. Luke is a smart guy, but some of his positions are controversial and he won't always warn you which ones will get you into trouble. :)
47 2013-08-14 06:24:31 <abrkn> for an electrum chain, what is the chain code and what is the root code?
48 2013-08-14 06:50:49 <ThomasV> abrkn: electrum < 1.9 does not use bip32
49 2013-08-14 06:51:27 <ThomasV> check out the (unstable) 1.9 branch of electrum if you want bip32
50 2013-08-14 07:20:32 <Luke-Jr> gmaxwell: hey :<
51 2013-08-14 07:33:22 <kuzetsa> https://github.com/bitcoin/bitcoin/issues/2894 <-- fees are zero when I restarted just now... is that a hardcoded change from the older 0.005 or whatever it was?
52 2013-08-14 07:33:57 <kuzetsa> (I re-tested by changing to a non-zero fee, clicking apply, then restarting... it was back to zero)
53 2013-08-14 07:36:57 <fanquake> kutzetsa osx?
54 2013-08-14 07:37:26 <kuzetsa> fanquake: windows 7 x64
55 2013-08-14 07:42:43 <kuzetsa> why would you assume mac?
56 2013-08-14 07:43:51 <Luke-Jr> gmaxwell: btw, "large integer with a '.' inserted" parsing won't work :/
57 2013-08-14 07:44:09 <Luke-Jr> gmaxwell: I've seen bitcoind give values that break it I think :|
58 2013-08-14 08:47:53 <gribble> The expected generation output, at 330.0 Mhps, given difficulty of 50810339.0483, is 0.00326624764823 BTC per day and 0.00013609365201 BTC per hour.
59 2013-08-14 08:47:53 <sipa> ;;genrate 330
60 2013-08-14 08:57:41 <t7> not like back in the day, when my old ati could get .1 an hour
61 2013-08-14 10:22:24 <TD> good day
62 2013-08-14 10:29:03 <fanquake> kuzetsa Some of the settings are broken in the current osx release
63 2013-08-14 12:34:12 <jgarzik> http://bitcoinprbuzz.com/worlds-first-stolen-bitcoin-tracing-service-and-bitcoin-data-recovery-high-profile-digital-forensic-services-company-sytech-embraces-bitcoin/
64 2013-08-14 12:34:26 <jgarzik> World?s First Stolen Bitcoin Tracing Service And Bitcoin Data Recovery ? High Profile Digital Forensic Services Company SYTECH Embraces Bitcoin
65 2013-08-14 12:34:53 <petertodd> we really need to get trust free mixing widespread...
66 2013-08-14 12:35:14 <TD> heh
67 2013-08-14 12:35:20 <TD> this will always be a cat/mouse game
68 2013-08-14 12:36:04 <TD> it doesn't say that they plan to be specifically blockchain based anyway. it's a general data forensics company. i'd expect them to use all kinds of things
69 2013-08-14 12:36:15 <TD> they also do data recovery
70 2013-08-14 12:36:40 <michagogo> petertodd: That's as easy as a group of people getting together, telling each other which inputs they want to use for which outputs, and then passing the transaction around to sign, right?
71 2013-08-14 12:36:40 <petertodd> if you read the press release it sounds like they're grabbing a quick headline because they wrote a tool that looks for privkeys on harddrives - nothing fancy
72 2013-08-14 12:37:38 <petertodd> michagogo: yup, you can even do it in the face of adversaries delibrately trying to attack the process by using fidelity bonds or PoW to ensure there is an incentive to complete the mix, as well as making it expensive to be every participant in every mix (sybil attack)
73 2013-08-14 12:38:00 <michagogo> fidelity bonds or PoW? Hmm?
74 2013-08-14 12:38:12 <michagogo> I'm not sure I understand... what is there to attack
75 2013-08-14 12:38:13 <michagogo> ?
76 2013-08-14 12:38:18 <petertodd> https://en.bitcoin.it/wiki/Fidelity_bonds
77 2013-08-14 12:38:55 <TD> i have a case of a person who has managed to get a wallet that serializes to over 11mb of transactions in protobuf form. impressive.
78 2013-08-14 12:39:05 <petertodd> first of all you want to decouple the process of agreeing to put money in the mix, and asking for a specific output, or anyone can just track who put money in for what transaction outputs
79 2013-08-14 12:39:05 <TD> and it all adds up to just ~0.8 coins
80 2013-08-14 12:39:14 <TD> now blockchain won't let them spend their money
81 2013-08-14 12:39:24 <michagogo> TD: blockchain?
82 2013-08-14 12:39:30 <michagogo> do you mean bc.i?
83 2013-08-14 12:39:34 <petertodd> of course, a trusted third party can co-ordinate the mix, but obviously the third party can deanonymize you
84 2013-08-14 12:39:35 <TD> yeah
85 2013-08-14 12:40:28 <TD> the error message it gives is quite confusing and poorly written i must say. i think it's trying to say that there are unconfirmed transactions in the wallet, though i can't actually find any myself
86 2013-08-14 12:40:39 <petertodd> on the other hand, if there isn't a link between putting money in the mix, and specifying transaction outputs, someone can DoS attack the mixing process by simply not signing for the inputs they specified - hence a PoW or fidelity bond to make doing that expensive enough that people can't easily attack it
87 2013-08-14 12:40:43 <TD> or possibly that trying to spend the money results in a transaction so gigantic that it consumes nearly all the money in fees
88 2013-08-14 12:40:48 <TD> not sure which
89 2013-08-14 12:40:51 <TD> will require some debugging
90 2013-08-14 12:42:21 <michagogo> petertodd: Erm, but how can you ensure that the person putting the money in is the same person putting an output in?
91 2013-08-14 12:42:31 <michagogo> Oh, wait, ignore that.
92 2013-08-14 12:58:08 <TD> petertodd: you will find this paper interesting
93 2013-08-14 12:58:09 <TD> http://css.csail.mit.edu/6.858/2013/readings/intel-sgx.pdf
94 2013-08-14 14:01:46 <nsh> comment? http://www.forbes.com/sites/kashmirhill/2013/08/12/every-important-person-in-bitcoin-just-got-subpoenaed-by-new-yorks-financial-regulator/
95 2013-08-14 14:03:16 <Graet> yeah most agree "some US based bitcoin businesses" would have been a more accurate title
96 2013-08-14 14:05:01 <gmaxwell> ACTION is happy to be unimportant
97 2013-08-14 14:06:41 <handle> lol
98 2013-08-14 14:45:13 <helo> did any devs get subpoenaed?
99 2013-08-14 14:47:04 <handle> nope
100 2013-08-14 14:47:08 <handle> just companies
101 2013-08-14 16:01:37 <jgarzik> ProcessMessage(getblocks, 902 bytes) FAILED
102 2013-08-14 16:01:37 <jgarzik> ProcessMessages(getblocks, 902 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
103 2013-08-14 16:01:49 <jgarzik> ACTION wonders what software generated that
104 2013-08-14 16:49:08 <diki> so slow
105 2013-08-14 16:49:13 <diki> the syncing these days is so slow
106 2013-08-14 17:00:32 <Zoop_> download the blockchain from a torrent
107 2013-08-14 17:00:39 <Zoop_> diki ^
108 2013-08-14 17:00:48 <diki> oh it was just 3 days
109 2013-08-14 17:00:51 <diki> but it took forevef
110 2013-08-14 17:00:53 <diki> forever*
111 2013-08-14 17:01:03 <diki> Glad to say I just paid to the humble bundle via Bitcoin
112 2013-08-14 17:01:09 <diki> I am thankful it has expanded to accept it