1 2013-09-10 00:00:48 <gmaxwell> Krellan__: as far as advanced features go, I think it would be more interesting to make the gui console more powerful. E.g. so you could do things like right click on a txid in a getrawtransaction output and have it run getrawtransaction on that txid.
2 2013-09-10 00:01:30 <gmaxwell> or replace the console with a box that brings up a python (or whatever) interperter with a good liberary loaded for speaking to the node.
3 2013-09-10 00:01:50 <gmaxwell> The problem with GUIs for "advanced" features is that they only work well for whatever narrow set of "advanced" you can predefine.
4 2013-09-10 00:02:13 <gmaxwell> The space of what people can do with bitcoin is so insanely broad, nothing we can do with an advanced interface would fail to be confining.
5 2013-09-10 00:02:42 <gmaxwell> So I would instead prefer to make a real advanced interface more accessible and then take the good things people invent in that space and make them regular (non-advanced) features.
6 2013-09-10 00:04:19 <Krellan__> Makes sense to me.
7 2013-09-10 00:05:22 <Krellan__> A worthy project would be to separate the GUI from bitcoind entirely, make the GUI operate 100% over RPC.
8 2013-09-10 00:05:55 <gmaxwell> e.g. from _my_ advanced interface, which is ... bash plus bitcoind answering complicated questions like "show me any non-version 1 transactions in the last 288" blocks is a (for i in {257023..256735} ; do echo $i ; ./bitcoind getblock `./bitcoind getblockhash $i` | grep ' "' | cut -d'"' -f2 | xargs -n1 -iblah ./bitcoind getrawtransaction blah 1 | grep -B 1 'ersion" : [^1]' ; done) away.
9 2013-09-10 00:06:32 <Krellan__> Nice. Find any more? I wonder if somebody was experimenting with fuzzing various fields in the TX?
10 2013-09-10 00:06:55 <gmaxwell> Apparently it was a bug in genjix's SX wallet code.
11 2013-09-10 00:07:06 <gmaxwell> Krellan__: no more yet.
12 2013-09-10 00:07:37 <gmaxwell> fortunately address reuse allowed me to deanonymize the guilty party and go ask them what happened!
13 2013-09-10 00:09:15 <gmaxwell> Another fun commandline added to my collection lately:
14 2013-09-10 00:09:21 <Krellan__> UTXO (standard form) contains a hash based on a signature, address is public key, signature requires matching private key, so could it be said that address ownership implies UTXO ownership?
15 2013-09-10 00:09:40 <Krellan__> with ownership defined as "I have the matching private key for that public key".
16 2013-09-10 00:09:48 <gmaxwell> $ ./bitcoind -rpcconnect=gbt.mining.eligius.st -rpcport=9337 -rpcuser=x -rpcpassword=x getblocktemplate '{"capabilities": ["coinbasetxn"]}' | grep `./bitcoind getrawtransaction b7574d16bcabd68f65286ca1648968ed8a7d9560c865c12051b33bfd4c8d7b7a` < Is eligius attempting to mine <txid>
17 2013-09-10 00:10:49 <Krellan__> nice, you can see if your TX has been accepted into the block being mined on that way.
18 2013-09-10 00:11:16 <gmaxwell> Krellan__: but it doesn't. MTGOX or Coinbase doesn't own the funds in your account, though they have the matching private keys.
19 2013-09-10 00:11:40 <gmaxwell> I'm not sure what you mean standard form there, P2SH addresses are IsStandard and could have any kind of rules the system can describe.
20 2013-09-10 00:12:00 <Krellan__> true. Only talking about address ownership, not who actually legally owns the funds there. I could be custodian of somebody else's funds and letting them use my addresses.
21 2013-09-10 00:13:06 <gmaxwell> Krellan__: for all I know you've managed to escrow your address into some kind of pycho multiparty computation.
22 2013-09-10 00:13:06 <Krellan__> by standard form I meant the really common script you see all the time (pay to pubkey hash).
23 2013-09-10 00:13:29 <Krellan__> CoinJoin?
24 2013-09-10 00:13:48 <Luke-Jr> Krellan__: addresses are just pointers, not objects.
25 2013-09-10 00:14:14 <Luke-Jr> Krellan__: the ECDSA keypair may be an object, but that is not an address itself
26 2013-09-10 00:14:31 <Luke-Jr> it's just part of the wallet
27 2013-09-10 00:15:15 <Krellan__> could I have more than one unique address that would both let me spend a particular UTXO that is pay-to-pubkey-hash, or does pay-to-pubkey-hash accept only one address as a valid solution?
28 2013-09-10 00:16:04 <Luke-Jr> Krellan__: addresses aren't solutions, they're templates for a scriptPubKey
29 2013-09-10 00:16:32 <Krellan__> by solution I meant "whatever makes the script return true so that I can spend the coins".
30 2013-09-10 00:17:07 <Krellan__> I think I have the idea right but not the semantics.
31 2013-09-10 00:17:21 <Luke-Jr> Krellan__: that's the ECDSA private key in this case
32 2013-09-10 00:18:19 <Krellan__> Yep. It matches an address, though, right? Address = public part of that keypair, I thought.
33 2013-09-10 00:18:48 <Luke-Jr> no
34 2013-09-10 00:18:58 <Luke-Jr> address *refers to* the keypair, but it's a one-way thing
35 2013-09-10 00:19:30 <Luke-Jr> (you *can* map from the ECDSA key to an address, but this is considered opaque outside of generating the address for people to send to)
36 2013-09-10 00:19:44 <gmaxwell> Really an address is just a shorthand template for some particular scriptpubkey form.
37 2013-09-10 00:19:47 <Luke-Jr> ^
38 2013-09-10 00:21:09 <gmaxwell> Krellan__: there are an ~infinite number of scriptsigs which will allow you to spend any particular pay-to-pubkey-hash UTXO.
39 2013-09-10 00:22:51 <gmaxwell> for example. PUSH("Quack. Quack. I'm a crazy spatula!") OP_DROP PUSH(signature) PUSH(pubkey)
40 2013-09-10 00:26:29 <gmaxwell> Krellan__: https://bitcointalk.org/index.php?topic=279249.0 is the CoinJoin reference.
41 2013-09-10 00:29:47 <Krellan__> Thanks. I meant only OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG.
42 2013-09-10 00:30:34 <gmaxwell> Krellan__: I was giving a scriptsig example, what you're giving there is a script pubkey.
43 2013-09-10 00:31:42 <Krellan__> Yep. The address influences the hash.
44 2013-09-10 00:32:16 <Luke-Jr> â¦
45 2013-09-10 00:32:33 <Luke-Jr> Krellan__: you're trying to make a link that simply doesn't exist
46 2013-09-10 00:33:11 <Krellan__> I'm probably missing something.
47 2013-09-10 00:34:24 <Luke-Jr> Krellan__: I think you want to fit "ownership" into some absurdly narrow definition that Bitcoin was not intended to convey it with
48 2013-09-10 00:40:02 <Krellan__> Bad choice of words on my part, then.
49 2013-09-10 00:40:46 <Krellan__> The address is the public key, right?
50 2013-09-10 00:43:16 <Luke-Jr> the address is just a pointer
51 2013-09-10 00:44:08 <Luke-Jr> it's a template for a BC (not ECDSA) public key technically, but that's a technical detail, not a user-end thing
52 2013-09-10 00:47:42 <gmaxwell> "OP_DUP OP_HASH160 <hash160> OP_EQUALVERIFY OP_CHECKSIG" is a bitcoin public key template, a 1xxx address means use that template with data in the xxx converted from base58 into binary and written into the <hash160> part.
53 2013-09-10 01:00:09 <Krellan__> gmaxwell: Yes, so that comes from the address, it plugs right into the template.
54 2013-09-10 01:01:13 <Krellan__> Is there a 1:1 mapping between an address and its template?
55 2013-09-10 01:03:19 <Krellan__> If there is a 1:1 mapping then you could say that one is merely an expanded, more verbose, form of the other.
56 2013-09-10 01:04:16 <Krellan__> And thus that there is a from address. Obviously I'm shortcutting something. Please correct my thinking.
57 2013-09-10 01:06:14 <gmaxwell> Krellan__: conventional software will display the same address for different scriptpubkeys, in fact.
58 2013-09-10 01:06:17 <gmaxwell> Krellan__: the stuff you've been talking about for the last hour really have nothing to do with your conclusion.
59 2013-09-10 01:07:53 <gmaxwell> Krellan__: I give you a transaction that pays you. By inspecting the public ledger, _but not the transaction itself_ you can determined what rules the value (coins) the transaction redeemed were previously assigned to.
60 2013-09-10 01:08:07 <gmaxwell> Addresses have absolutely nothing to do with this, they're a complete distraction.
61 2013-09-10 01:09:02 <gmaxwell> But knowing what rules the value being moved was previously assigned to tells you _nothing_ about who the transaction is from in theory, and in practice it sometimes tells you far lower than you might guess.
62 2013-09-10 01:09:53 <gmaxwell> So if you'd like to insist in insting you know a "from address", be my guested, I'm not president of the universe or anything. But it's been my expirence that that kind of thinking has caused people to lose funds.
63 2013-09-10 01:10:17 <gmaxwell> The system is what it is. Assigning names to things doesn't add value if the names remove clarity instead of adding it.
64 2013-09-10 01:16:13 <nsh> GMAXWELL FOR PRESIDENT OF THE UNIVERSE!!!
65 2013-09-10 01:16:21 <Krellan__> :)
66 2013-09-10 01:16:32 <Krellan__> Nice conclusion.
67 2013-09-10 01:16:46 <Cusipzzz> nsh: ++
68 2013-09-10 01:17:23 <nsh> HIS SUPPORT HAS LITERALLY DOUBLED IN THE LAST TEN SECONDS. THIS IS THE FASTEST GROWING POLITICAL MOVEMENT THE WORLD HAS EVER SHOUTED ABOUT IN CAPS FOR NO GOOD REASON
69 2013-09-10 01:17:35 <nsh> ACTION crawls back into his books
70 2013-09-10 01:41:29 <Andrevan> well I'm forming an anti-masonic party specifically targeting gmaxwell, although I doubt he is masonic, I just like the name
71 2013-09-10 01:42:59 <Luke-Jr> â¦
72 2013-09-10 02:09:37 <gmaxwell> Anyone know of an instance where someone has sent coin to an contrived (random value) pay to pubkey, other than 0?
73 2013-09-10 04:08:46 <hydromet> is it possible to generate a paper rendition of my bitcoin wallet using Bitcoin-Qt or the bitcoind daemon?
74 2013-09-10 04:09:53 <maaku> hydromet: not that i'm aware of, but there's a python bitcoin wallet tool
75 2013-09-10 04:10:21 <gmaxwell> hydromet: in git bitcoin-qt/bitcoind you can get a simple textfile output that can be easily printed.
76 2013-09-10 04:10:21 <maaku> which will dump out the whole wallet
77 2013-09-10 04:10:22 <hydromet> maaku: armory
78 2013-09-10 04:10:35 <gmaxwell> hydromet: spatula?
79 2013-09-10 04:10:45 <hydromet> gmaxwell: never heard of spatula
80 2013-09-10 04:11:07 <hydromet> I want to have a physical copy of my wallet
81 2013-09-10 04:11:26 <maaku> i was thinking of pywallet, but sure armory could probably handle that
82 2013-09-10 04:12:02 <gmaxwell> I'm pretty sure armory will do nothing with a bitcoin-qt wallet file. So that depends on what he means by "my bitcoin wallet"
83 2013-09-10 04:12:18 <hydromet> gmaxwell: wallet.dat
84 2013-09-10 04:12:19 <gmaxwell> hydromet: sorry, I couldn't figure out why you said armory there it seemed kinda random.
85 2013-09-10 04:12:58 <hydromet> gmaxwell: I meant the python based bitcoin armory wallet app
86 2013-09-10 04:13:23 <gmaxwell> what about it?
87 2013-09-10 04:28:27 <phantomcircuit> hydromet, you can dump the private keys using the rpc interface (help -> debug window)
88 2013-09-10 04:30:02 <gmaxwell> ls
89 2013-09-10 04:30:07 <Luke-Jr> hydromet: if you want a so-called "paper wallet", no. Bitcoin-Qt's wallet.dat is constantly changing, and needs to be re-backedup every 90 transactions or so
90 2013-09-10 04:30:16 <Luke-Jr> phantomcircuit: but people shouldn't do that.
91 2013-09-10 04:30:46 <gmaxwell> Luke-Jr: does anyone want us to keep wallets non-determinstic?
92 2013-09-10 04:30:54 <Luke-Jr> gmaxwell: I'm not aware of anyone
93 2013-09-10 04:31:25 <phantomcircuit> Luke-Jr, shrug as long as they're printing all of them including everytime a keypool key is elevated (lol yeah nobody will do that)
94 2013-09-10 04:32:01 <phantomcircuit> gmaxwell, well i have a healthy bit of caution about it
95 2013-09-10 04:32:02 <Luke-Jr> ACTION wonders if we should rename dumpprivkey to something random every release to discourage people from using it
96 2013-09-10 04:32:11 <gmaxwell> it would be pretty easy to split the keypool into two (change and not change), set the default size to 50000 and replaced the generate function with the BIP32 private derrivation code...
97 2013-09-10 04:32:21 <maaku> Luke-Jr: as far as i'm aware needs for non-determinism can be handled by multi-wallet support
98 2013-09-10 04:32:31 <gmaxwell> Luke-Jr: I can't wait for the first big extendpubkey+private break.
99 2013-09-10 04:32:38 <maaku> multi-HD-wallet
100 2013-09-10 04:33:10 <gmaxwell> maaku: back in early 2011 I got bludgeoned for suggesting we change, back then people wanted "unstealing"
101 2013-09-10 04:33:21 <Luke-Jr> lol
102 2013-09-10 04:33:35 <gmaxwell> I think multiwallet doesn't do anything relevant for non-determinism.
103 2013-09-10 04:33:38 <phantomcircuit> gmaxwell, unstealing o.o
104 2013-09-10 04:33:39 <gmaxwell> Does it?
105 2013-09-10 04:33:46 <Luke-Jr> gmaxwell: for backward compat, we might want to support both anyway
106 2013-09-10 04:33:59 <Luke-Jr> gmaxwell: multiwallet would mean a different HD chain for each
107 2013-09-10 04:34:00 <maaku> the point is people want keys that are not linked in any way
108 2013-09-10 04:34:22 <gmaxwell> maaku: thats not an application, thats a mechenism.
109 2013-09-10 04:34:41 <gmaxwell> phantomcircuit: the property that if you lose an old backup then someone who finds it will gradually be able to get less and less of your coin over time.
110 2013-09-10 04:34:58 <phantomcircuit> gmaxwell, oh...
111 2013-09-10 04:34:59 <phantomcircuit> hmm
112 2013-09-10 04:35:30 <phantomcircuit> something tells me that would in practice just lead to people not 100% breaking off that wallet chain
113 2013-09-10 04:35:38 <phantomcircuit> ie mistakes
114 2013-09-10 04:35:43 <gmaxwell> Luke-Jr: backwards compat? well I'd say you have a new wallet version, and if your wallet is upgraded to that version it adds a masterprivate key record and fills up the pools from it.
115 2013-09-10 04:36:09 <gmaxwell> phantomcircuit: I didn't consider it very compelling myself at the time, but back then it had its proponents.
116 2013-09-10 04:36:48 <hydromet> gmaxwell: sorry I had to step away from my computer ... regarding the armory app, it has an ability to print a paper rendition of a bitcoin wallet (if I'm not mistaken the printout includes a bar or QR code)
117 2013-09-10 04:37:24 <gmaxwell> hydromet: it has the ability to print a paper backup of an armory wallet. that functionality doesn't exist for bitcoin-qt and doesn't make sense yet.
118 2013-09-10 04:37:46 <hydromet> gmaxwell: doesn't make sense "yet" but will some day make sense?
119 2013-09-10 04:38:03 <gmaxwell> yes, the functionality will someday work for bitcoin-qt.
120 2013-09-10 04:38:06 <hydromet> gmaxwell: because Luke-Jr statd "Bitcoin-Qt's wallet.dat is constantly changing, and needs to be re-backedup every 90 transactions or so" ??
121 2013-09-10 04:38:17 <gmaxwell> correct.
122 2013-09-10 04:39:21 <hydromet> gmaxwell: great to know this ... I'm not sure how many people using Bitcon-Qt are aware that they need to back up their wallet every 90 transactions or so
123 2013-09-10 04:39:34 <hydromet> unless there is a wiki page about this stating so?
124 2013-09-10 04:39:41 <gmaxwell> There is. Several.
125 2013-09-10 04:39:47 <hydromet> ok
126 2013-09-10 04:41:09 <hydromet> phantomcircuit: thanks for the tip regarding dumping private keys
127 2013-09-10 04:43:06 <gmaxwell> hydromet: careful, a lot of people have lost funds while doing that and not completely understanding what they were doing.
128 2013-09-10 04:46:01 <hydromet> gmaxwell: what would you recommend? case in point, if I have some bitcions I'm saving in my wallet and something happens to me, I want my little brother to inherit them (but he's not as tech savvy as me), and so I would want him to have a paper version of my wallet which we could put in a physically safe place (like a physical bank vault)
129 2013-09-10 04:50:36 <Luke-Jr> hydromet: try a USB stick
130 2013-09-10 04:50:47 <Luke-Jr> hydromet: if that isn't good enough, switch to Armory temporarily
131 2013-09-10 04:56:07 <phantomcircuit> hydromet, long term media storage is a non trivial subject
132 2013-09-10 04:56:26 <phantomcircuit> do not expect normal paper to last long term
133 2013-09-10 04:56:34 <CodeShark> you should certainly store multiple copies
134 2013-09-10 04:56:41 <CodeShark> in different places
135 2013-09-10 04:56:52 <CodeShark> perhaps using different technologies
136 2013-09-10 04:57:09 <CodeShark> i.e. USB stick, CD, etc...
137 2013-09-10 04:57:56 <CodeShark> do NOT use a thermal printer :p
138 2013-09-10 04:58:19 <phantomcircuit> unless it's actually burning the paper
139 2013-09-10 04:58:27 <phantomcircuit> (jk)
140 2013-09-10 04:58:49 <phantomcircuit> acid free paper printed with a laser printer
141 2013-09-10 04:58:50 <phantomcircuit> magic
142 2013-09-10 04:59:03 <phantomcircuit> (ink jet with low quality ink will fade/migrate over time)
143 2013-09-10 04:59:50 <gmaxwell> I wouldn't count on USB lasting a long time.
144 2013-09-10 05:00:09 <CodeShark> yeah, I probably wouldn't either
145 2013-09-10 05:01:00 <CodeShark> there's something to be said for etching it on metal or stone
146 2013-09-10 05:01:55 <CodeShark> archaeologists would probably agree :)
147 2013-09-10 05:03:02 <CodeShark> old tech, but quite reliable
148 2013-09-10 05:04:56 <CodeShark> I guess the modern version is to use a laser
149 2013-09-10 05:06:09 <CodeShark> as in laser etching, not laser printing
150 2013-09-10 05:10:50 <CodeShark> inks can bleed and might be chemically unstable
151 2013-09-10 05:11:58 <CodeShark> and paper is certainly chemically unstable
152 2013-09-10 05:12:48 <CodeShark> not to mention biodegradeable, etc...
153 2013-09-10 05:13:55 <Luke-Jr> hmm, you're right
154 2013-09-10 05:14:04 <Luke-Jr> ACTION goes back to stashing gold in his backyard
155 2013-09-10 05:16:12 <CodeShark> I suppose today's printing technology can guarantee legibility for decades if not centuries at the very least, assuming the paper is kept in a dry, noncorrosive environment
156 2013-09-10 05:17:01 <gmaxwell> there is also ink and paper designed for archival..
157 2013-09-10 05:17:08 <CodeShark> but for comparison, stone can preserve a faithful copy for billions of years :)
158 2013-09-10 05:17:42 <weex> protip: get a kiln
159 2013-09-10 05:18:08 <CodeShark> and noble metals can as well, as long as they are kept well below melting temperature and not under high pressure
160 2013-09-10 05:19:56 <Luke-Jr> CodeShark: nobody cares about stuff in stone for even thousands of years
161 2013-09-10 05:20:25 <CodeShark> what do you mean?
162 2013-09-10 05:21:11 <magbo> Greetings, gentlemen. What is the common pattern to listen to the transactions that have a destination in a configurable list of addresses? -walletnotify is great, but it listens only to the addresses within a local wallet.
163 2013-09-10 05:21:56 <magbo> Also, for those who wonder â I've fixed testnet compatibility in pycoin.
164 2013-09-10 05:22:38 <Luke-Jr> magbo: just scan every block once it's 6 deep in the chain
165 2013-09-10 05:23:24 <magbo> Luke-Jr: ok! Thanks.
166 2013-09-10 05:23:47 <Luke-Jr> -blocknotify will tell yuo when there's a new one
167 2013-09-10 05:25:07 <magbo> Yeah, I know that ;) Thank you.
168 2013-09-10 05:25:14 <Luke-Jr> np
169 2013-09-10 05:25:59 <CodeShark> luke, geologists and paleontologists regularly look for clues etched in stone hundreds of millions or even billions of years ago :)
170 2013-09-10 05:26:47 <CodeShark> human written language has only really existed for several thousand years, though
171 2013-09-10 05:27:44 <Luke-Jr> CodeShark: maybe, but IMO who cares :P
172 2013-09-10 05:28:41 <CodeShark> granted, if people are still using bitcoin a billion years from now I'll be at the same time disappointed at the lack of technological innovation and astounded we're not yet extinct
173 2013-09-10 05:29:32 <phantomcircuit> Luke-Jr, that's hella slow
174 2013-09-10 05:29:46 <phantomcircuit> Luke-Jr, getblock doesn't return information about txouts
175 2013-09-10 05:29:57 <Luke-Jr> phantomcircuit: getrawtransaction in batches
176 2013-09-10 05:30:01 <phantomcircuit> so you end up calling getblock and getrawtransaction <txid> 1 for everything
177 2013-09-10 05:30:14 <phantomcircuit> Luke-Jr, it takes days/weeks to do that due to rpc overhead
178 2013-09-10 05:30:22 <Luke-Jr> phantomcircuit: it's 2 RPC calls
179 2013-09-10 05:30:33 <Luke-Jr> 2nd call gets all transactions at once
180 2013-09-10 05:30:38 <CodeShark> if you want a really fast notification mechanism, add a filter to https://github.com/CodeShark/CoinClasses/blob/master/examples/listener2/listener2.cpp
181 2013-09-10 05:30:42 <phantomcircuit> getrawtransaction doesn't take a list
182 2013-09-10 05:30:49 <Luke-Jr> phantomcircuit: JSON-RPC does
183 2013-09-10 05:30:58 <Luke-Jr> 2.0
184 2013-09-10 05:31:22 <phantomcircuit> Luke-Jr, well even with my hacked getrawtransactions it takes days to load them all
185 2013-09-10 05:32:01 <sipa> Krellan: making tools that only function for "the common case" implies you're working on infrastructure that enforcing limitation to the common case. Don't do that - don't assume from addresses exist or usable, and you get a much more scalable ecosystem
186 2013-09-10 05:32:10 <Luke-Jr> phantomcircuit: don't blame me, I made getblock return complete data originally :<
187 2013-09-10 05:32:46 <phantomcircuit> Luke-Jr, heh that's what i was about to do
188 2013-09-10 05:32:54 <phantomcircuit> instead i just ran 16 bitcoind instances
189 2013-09-10 05:33:01 <phantomcircuit> zfs snapshots ftw
190 2013-09-10 05:36:18 <tgerring> magbo, if there was a cloud service that you could use for transaction or block notifications, would it be something you'd be interested in using?
191 2013-09-10 05:36:59 <CodeShark> so much for the zero trust philosophy :p
192 2013-09-10 05:37:43 <tgerring> I don't think much trust is required to listen for notifications about public information?
193 2013-09-10 05:38:18 <CodeShark> an application developer would presumably be using these events to do things like trigger transaction processing
194 2013-09-10 05:38:46 <gmaxwell> YOU JUST GOT PAID A BILLION BITCOIN. CONGRATS.
195 2013-09-10 05:38:52 <CodeShark> lol
196 2013-09-10 05:39:11 <gmaxwell> https://people.xiph.org/~greg/21mbtc.png
197 2013-09-10 05:39:29 <Luke-Jr> tgerring: it makes no sense to JUST notify
198 2013-09-10 05:39:37 <Luke-Jr> the notification is that your local client has the block! :p
199 2013-09-10 05:39:54 <Luke-Jr> gmaxwell: I have 21 mBTC too!
200 2013-09-10 05:39:58 <tgerring> Luke-Jr, you've never sat around waiting for a deposit to confirm N blocks?
201 2013-09-10 05:40:13 <CodeShark> I let programs do that for me
202 2013-09-10 05:40:31 <CodeShark> :)
203 2013-09-10 05:40:42 <magbo> tgerring: I would be interested in building a distributed system that does this once transaction listening becomes a bottleneck in the system I'm working at ;)
204 2013-09-10 05:40:56 <CodeShark> there is a distributed system - it's called bitcoin
205 2013-09-10 05:40:57 <Luke-Jr> â¦
206 2013-09-10 05:41:00 <magbo> But such a distributed system should be deployable locally.
207 2013-09-10 05:41:14 <Luke-Jr> ACTION facepalms
208 2013-09-10 05:41:28 <magbo> And it's like 20LoC.
209 2013-09-10 05:41:54 <magbo> tgerring: So, no, I wouldn't.
210 2013-09-10 05:42:46 <magbo> Luke-Jr: uh wha? Doesn't it make sense to listen to txs in parallel across several nodes if one node fails to do that effectively?
211 2013-09-10 05:43:06 <magbo> to listen to txs that match a predicate, that is.
212 2013-09-10 05:43:41 <tgerring> Is there any scenario in which you could using an external service related to Bitcoin for your application?
213 2013-09-10 05:44:31 <CodeShark> it makes complete sense for an organization to run redundant listeners as part of their transaction processing IT infrastructure - it even makes sense for third parties to handle transaction processing as a service for third parties. but it doesn't really make sense for an application developer to rely on third party services for this
214 2013-09-10 05:44:48 <CodeShark> err, as a service for other companies
215 2013-09-10 05:44:48 <magbo> tgerring: I don't see any just yet.
216 2013-09-10 05:44:59 <CodeShark> if you can'
217 2013-09-10 05:45:03 <tgerring> Cool, I appreciate the input
218 2013-09-10 05:45:23 <CodeShark> if you can't run your own instances of verification nodes, you probably shouldn't be writing applications that handle any significant amounts of money
219 2013-09-10 05:46:07 <magbo> I want to type âthis^â but I'm not sure if it's acceptable here :)
220 2013-09-10 05:47:09 <tgerring> But if the environment was 100% buildable on your own hardware, it's something you'd be interested in?
221 2013-09-10 05:47:30 <CodeShark> application developers can indeed rely on libraries that run on their own devices - that's fine
222 2013-09-10 05:48:38 <tgerring> Do you think there's a service model that would exist in the space of licensing/support/etc. ?
223 2013-09-10 05:49:46 <CodeShark> I think the two approaches that make sense are either software components that provide these services to application developers - or transaction processing as a service, as in the processor would take care of all the infrastructure for you
224 2013-09-10 05:49:56 <gmaxwell> tgerring: the service model for that service appears to be to (1) offer it for free, and then (2) in 9 months get "hacked" and lots of people lose their bitcoins (3) profit (the mysterious step two has been solved, apparently)
225 2013-09-10 05:50:22 <tgerring> why is 2 inevitable?
226 2013-09-10 05:51:33 <CodeShark> if you're relying on a third party transaction processor, then you're not writing directly to bitcoin yourself
227 2013-09-10 05:52:04 <CodeShark> the transaction processor can just provide you with a very high level RESTful API or something
228 2013-09-10 05:53:15 <tgerring> and there's not value in having software that automates that build environment?
229 2013-09-10 05:54:04 <CodeShark> you could distribute binaries - or complete VMs, even
230 2013-09-10 05:55:18 <tgerring> as long as it's hosted on your own hardware?
231 2013-09-10 05:55:47 <CodeShark> there's also a business model for renting the capacity
232 2013-09-10 05:56:25 <tgerring> not sure I follow...
233 2013-09-10 05:56:51 <CodeShark> you don't necessarily need to own the hardware - you could rent it
234 2013-09-10 05:57:04 <CodeShark> either as VPSes or get colo or something
235 2013-09-10 05:57:48 <tgerring> what's the difference between that and spinning up an user-encrypted VM hosted by a "cloud" company?
236 2013-09-10 05:58:17 <CodeShark> decentralization
237 2013-09-10 05:58:20 <CodeShark> no single point of failure
238 2013-09-10 05:59:57 <tgerring> Not sure I'm sold on the the point, since part of the sell of cloud is redundancy. And with choice of cloud providers, it's not like a monopoly
239 2013-09-10 06:00:24 <tgerring> in my mind a VM is a VM
240 2013-09-10 06:02:13 <CodeShark> I just think that any serious application developer will probably want to run their own instances - and people who want someone else to handle all this infrastructure for them probably wants a higher level set of services, including full transaction processing, invoicing, etc...
241 2013-09-10 06:02:45 <tgerring> So you don't see any real space in the middle?
242 2013-09-10 06:03:44 <tgerring> bitcoin transactions aren't exactly the easiest thing to work with :D
243 2013-09-10 06:04:19 <CodeShark> I agree that the p2p protocol itself is too low-level for most application development. But I believe that the gap should be filled with libraries and runtime services
244 2013-09-10 06:04:33 <CodeShark> not third-party proprietary networks
245 2013-09-10 06:04:54 <tgerring> not sure how an open-source VM is a "proprietary" network.. but okay
246 2013-09-10 06:06:19 <CodeShark> VM hosting is ok - I thought you were referring to a third-party service that channels all your queries through their own network
247 2013-09-10 06:07:23 <tgerring> My basic idea is to provide a fully-prepared VM with up-to-date blockchain and authenticated RESTful API. It would contain source and be re-buildable at any point with ssh access. You'd own the environment.
248 2013-09-10 06:07:45 <CodeShark> that's fine - I have no problem with that model
249 2013-09-10 06:07:50 <tgerring> But I want to make it easy enough for Joe Developer to "spin up" in a few seconds and query against via simple REST calls
250 2013-09-10 06:08:14 <tgerring> gotcha
251 2013-09-10 06:09:07 <tgerring> right now, it's too hard for the average programmer to work with addresses and transactions and i feel like it's inhibiting potential application development
252 2013-09-10 06:09:35 <tgerring> so if there's a service I can build that people are interested in, I want to build it
253 2013-09-10 06:09:44 <CodeShark> indeed, I've spent the better part of the last couple years working to fill the gap between p2p and applications
254 2013-09-10 06:11:12 <tgerring> so if you could spin-up a fully loaded bitcoind VM as described above, is that something that you'd be interested in using? possibly in paying for as a service?
255 2013-09-10 06:11:43 <CodeShark> I'm more interested in being on the other end of that deal :p;
256 2013-09-10 06:12:23 <tgerring> hah
257 2013-09-10 06:12:54 <tgerring> fair enough :-p bitcoin has so much potential but the market is so small right now that trying to build a company seems infeasible
258 2013-09-10 06:14:14 <CodeShark> tgerring: I've been doing these sorts of things for a few clients the last couple years, but it's far from being commoditized where I can just sell it generically
259 2013-09-10 06:14:39 <CodeShark> well, perhaps not too far :p
260 2013-09-10 06:15:45 <tgerring> ACTION demands the future hurries up
261 2013-09-10 06:15:47 <CodeShark> but rather than selling the VM usage as a service, I'm more interested in a model that also includes technical support and app integration services
262 2013-09-10 06:16:08 <CodeShark> or rather, that is more based on these latter things than selling the VM usage as a service - perhaps licensing the VM
263 2013-09-10 06:16:38 <tgerring> I'm not opposed to any model that makes money
264 2013-09-10 06:18:50 <CodeShark> I agree there's no mass market for this kind of service right now - which is why it probably makes a lot more sense to focus on a few big clients
265 2013-09-10 06:18:50 <CodeShark> the mass market product would probably be the full transaction processing service (i.e. bitpay)
266 2013-09-10 06:19:25 <CodeShark> anyhow, this isn't #bitcoin-biz
267 2013-09-10 06:19:27 <CodeShark> :p
268 2013-09-10 06:21:52 <tgerring> sad empty chan :( thanks for the input. there's a thread i started over at bitcointalk if anyone cares to follow the discussion: https://bitcointalk.org/index.php?topic=289998
269 2013-09-10 07:48:19 <Krellan> sipa: Just read the scrollback now. Thanks for the advice earlier re the "common case".
270 2013-09-10 07:54:40 <sipa> in any case, if you work on infrastructure that requires that senders spend from conventional outputs, you're.artifically and unnecessarily restricting who can use it, and even if that's 99.9% of bitcoin users today, it will make it much hard to adopt more generic solutions later if everyone does this
271 2013-09-10 08:07:48 <Krellan> Agreed. Although I will agree "there is no from address", 99% of the time there is a de facto from address.
272 2013-09-10 08:08:07 <sipa> there is no useful from address
273 2013-09-10 08:08:37 <sipa> you can't use it for refunds wuthout knowing what software the sender used
274 2013-09-10 08:10:01 <sipa> assuming widespread address reuse, you could use it for detecting recurring customers, but that's a very weak test, and bad pracrice in any case
275 2013-09-10 08:11:01 <sipa> it is usefup when you're not using a wallet abstraction, and look at individual addresses all the way, but that risks causing a miaunderstandig about the system
276 2013-09-10 08:11:19 <sipa> and coin control provides much better transparency in that case
277 2013-09-10 08:11:45 <sipa> if you want to break the abstraction to be able keep addresses unlinked, multiwallet is a muxh better aolution
278 2013-09-10 08:12:29 <sipa> i hope we can evolve towards a world where we reason about wallets sending coina from/to eachother
279 2013-09-10 08:12:40 <TD> good morning
280 2013-09-10 08:12:44 <sipa> and addressea are an implementation detail that humans can ignore ezcept for debugging
281 2013-09-10 08:12:56 <sipa> the payment protocol is a step in that direction
282 2013-09-10 08:13:27 <sipa> hi there
283 2013-09-10 08:14:03 <TD> did someone change regtest mode to not use regular addresses?
284 2013-09-10 08:14:53 <Krellan> I wonder why Bitcoin-Qt uses "wallets" - it should just be a collection of addresses with an available balance on each address
285 2013-09-10 08:15:09 <Krellan> er "accounts"
286 2013-09-10 08:15:35 <Krellan> ideally each wallet would be a collection of addresses, and you'd be able to merge/split wallets up as desired.
287 2013-09-10 08:15:57 <sipa> Krellan: that's micromanagement
288 2013-09-10 08:16:00 <TD> merging a wallet would mean putting transactions on the network, too
289 2013-09-10 08:16:13 <sipa> Krellan: the point is exactly that humans shouldn't deal with individual addresses
290 2013-09-10 08:16:33 <sipa> wallet software can move coins around in addresses without human interaction
291 2013-09-10 08:16:34 <Krellan> no, I meant from local point of view only. Merging a wallet = walletA.dat + walletB.dat = walletAB.dat (new file created)
292 2013-09-10 08:16:51 <sipa> you can do that
293 2013-09-10 08:17:04 <Krellan> I like tagging every address I send/receive with a memorable name that reminds me who it was to/from
294 2013-09-10 08:17:05 <sipa> dump the keys from one wallet, import them in another
295 2013-09-10 08:17:25 <sipa> ok, how is that a problem?
296 2013-09-10 08:17:33 <phantomcircuit> sipa, he cant merge the labels
297 2013-09-10 08:17:34 <sipa> addresses are *entry* points into a wallet
298 2013-09-10 08:17:43 <sipa> they are not things that hold a balance
299 2013-09-10 08:17:54 <sipa> at least when lookwd at from the wallet abstraction
300 2013-09-10 08:18:16 <sipa> you can meaningfully define a balance per address, but that is micromanagement and causes misunderstansing
301 2013-09-10 08:18:39 <sipa> phantomcircuit: dump+import will in fact merge labels
302 2013-09-10 08:18:56 <Krellan> I think of it as a hierarchy: wallet contains 1 or more addresses, address contains the ability to satisfy conditions to spend 1 or more UTXO's, UTXO's have value denominated in BTC
303 2013-09-10 08:19:22 <sipa> yes, you like to reason about it as each address being an individual wallet
304 2013-09-10 08:19:31 <sipa> that is what coin control is for
305 2013-09-10 08:19:36 <sipa> if you want that level of control
306 2013-09-10 08:19:46 <Krellan> I really like coin control
307 2013-09-10 08:20:03 <sipa> but if you make that the default, you require people to understand low level details about the system
308 2013-09-10 08:20:10 <Krellan> coin control = Where's George for bitcoin :)
309 2013-09-10 08:20:42 <sipa> TD: they use testnet addresses, afaics
310 2013-09-10 08:20:53 <TD> sipa: not originally. only if someone changed it
311 2013-09-10 08:21:01 <sipa> really?
312 2013-09-10 08:21:07 <TD> i have someone saying that bitcoinj no longer accepts regtest addresses, and it seems somebody changed them to use testnet form
313 2013-09-10 08:21:20 <sipa> i'm the only one who touched that code, so that was probably me
314 2013-09-10 08:21:20 <TD> arguably that may have made more sense originally, but the way matt wrote it, it used regular v1 addresses
315 2013-09-10 08:21:33 <sipa> not realizing they were intended to use mainnet addresses
316 2013-09-10 08:21:36 <TD> any idea which commit it might have been?
317 2013-09-10 08:21:45 <sipa> bip32
318 2013-09-10 08:22:11 <sipa> can't reach right now, but it was part of the bip32 pullreq
319 2013-09-10 08:22:17 <sipa> alao, git blame is your friend
320 2013-09-10 08:22:24 <TD> hmm i reviewed that code and don't recall seeing such a change
321 2013-09-10 08:22:25 <sipa> *search
322 2013-09-10 08:22:25 <TD> yeah
323 2013-09-10 08:22:28 <TD> i'm fiddling with it now
324 2013-09-10 08:22:41 <TD> ah. "generalize version bytes"
325 2013-09-10 08:23:00 <sipa> testnet does make more sense imho, and maybe even something entirely different
326 2013-09-10 08:23:07 <TD> yes. you deleted that code block.
327 2013-09-10 08:24:05 <sipa> i probably didn't realize it was there to return it to mainnet bytes, or that it wasn't important as it was just for single-node testing
328 2013-09-10 13:25:33 <jgarzik> hum
329 2013-09-10 13:25:47 <jgarzik> ACTION was looking for PGP-in-the-browser
330 2013-09-10 13:26:15 <jgarzik> https://webpg.org seems like a candidate
331 2013-09-10 13:36:46 <TD> jgarzik: what does it mean to do pgp in the browser?
332 2013-09-10 13:36:59 <TD> at least on macos, gpg services lets you encrypt/decrypt in arbitrary text edit boxes
333 2013-09-10 13:55:22 <jgarzik> TD, I was thinking of PGP-JS as a solution for people who do not already have PGP software installed, and might find that cumbersome for whatever reason. i.e. when answering the question "how do you send PGP email to jeff garzik?" I can reply "gnupg on linux, gpgtools on osx, blahblah on windows, or $this in a JS-capable browser"
334 2013-09-10 13:56:00 <TD> i think the problems PGP has are not dislike of installing software, but rather mental overhead in setting it up and learning how to use it
335 2013-09-10 13:56:11 <jgarzik> a valid point
336 2013-09-10 13:57:22 <TD> IMHO it's better to use an entirely parallel mail system. stuff like OTR or PGP that piggybacks on existing channels is a good way to save effort, but ultimately the impedence mismatch creates a lot of problems
337 2013-09-10 13:57:39 <TD> so something like Pond or BitMessage or enhanced versions thereof
338 2013-09-10 14:50:20 <jonass> hmm? i'm trying to build bitcoin/master? strugle with the new autotools...
339 2013-09-10 14:50:32 <jonass> is there no chance to reopen the project in Qt-Creator?
340 2013-09-10 15:13:22 <jcorgan> do TXs get aged out of the mempool at some point? I can't find it in main.cpp; all I see is where mempool.remove is called in a couple different places in the chain reorg code logic
341 2013-09-10 15:16:11 <TD> jcorgan: no. well known problem
342 2013-09-10 15:16:23 <TD> matt wrote some code to try and fix that at some point but it bit-rotted and didn't get merged
343 2013-09-10 15:16:26 <jcorgan> TD: thanks
344 2013-09-10 15:16:53 <jcorgan> in #bitcoin we were discussing rebroadcasting an unconfirmed TX with a higher TX fee
345 2013-09-10 15:17:10 <jcorgan> but I though it wouldn't get relayed because the old one was still in the mempool of the neighbor nodes
346 2013-09-10 15:18:14 <TD> that won't work
347 2013-09-10 15:18:26 <TD> you're trying to double spend, and stopping that would be rather the whole point of bitcoin
348 2013-09-10 15:18:39 <jcorgan> yes, i agree, i assumed that's how it worked
349 2013-09-10 15:18:42 <TD> there are right fixes for that issue, such as child-pays-for-parent but unfortunately, again, the code for that has not been reviewed
350 2013-09-10 15:18:46 <TD> (although some was written)
351 2013-09-10 15:20:30 <jcorgan> thanks for confirming my understanding
352 2013-09-10 15:20:59 <ElevatioN> im an electronics engineering student, writing a paper on bitcoin, was wondering if anyone wanted to be interviewed
353 2013-09-10 15:22:22 <michagogo> ElevatioN: What kind of people are you looking for?
354 2013-09-10 15:23:23 <ElevatioN> anyone with technical knowledge, be it electronics, programming or even like econmics/ finance that wants to talk and talk and share information and maybe anwser some dumb questionsw
355 2013-09-10 15:24:24 <jcorgan> ElevatioN: just remember that anyone you interview is going to speaking as an individual, not on behalf of "bitcoin developers", even though you are in #bitcoin-dev
356 2013-09-10 15:24:27 <michagogo> TD: jcorgan: I think there *were* talks of allowing a transaction that would be an older unconfirmed transaction, but with one or more added inputs and zero or more added outputs
357 2013-09-10 15:25:22 <jcorgan> michagogo: yes, TD's comment reminded of the discussion on bitcointalk about that
358 2013-09-10 15:27:07 <ElevatioN> oh i know jcorgan
359 2013-09-10 15:27:11 <jcorgan> michagogo: but it would be hard to add just another TX input to add a TX fee without being able to add a change output
360 2013-09-10 15:27:14 <ElevatioN> thats alot what my paper is about
361 2013-09-10 15:27:21 <ElevatioN> the decentralized nature of bitcoin
362 2013-09-10 15:27:32 <ElevatioN> and why its important for the internet, freedom of information etc in general
363 2013-09-10 15:27:32 <michagogo> jcorgan: Well, not necessarily
364 2013-09-10 15:28:01 <michagogo> jcorgan: In theory you *could* create an output that is the size of the fee you're looking for
365 2013-09-10 15:28:45 <jgarzik> jcorgan, aging TX's out of the mempool has been a years-long wishlist item for me
366 2013-09-10 15:28:54 <jgarzik> IIRC I wrote a patch to do that, too
367 2013-09-10 15:29:00 <jgarzik> long since bitrotted
368 2013-09-10 15:29:37 <jgarzik> but TX determinism (or as near as we get) is a nice feature to have. Client already has responsibility to transmit until confirmed, so we should not let things linger in the mempool.
369 2013-09-10 15:29:40 <jcorgan> yes, in theory, but now this hypothetical TX replacement idea is getting complicated enough to be considered fragile in my mind
370 2013-09-10 15:29:45 <michagogo> ;;google bitrot
371 2013-09-10 15:29:46 <gribble> Bit rot - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Bit_rot>; bit rot - Catb.org: <http://www.catb.org/jargon/html/B/bit-rot.html>; Short Story: Bit Rot - Charlie's Diary - Antipope!: <http://www.antipope.org/charlie/blog-static/2013/06/short-story-bit-rot.html>
372 2013-09-10 15:30:48 <jcorgan> jgarzik: question for me is what a good age is
373 2013-09-10 15:30:59 <michagogo> jgarzik: Do you mean it in the sense of "dormant code rot, i.e. the fact that dormant (unused or little-used) code gradually decays in correctness as a result of interface changes in active code that is called from the dormant code."?
374 2013-09-10 15:31:04 <jgarzik> jcorgan, 24 hours | 48 hours | 1 week
375 2013-09-10 15:31:05 <jgarzik> no more
376 2013-09-10 15:31:30 <jgarzik> michagogo, it is a patch that has no hope of applying or working with current code in git master
377 2013-09-10 15:31:42 <jgarzik> the world Has Moved On
378 2013-09-10 15:32:32 <jcorgan> jgarzik: what are the objections to mempool aging?
379 2013-09-10 15:33:27 <jgarzik> jcorgan, also keep in mind an on-going proposal is to rewrite the mempool to behave as if it is a block of, say, 100MB in size. transactions that cannot be selected for this mega-block will simply be discarded as spam or junk. sometimes aging would naturally fall out of that.
380 2013-09-10 15:33:51 <jgarzik> jcorgan, objections? will just that it's complex and nobody has championed it as an ongoing effort yet
381 2013-09-10 15:33:56 <jgarzik> no real "don't do that"
382 2013-09-10 15:34:03 <jgarzik> *well
383 2013-09-10 15:34:16 <michagogo> jgarzik: Couldn't that 100MB block thing cause legitimate transactions to be discarded?
384 2013-09-10 15:34:21 <michagogo> It seems like a bad idea to me.
385 2013-09-10 15:34:34 <michagogo> (just first-glance reaction)
386 2013-09-10 15:35:03 <jgarzik> michagogo, if it doesn't fit with a mega-block, it will not get mined in the next many hours
387 2013-09-10 15:36:02 <michagogo> But will the transaction still exist on the sender's end?
388 2013-09-10 15:36:11 <michagogo> And therefore, tie up those coins in the client?
389 2013-09-10 15:36:47 <jgarzik> michagogo, The normal flow of a transaction is: create transaction, resend until confirmed.
390 2013-09-10 15:37:00 <michagogo> Oh, I forgot about the resending part
391 2013-09-10 15:37:03 <jgarzik> michagogo, Nothing changes from the client's perspective
392 2013-09-10 15:37:35 <michagogo> Personally I think it may be a good idea to have the transaction flood-filled, even if it's not stored in mempool
393 2013-09-10 15:37:42 <jgarzik> combined with TX mempool aging
394 2013-09-10 15:37:44 <michagogo> (or maybe removed from mempool after, say, 1 minute)
395 2013-09-10 15:37:53 <jcorgan> michagogo: easy DOS then
396 2013-09-10 15:37:55 <jgarzik> and clients may expire transactions, and resend them with higher fees, if it is taking too long to confirm
397 2013-09-10 15:38:03 <michagogo> That way the receiver will also have it to resend
398 2013-09-10 15:38:15 <jgarzik> michagogo, that's not how bitcoin works
399 2013-09-10 15:38:27 <michagogo> jgarzik: Do receivers not rebroadcast transactions?
400 2013-09-10 15:38:37 <jgarzik> michagogo, depends on the client. some do, some don't.
401 2013-09-10 15:38:38 <michagogo> (sent to their address, I mean)
402 2013-09-10 15:38:45 <jgarzik> michagogo, if you are smart, you do :)
403 2013-09-10 15:38:56 <michagogo> Does the reference client do it?
404 2013-09-10 15:39:05 <jgarzik> bitcoind rebroadcasts any IsMine(), yes.
405 2013-09-10 15:39:13 <michagogo> That's what I thought.
406 2013-09-10 15:39:58 <michagogo> So, a transaction that doesn't fit into the 100MB block should be relayed, even if not stored (assuming it passes the regular checks for relaying, ofc)
407 2013-09-10 15:40:53 <michagogo> So that the receiving node can see it, tell that it exists, and rebroadcast it later when there's less traffic or whatever
408 2013-09-10 15:41:34 <jgarzik> we mempool what we relay. I don't think we should relay spam.
409 2013-09-10 15:42:12 <jcorgan> jgarzik: isn't it the other way around--we only relay what makes it passed the checks to go into the mempool?
410 2013-09-10 15:42:16 <jgarzik> 100MB == 16 hours worth of blocks
411 2013-09-10 15:42:23 <jcorgan> s/passed/past/
412 2013-09-10 15:42:34 <jgarzik> jcorgan, don't read too much into English word ordering :)
413 2013-09-10 15:42:36 <michagogo> jgarzik: But if you limit mempool size, there may be something that would get relayed under current rules, but simply doesn't have space in the limited mempool
414 2013-09-10 15:42:41 <jgarzik> I consider it transitive
415 2013-09-10 15:42:55 <michagogo> And, there *are* some transactions that can take more than 16 hours to confirm
416 2013-09-10 15:43:17 <jgarzik> michagogo, yes they get retransmitted until they confirm
417 2013-09-10 15:43:28 <michagogo> Right, I know.
418 2013-09-10 15:43:32 <jgarzik> or not, if the client chooses to let expire
419 2013-09-10 15:43:34 <jcorgan> jgarzik: yeah, i'm being pedantic, a little burned out after 10 days on the road
420 2013-09-10 15:43:44 <jgarzik> and thus choose to rewrite with a higher fee, that will make it confirm
421 2013-09-10 15:43:45 <michagogo> But if it doesn't get relayed if it doesn't fit, the receiver doesn't hear of it
422 2013-09-10 15:43:54 <jgarzik> == free market, not our stupid fixed fee market
423 2013-09-10 15:44:01 <jgarzik> michagogo, correct
424 2013-09-10 15:44:08 <jgarzik> michagogo, and that's a good thing
425 2013-09-10 15:44:13 <michagogo> ...it is? o_O
426 2013-09-10 15:44:38 <jgarzik> michagogo, it's spam
427 2013-09-10 15:44:49 <michagogo> It opens up the door to "hey, you didn't send these bitcoins." "Yes I did..." if the sender doesn't keep the node running
428 2013-09-10 15:44:57 <michagogo> jgarzik: Not necessarily, if you limit mempool size
429 2013-09-10 15:45:02 <jgarzik> michagogo, that door has always been open
430 2013-09-10 15:45:12 <michagogo> jgarzik: Yes, for spammy transactions
431 2013-09-10 15:45:17 <jgarzik> ...
432 2013-09-10 15:45:20 <gmaxwell> michagogo: which is somewhat a better outcome than "hey, you sent those bitcoins a week ago, but they're still not confirmed"
433 2013-09-10 15:45:46 <michagogo> jgarzik: What I'm saying is, a 100MB mempool size limit will cause some not-spam transactions to be dropped
434 2013-09-10 15:45:57 <jgarzik> michagogo, no
435 2013-09-10 15:46:02 <michagogo> ...no?
436 2013-09-10 15:46:15 <jgarzik> michagogo, if dropped, it is by definition not interesting to the network
437 2013-09-10 15:46:27 <jgarzik> michagogo, and aging gives you the opportunity to revise and make it interesting
438 2013-09-10 15:46:33 <michagogo> Erm.
439 2013-09-10 15:46:34 <gmaxwell> michagogo: effectively doing so would _define_ spam transactions.
440 2013-09-10 15:46:44 <michagogo> Maybe I'm missing something...
441 2013-09-10 15:47:05 <gmaxwell> michagogo: e.g. "it's spammy if it's not in the top half of that sorted pool"
442 2013-09-10 15:47:14 <jgarzik> nod
443 2013-09-10 15:47:21 <michagogo> gmaxwell: But if transaction volume is high enough...
444 2013-09-10 15:47:23 <jgarzik> the mempool is sorted by "attractiveness" (fee, etc.)
445 2013-09-10 15:47:23 <maaku> michagogo: no one is stopping you from rebroadcasting your transaction after it's been dropped
446 2013-09-10 15:47:31 <maaku> or building off it with a higher fee
447 2013-09-10 15:47:48 <michagogo> maaku: Right, but that requires the sender to keep the sending node running
448 2013-09-10 15:48:00 <gmaxwell> getting stuff _out_ of the memorypool is important too. A couple times lately I've dealt with people with seriously screwed up stuck transactions that they can't fix.
449 2013-09-10 15:48:00 <maaku> michagogo: which is still the case, currently
450 2013-09-10 15:48:10 <jgarzik> michagogo, it requires the sender to not send spam
451 2013-09-10 15:48:17 <gmaxwell> Esp because bc.i is a really agressive re-relayer and cannot bet stopped.
452 2013-09-10 15:48:19 <jcorgan> jgarzik: so, that 100MB would be full of transactions that miners have chosen to ignore, as the ones that get mined would be removed, correct?
453 2013-09-10 15:48:22 <jgarzik> payment protocol also fixes this issue
454 2013-09-10 15:48:39 <michagogo> maaku: Right now, as soon as the receiver sees the transaction, the receiver's client can keep resending it
455 2013-09-10 15:48:49 <jgarzik> jcorgan, the mempool would be full of transactions, sorted in order of "most likely to be mined"
456 2013-09-10 15:48:54 <jgarzik> michagogo, ^
457 2013-09-10 15:49:01 <maaku> michagogo: and that won't continue to be true, because...?
458 2013-09-10 15:49:07 <jcorgan> yeah, got it
459 2013-09-10 15:49:27 <jgarzik> Each new transaction that arrives is judged by that criteria: it is LESS likely to be mined than these other 100MB of transactions?
460 2013-09-10 15:49:33 <gmaxwell> michagogo: e.g. one person sent a 0.01 btc input without fee and low priority. Then somehow their dumb ass bci wallet double spend that transaction in an important 3.3 btc transaction which had a decent fee. Two days later neither transaction had gone through.
461 2013-09-10 15:49:35 <michagogo> jgarzik: ...but something that falls below a certain number in the most likely list isn't necessarily spam
462 2013-09-10 15:49:58 <gmaxwell> michagogo: the 0.01 was going to take days to go in at best.. the second wouldn't relay at all because it was a double spend.
463 2013-09-10 15:50:12 <michagogo> gmaxwell: I'm not saying transaction aging is a bad thing
464 2013-09-10 15:50:38 <michagogo> But I'm still not understanding how having a limit on mempool size will be a good thing
465 2013-09-10 15:50:42 <jgarzik> michagogo, we are going around in circles :) this scheme basically defines spam. There is no _obligation_ that the network remember spammy transactions. The obligation has always been on the user, to retransmit until confirmed.
466 2013-09-10 15:50:51 <gmaxwell> michagogo: you'd just perfer the pool to be time limited instead of size? The problem with time limited alone is that its a potential dos vector.
467 2013-09-10 15:51:11 <jgarzik> functionally, in the field, mempool is memory-limited
468 2013-09-10 15:51:19 <gmaxwell> michagogo: not needing unbounded storage for other people's unconfirmed txn is a good thing.
469 2013-09-10 15:51:33 <michagogo> Defining a spammy transaction in terms of "has x transactions ahead of it" seems iffy to me
470 2013-09-10 15:51:35 <jgarzik> any node operator may certainly choose 1000MB rather than 100MB.. it will be a configurable parameter, I presume.
471 2013-09-10 15:51:45 <jgarzik> michagogo, it's the definition of a competitive market
472 2013-09-10 15:51:51 <gmaxwell> Though I dunno if 100 MB is enough. Mempool really shouldn't be in memory, it should be on disk.
473 2013-09-10 15:51:54 <jgarzik> it is self-selected
474 2013-09-10 15:51:57 <michagogo> jgarzik: Right, but the node will never see most of the transactions it would otherwise keep
475 2013-09-10 15:52:08 <jgarzik> michagogo, that's not true at all
476 2013-09-10 15:52:35 <michagogo> If a transaction is below the 100MB spot on the list
477 2013-09-10 15:52:50 <michagogo> but still above the 1000MB cutoff...
478 2013-09-10 15:53:04 <michagogo> And the majority of nodes are running on 100MB...
479 2013-09-10 15:53:19 <michagogo> They won't relay the transaction to the node that keeps 1000MB
480 2013-09-10 15:53:29 <jgarzik> gmaxwell, meh :) Though I think it's fine to define it in terms of days, e.g. 1MB * 144 * 2, plus mempool aging of 48 hours
481 2013-09-10 15:53:50 <michagogo> Right now, there's a certain set of definitions as to what's considered spam.
482 2013-09-10 15:53:51 <jgarzik> michagogo, correct
483 2013-09-10 15:54:02 <michagogo> So how is it not true at all?
484 2013-09-10 15:54:05 <jgarzik> michagogo, you want nodes to be able to make their own choices about resources and the network
485 2013-09-10 15:54:16 <jgarzik> michagogo, and that provides feedback in a dynamic system
486 2013-09-10 15:54:28 <michagogo> (also: can someone remind me why non-miners keep mempools?)
487 2013-09-10 15:55:01 <gmaxwell> jgarzik: yea, 1MB * 144 * 2 sounds good to me.
488 2013-09-10 15:55:47 <gmaxwell> 08:53 < michagogo> Right now, there's a certain set of definitions as to what's considered spam.
489 2013-09-10 15:55:50 <gmaxwell> huh? there are?
490 2013-09-10 15:56:03 <michagogo> gmaxwell: The relay criteria...
491 2013-09-10 15:56:15 <gmaxwell> I don't thinks at all a definition of whats considered spam.
492 2013-09-10 15:56:27 <gmaxwell> Thats "shit we won't relay at all" a lot of it has nothing to do with spam.
493 2013-09-10 15:56:27 <michagogo> Okay, not "what's considered spam"
494 2013-09-10 15:56:49 <gmaxwell> and a limit isn't a permission slip either. :)
495 2013-09-10 15:57:00 <r0sc0e> hi everybody
496 2013-09-10 15:57:24 <r0sc0e> i have a problem with the bitcoin-qt 0.8.4 client
497 2013-09-10 15:57:38 <michagogo> r0sc0e: Database corruption message on start?
498 2013-09-10 15:57:43 <gmaxwell> r0sc0e: http://sourceforge.net/mailarchive/forum.php?thread_name=CAAS2fgRrgrfmjSKMkDWcqnRNfS_S2pZaCECb7OiaGr3B%2BkMqww%40mail.gmail.com&forum_name=bitcoin-development
499 2013-09-10 15:57:54 <r0sc0e> it seems that qt is reindexing all
500 2013-09-10 15:58:17 <gmaxwell> r0sc0e: follow the link
501 2013-09-10 15:58:18 <jcorgan> gmaxwell: lol that you have that url on speed dial
502 2013-09-10 15:58:31 <r0sc0e> thanks! :)
503 2013-09-10 15:58:43 <gmaxwell> jcorgan: I have people emailing me constantly for help.
504 2013-09-10 15:59:11 <jcorgan> on that subject, have you guys decided on a release plan?
505 2013-09-10 15:59:31 <michagogo> gmaxwell: is that mailing list post better than https://bitcointalk.org/index.php?topic=290923.0 ?
506 2013-09-10 15:59:45 <michagogo> (if so, maybe it should be changed in /topic #bitcoin?)
507 2013-09-10 16:00:35 <r0sc0e> hm i start the qt-client with these parameters, but it keeps on reindexing
508 2013-09-10 16:00:39 <r0sc0e> is that correct?
509 2013-09-10 16:01:05 <gmaxwell> michagogo: yea, is now. https://bitcointalk.org/index.php?topic=290923.0
510 2013-09-10 16:01:11 <jcorgan> r0sc0e: once started, it will need to finish reindexing, but it won't hurt anything
511 2013-09-10 16:01:14 <gmaxwell> r0sc0e: once you've started with the reindex you're comitted to it.
512 2013-09-10 16:01:21 <jcorgan> just waste your time
513 2013-09-10 16:01:38 <michagogo> gmaxwell: What is now?
514 2013-09-10 16:01:50 <gmaxwell> Can someone write an OSX walkthrough for me? it's something like open a terminal and type open /Applications/bitcoin or something?
515 2013-09-10 16:02:07 <gmaxwell> michagogo: I moved goodbc's windows walkthrough into the top post
516 2013-09-10 16:02:14 <michagogo> open /Applications/Bitcoin-Qt.app --args -checklevel=2
517 2013-09-10 16:04:36 <gmaxwell> Thanks.
518 2013-09-10 16:04:43 <michagogo> gmaxwell: either `open /Applications/Bitcoin-Qt.app --args -checklevel=2` or `/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -checklevel=2`
519 2013-09-10 16:05:58 <saivann> New bitcoin.org FAQ should be merged in two days : https://github.com/bitcoin/bitcoin.org/pull/230
520 2013-09-10 16:06:05 <saivann> If you want to suggest changes, please comment in the pull request
521 2013-09-10 16:06:30 <jcorgan> jgarzik gmaxwell: is there any value or risk to mempool aging by itself, as an increment to current functionality, and not part of the bigger "megablock" idea we were discussing here a bit ago?
522 2013-09-10 16:09:24 <gmaxwell> jcorgan: there is both value and risk.
523 2013-09-10 16:09:58 <gmaxwell> Value: being able to fix stuck transactions. Risk: increased exposure to doublespends for transactions that take forever to confirm.
524 2013-09-10 16:10:53 <gmaxwell> though I don't know how much aging really solves transactions now since it seems that there are bozos who rebroadcast third party transactions
525 2013-09-10 16:11:17 <gmaxwell> er, solves stuck transactions.
526 2013-09-10 16:12:00 <jcorgan> don't see a way to prevent or proscribe that behavior
527 2013-09-10 16:14:41 <gmaxwell> Well, I know how to make it not problematic, but that has other tradeoffs.
528 2013-09-10 16:14:56 <gmaxwell> (to make it non-problematic: replace by fees)
529 2013-09-10 16:15:52 <gmaxwell> (e.g. oldest higest fee/byte transaction wins, if there is a doublespending conflict in the mempool)
530 2013-09-10 16:17:23 <r0sc0e> can anyone tell me a node with good bandwith to sync my qtclient?
531 2013-09-10 16:18:10 <jcorgan> hmm, compile fail on master with autotools
532 2013-09-10 16:18:23 <jcorgan> well, linker fail
533 2013-09-10 16:18:34 <michagogo> r0sc0e: Sync, or reindex?
534 2013-09-10 16:19:03 <michagogo> Reindexing is just scanning and reindexing what you already have on disk
535 2013-09-10 16:19:13 <jcorgan> ACTION wants me to recompile libleveldb.a with -fPIC to solve
536 2013-09-10 16:20:08 <jcorgan> known issue?
537 2013-09-10 16:21:22 <r0sc0e> michagogo: ah, okay
538 2013-09-10 16:21:41 <r0sc0e> its not downloading some information from blockchain on reindexing
539 2013-09-10 16:21:46 <michagogo> Nope.
540 2013-09-10 16:21:51 <r0sc0e> okay
541 2013-09-10 16:21:55 <michagogo> r0sc0e: (good thing I remembered your name, or I'd have sent you to download the 9+ GB torrent)
542 2013-09-10 16:22:35 <r0sc0e> you remembered my name? ;)
543 2013-09-10 16:23:03 <jcorgan> interesting, looks like parallel make -j4 failed, but make clean and then single job make is succeeding
544 2013-09-10 16:23:37 <gmaxwell> jcorgan: I expect it'll fail to but at another point. Some other people were reporting that fPIC needed to be added to cflags.
545 2013-09-10 16:24:08 <jcorgan> it was linking bitcoind
546 2013-09-10 16:24:11 <michagogo> r0sc0e: Well, I recognized it as someone who asked about reindexing a bit ago
547 2013-09-10 16:24:16 <gmaxwell> there area bunch of problems with the autotools right now, but theuni asked people not to change it out from under him.
548 2013-09-10 16:24:22 <jcorgan> and complained about a symbol in leveldb code
549 2013-09-10 16:24:32 <r0sc0e> michagogo: that wasnt me
550 2013-09-10 16:24:39 <michagogo> Oh?
551 2013-09-10 16:24:44 <r0sc0e> not with reindexing
552 2013-09-10 16:24:48 <jcorgan> gmaxwell: it's my first time testing it
553 2013-09-10 16:24:51 <r0sc0e> perhaps with syncing ;)
554 2013-09-10 16:24:53 <michagogo> [19:00:26] <r0sc0e> hm i start the qt-client with these parameters, but it keeps on reindexing
555 2013-09-10 16:24:53 <michagogo> [19:00:31] <r0sc0e> is that correct?
556 2013-09-10 16:25:00 <michagogo> [18:57:46] <r0sc0e> it seems that qt is reindexing all
557 2013-09-10 16:25:41 <r0sc0e> ah, i thought you mean i asked that few days ago
558 2013-09-10 16:26:04 <gmaxwell> jcorgan: it doesn't build at all for me in fedora without a big heap of patches. So every time I want to work on something I have to drop this patch set on and then pull it out of the tree before pushing... but little bumps are expected. :)
559 2013-09-10 16:26:45 <michagogo> r0sc0e: If someone had asked for a way to speed up syncing with the network, I'd have pointed them to https://bitcointalk.org/index.php?topic=145386.0;all
560 2013-09-10 16:28:10 <jcorgan> gmaxwell: we used autotools for years and years in gnuradio and finally got it tuned very nicely, then switched to cmake and had to start all over again :)
561 2013-09-10 16:29:08 <jcorgan> gmaxwell: i don't know if it works, but the compile on ubuntu 12.04/g++4.6/boost 1.48 succeeded
562 2013-09-10 16:37:07 <jcorgan> gmaxwell: so far so good
563 2013-09-10 17:23:29 <tekkentux> Hi, using getwork how much may the timestamp be varied so that the block is sill accepted?
564 2013-09-10 17:24:30 <tekkentux> I know gbt would be the better approach and I want to implement it later, but for now I just want to get some extra nonce the quick and dirty way, cuz I have no time to implement gbt
565 2013-09-10 17:24:37 <gmaxwell> by bitcoind? a found block will be accepted so long as the timestamp is still valid.
566 2013-09-10 17:24:54 <tekkentux> by bitcoind and pools
567 2013-09-10 17:24:55 <gmaxwell> if you're talking about some pool, your freedom in adjusting the timestamp will be limited to none and depends on the pool.
568 2013-09-10 17:25:05 <tekkentux> ok
569 2013-09-10 17:25:36 <tekkentux> talking about bitcoind, what does "valid" mean?
570 2013-09-10 17:26:19 <tekkentux> not in future? not differing to much any how from the data got via getwork? or just dont care as long as the hash meets the target?