1 2015-02-10 00:37:23 <petertodd> Luke-Jr: ljrP? is that what it's called? what's the exact github repo/branch you want that against?
2 2015-02-10 00:40:20 <jikoz> With 0.10's floating fees, there's no way to do it on a per-transaction level ?
3 2015-02-10 00:40:44 <petertodd> jikoz: define "it"
4 2015-02-10 00:40:56 <jikoz> I'd like to have different transactions with different txconfirmtarget
5 2015-02-10 00:41:11 <petertodd> ah, yeah, I dunno
6 2015-02-10 00:42:03 <petertodd> jikoz: in any case, specifying a target when you send the tx isn't all that useful - what fee you need to use after the tx is sent isn't all that predictable, particularly if your accepting longer confirmation times
7 2015-02-10 00:43:42 <jikoz> petertodd: I'm not sure what you mean. I have two payments I want to send, one I want to arrive immediately, one i don't care if it takes 10 confirmations
8 2015-02-10 00:43:56 <jikoz> So I'd like to send one with a txconfirmtarget of 1, and the other with 10
9 2015-02-10 00:44:50 <petertodd> jikoz: yeah, that's not supported by the RPC; dunno if coin control does it
10 2015-02-10 00:45:44 <ajweiss> the gui lets you fiddle with it
11 2015-02-10 00:46:19 <jikoz> And that's not exposed over rpc? :' (
12 2015-02-10 00:46:48 <ajweiss> i don't think so...
13 2015-02-10 00:47:30 <jikoz> https://cloud.githubusercontent.com/assets/10347403/5576863/98612042-9005-11e4-96e5-845c4f3b71f3.jpg
14 2015-02-10 00:47:36 <jikoz> That sucks that it's not exposed over rpc
15 2015-02-10 00:47:39 <jikoz> I'd love to use that
16 2015-02-10 00:48:18 <sdaftuar> rpc has estimatefee, no?
17 2015-02-10 00:48:44 <sdaftuar> see smartfees.py for example usage
18 2015-02-10 00:48:48 <ajweiss> i don't think you can set it for an outgoing transaction, unless you fiddle with it raw...
19 2015-02-10 00:49:40 <sdaftuar> yeah not sure what interface you'd be looking for, but it lets you see what fee it would recommend for a given confirmation target\
20 2015-02-10 00:49:50 <dgenr8> petertodd: i was disheartened not to see more evidence of reading/understanding. and i really fail to understand the atmosphere. no wonder the mailing list is full of terrified lurkers.
21 2015-02-10 00:50:11 <petertodd> dgenr8: ?
22 2015-02-10 00:50:53 <jikoz> sdaftuar: The interface I'd be looking for, would allow me to set my own txfee i guess
23 2015-02-10 00:50:55 <ajweiss> true you can do your own coin control like in the tests
24 2015-02-10 00:51:02 <jikoz> sendtoaddress with a txfee
25 2015-02-10 00:51:09 <jikoz> I could use estimatefee to figure that out
26 2015-02-10 00:51:26 <dgenr8> petertodd: i mean it's not like i said "this is implemented, and should really go into .10 tomorrow"
27 2015-02-10 00:51:35 <jikoz> fiddling with raw takes me down the rabbit hole of coin selection
28 2015-02-10 00:51:42 <petertodd> dgenr8: oh, right you're tom harding
29 2015-02-10 00:52:02 <petertodd> dgenr8: you've been wasting peoples' time with that idea for months now
30 2015-02-10 00:52:19 <dgenr8> try to stay concrete peter
31 2015-02-10 00:52:24 <petertodd> dgenr8: I'm disappointed after all this time you still don't understand why it's a bad idea
32 2015-02-10 00:52:27 <Luke-Jr> petertodd: 0.10.x-ljrP
33 2015-02-10 00:52:45 <ajweiss> yeah sentoaddress with an optional fee argument would really be ideal
34 2015-02-10 00:52:45 <sipa> petertodd: correct me if i'm wrong; but dgenr8: i think the essence of what peter was saying is that you can't prevent miners from peering with eachother, and if they do, block discouragement by other nodes is irrelevant
35 2015-02-10 00:53:13 <petertodd> Luke-Jr: this right? https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
36 2015-02-10 00:53:33 <dgenr8> sipa: what? that sounds like 51%
37 2015-02-10 00:53:41 <jikoz> dgenr8: lol?
38 2015-02-10 00:54:42 <dgenr8> sipa: what makes you think i believe miners should not peer with each other?
39 2015-02-10 00:54:45 <petertodd> sipa: not quite what I was saying; mainly worried about how you just can't get good guarantees on network connectivity without peering directly
40 2015-02-10 00:54:48 <sipa> dgenr8: i believe they should
41 2015-02-10 00:55:01 <sipa> dgenr8: but if they do, block discouragement by other is not relevant
42 2015-02-10 00:55:06 <petertodd> sipa: requiring that as part of mining is a very strong centralizing force, as the non-participating nodes are easily attacked
43 2015-02-10 00:55:20 <Luke-Jr> petertodd: ye, but just pushed an update
44 2015-02-10 00:55:45 <sipa> i would hate to incentivize miner peering further, but i think it's already inevitable, and from their perspective they have no reason not to
45 2015-02-10 00:55:58 <petertodd> I've had a lot of discussions with miners lately, and they worry enough already about not being sure they have good peering *without* the consequences of losing just a *transaction* being you lose a whole block
46 2015-02-10 00:56:00 <dgenr8> sipa: by peering, you just mean connecting?
47 2015-02-10 00:56:04 <sipa> dgenr8: yes
48 2015-02-10 00:56:43 <dgenr8> sipa: i'm afraid i have to ask you to explain that more ... to me it sounds like you do not understand but that is unlikely
49 2015-02-10 00:57:28 <sipa> dgenr8: you're trying to set miner incentives by changing how full node choose which block to accept, right?
50 2015-02-10 00:58:08 <dgenr8> sipa: well yes, but obviously the hash power is what matters when it comes to choosing what to build on
51 2015-02-10 00:58:13 <sipa> bingo
52 2015-02-10 00:58:22 <Luke-Jr> dgenr8: block discouragement is 51% attack, if anything
53 2015-02-10 00:58:29 <petertodd> Luke-Jr: +1
54 2015-02-10 00:58:56 <sipa> if miners do block discouragement, yes
55 2015-02-10 00:59:13 <sipa> if full nodes do, it's just making it harder for themselves to come to consensus
56 2015-02-10 00:59:44 <jikoz> What's the interface/protocol bitcoinqt uses to make a transaction? That's not something I can do as a 3rd party app? (To send a transaction with a fee i picked)
57 2015-02-10 01:00:08 <Luke-Jr> jikoz: you can make your own tx, sure
58 2015-02-10 01:00:31 <jikoz> I'd like to make my own tx, without having to write my own coin selection
59 2015-02-10 01:00:47 <Luke-Jr> jikoz: try createrawtrasnaction maybe
60 2015-02-10 01:00:49 <justanotheruser> jikoz: bitcoin core doesn't let you construct arbitrary transactions
61 2015-02-10 01:00:59 <justanotheruser> unless you do it byte by byte
62 2015-02-10 01:01:38 <justanotheruser> s/byte by byte/by entering the raw transaction data manually/
63 2015-02-10 01:02:52 <dgenr8> sipa: i fail to see how miners simply peering is at all relevant. if 95% didn't run the software, sure, that would be a failure
64 2015-02-10 01:03:50 <jikoz> dgenr8: What would happen if 10% of miners peered?
65 2015-02-10 01:04:00 <jikoz> Would you call it a success?
66 2015-02-10 01:04:42 <petertodd> jikoz: whether or not they peer isn't all that relevant; whether or not they're *forced to* peer and trust each other is relevant
67 2015-02-10 01:04:45 <dgenr8> jikoz: i'd be delighted if all miners connected to each other. it would be a problem if all the transactions got submitted there though... but totally different topic
68 2015-02-10 01:05:01 <petertodd> jikoz: dgren8's proposal leads to miners being *forced* to peer *and* trust each other
69 2015-02-10 01:05:09 <dgenr8> no it doesn't
70 2015-02-10 01:05:31 <petertodd> dgenr8: like I said, if you're not peering reliably with other miners, you can easily be sybil attacked
71 2015-02-10 01:05:47 <dgenr8> so peer away
72 2015-02-10 01:06:01 <dgenr8> really i wonder if anybody had read the thing
73 2015-02-10 01:06:14 <petertodd> dgenr8: you've now given those attackers strong incentives to do that because they can use the discouragement mechanism to both pull off 1-confirmation attacks, and fuck over small miners
74 2015-02-10 01:06:28 <fanquake> wumpus Can close #5723
75 2015-02-10 01:06:46 <jikoz> Oh, I just noticed the persons username: https://github.com/bitcoin/bitcoin/commit/ee932025c1a318943a6b101be9fe7a4a2e10648c
76 2015-02-10 01:06:51 <petertodd> dgenr8: at this point I suspect many have given up reading it, because you're previous iterations of it were such obviously bad ideas that it discredits you
77 2015-02-10 01:07:04 <petertodd> jikoz: lol
78 2015-02-10 01:07:26 <justanotheruser> jikoz: LOL
79 2015-02-10 01:07:31 <dgenr8> petertodd: at least you admit not reading it. you could consider refraining from strongly worded reactions in that case though
80 2015-02-10 01:07:36 <justanotheruser> I wonder if they're a bot
81 2015-02-10 01:07:48 <petertodd> jikoz: *however* seeing that name as against the purpose of the pull-req would be seen as highly anti-inclusiveness in many circles (and I say this both in jest and seriously)
82 2015-02-10 01:08:09 <petertodd> dgenr8: ha, no, I didn't admit that at all - I *did* read it from top to bottom
83 2015-02-10 01:08:45 <petertodd> dgenr8: note how my email in response isn't written to try to convince you that it's a bad idea - I've kinda given up on that as a waste of time - it's to convince others
84 2015-02-10 01:09:01 <justanotheruser> dgenr8: If miners can safely come to consensus within 30 seconds, the block time should be 30 seconds.
85 2015-02-10 01:09:09 <petertodd> justanotheruser: heh, very true
86 2015-02-10 01:09:43 <dgenr8> petertodd: you missed a lot. such as how 1-conf is actually improved
87 2015-02-10 01:10:09 <petertodd> dgenr8: I did see that, and I disagree
88 2015-02-10 01:10:29 <justanotheruser> You cannot simultaneously have no fork risk and be ignoring valid block
89 2015-02-10 01:10:48 <dgenr8> justanotheruser: both of those statements are superficial misunderstandings
90 2015-02-10 01:11:31 <justanotheruser> I guess that you can have those simultaneously if you have miners not doing the most profitable thing possible
91 2015-02-10 01:12:39 <petertodd> justanotheruser: indeed, all this stuff has to survive bad actors at all levels
92 2015-02-10 01:13:26 <dgenr8> well clearly if it ever gets tried, it will first be in an alt or sidechain. i need to get a good implementer interested though.
93 2015-02-10 01:13:34 <justanotheruser> Can you even call them bad actors when their profitability doubles by mining on the fork and not recognizing these rules?
94 2015-02-10 01:16:04 <dgenr8> justanotheruser: i never said the word "bad" (nor "honest" petertodd). they would not be wise though, if say even 20% adopted
95 2015-02-10 01:16:07 <petertodd> what amazes me about this whole ridiculous idea is how replace-by-fee scorched-earth obviously works, and doesn't need anyone to act against any incentives
96 2015-02-10 01:16:50 <dgenr8> dgenr8: please
97 2015-02-10 01:17:06 <Luke-Jr> ^ +1
98 2015-02-10 01:17:33 <justanotheruser> If bob creates a block that miners don't like because it has a doublespend, you have the choice of mining on bobs block or the other block. If you mine a second block on bobs then the other miners could undo the doublespend by making a 2 block reorg. Of course, you are claiming this is fork-resistant, so you can't have forks that big. Because there is no risk of a fork that big you have no reason to not mine on the block ...
99 2015-02-10 01:17:39 <justanotheruser> ... that doesn't follow these rules.
100 2015-02-10 01:18:03 <Luke-Jr> justanotheruser: what? blocks with double spends are invalid
101 2015-02-10 01:18:10 <justanotheruser> Luke-Jr: lol, you know what I mean
102 2015-02-10 01:18:43 <Luke-Jr> â
103 2015-02-10 01:19:05 <justanotheruser> even if I didn't use the right terminology, I have a feeling you know what I meant
104 2015-02-10 01:19:22 <Luke-Jr> â¦
105 2015-02-10 01:20:12 <jikoz> If I add a 5th argument to `sendtoaddress` nTxConfirmTarget ... is that something that would be merged in?
106 2015-02-10 01:20:15 <justanotheruser> s/doublespend/transaction that spends the same outputs as another transaction that was already broadcast, but isn't in the blockchain/
107 2015-02-10 01:20:28 <Luke-Jr> jikoz: what would it do?
108 2015-02-10 01:20:40 <jikoz> It would override the nTxConfirmTarget for that particular transaction
109 2015-02-10 01:20:48 <Luke-Jr> justanotheruser: um, that'd be insane to have as a rule
110 2015-02-10 01:21:02 <jikoz> So you could send a transaction with a lower/higher confirm target
111 2015-02-10 01:21:20 <justanotheruser> Luke-Jr: My message was pointing out the problem with that rule
112 2015-02-10 01:21:25 <Luke-Jr> jikoz: where is there a nTxConfirm Target and what does it do/
113 2015-02-10 01:21:29 <justanotheruser> s/the/a/
114 2015-02-10 01:22:12 <earlz> how much ram does bitcoin 0.10 take to compile these days? Tried on 1G of RAM and got an out of memory error heh
115 2015-02-10 01:23:05 <Luke-Jr> earlz: CXXFLAGS/LDFLAGS, add memory reduction opts
116 2015-02-10 01:24:03 <dgenr8> justanotheruser: you are assuming all kinds of logic that isn't there. such as that there is some concerted effort to "undo a doublespend"
117 2015-02-10 01:25:03 <earlz> eh, just added some swap memory and seeing if that gets it past it
118 2015-02-10 01:27:58 <justanotheruser> dgenr8: mining on a blockchain with less work because it doesn't contain a doublespend is a concerted effort.
119 2015-02-10 02:58:56 <dgenr8> I think maybe folks are hung up on peering details, because you are not grasping that tx propagation can be modeled by a single 2-parameter distribution, which can then give quantitative answers
120 2015-02-10 02:59:21 <dgenr8> if somebody said "hey, how do you justify a lognormal model?" then we'd be getting somewhere
121 2015-02-10 03:08:31 <justanotheruser> dgenr8: Are you aware that you are trying to create a consensus mechanism by getting miners to agree on what transactions are not to be included in blocks based on their timing?
122 2015-02-10 03:20:41 <benjamindees> the average internet speed in Argentina is 3 mbit/s
123 2015-02-10 04:11:45 <dgenr8> justanotheruser: not "getting miners to agree". choosing parameters so that a targeted % will agree, with plenty of cushion.
124 2015-02-10 04:11:50 <dgenr8> miners don't agree today on which block was first in a race. and yet the world spins on.
125 2015-02-10 04:17:37 <justanotheruser> the point of consensus is that eventually 100% should agree
126 2015-02-10 04:19:04 <dgenr8> DSDW does not change that. It seeks to influence the consensus-forming process.
127 2015-02-10 04:19:19 <kanzure> other than running a second regtest bitcoind node, is there a way to not keep private keys for mined blocks in regtest mode?
128 2015-02-10 04:19:36 <kanzure> i could manually remove keys through rpc but perhaps there's a super secret flag? :/
129 2015-02-10 04:24:10 <justanotheruser> but because you aren't using a blockchain and trying to get miners to agree on something, you are attempting to form consensus outside the blockchain
130 2015-02-10 04:25:03 <justanotheruser> You would need 100% of the network hashrate for this to work
131 2015-02-10 04:25:16 <justanotheruser> and they'd be going against profitability
132 2015-02-10 04:32:19 <phantomcircuit> kanzure, patch the generate code to generate a new key per block
133 2015-02-10 04:35:22 <dgenr8> justanotheruser: with reasonable assumptions, if 6.9% adopted it, out of self interest I would not mine anything I thought was a double-spend aged > 30s.
134 2015-02-10 04:35:34 <dgenr8> justanotheruser: I would not mine any unconfirmed double-spends period, but that's beside the point.
135 2015-02-10 04:35:55 <justanotheruser> dgenr8: so you wouldn't replace by fee as most mining pools don't do?
136 2015-02-10 04:36:11 <justanotheruser> thats pretty normal
137 2015-02-10 04:36:27 <justanotheruser> mining on a different block than everyone else isn't healthy for consensus though
138 2015-02-10 04:40:15 <kanzure> phantomcircuit: that's unfortunate...
139 2015-02-10 04:40:38 <kanzure> i suppose i could do that with a flag/parameter, which is slightly less unfortunate.
140 2015-02-10 04:40:54 <kanzure> why has nobody needed this in the past?
141 2015-02-10 04:41:15 <kanzure> i don't think anyone is testing watchonlys on regtest mode
142 2015-02-10 04:41:56 <kanzure> oh wait, i see now. my use-watchonlys-during-coin-selection patch didn't exist before, therefore nobody ran into this.
143 2015-02-10 04:43:49 <dgenr8> justanotheruser: i agree it is spending a little bit of security capital, to pursue a very desirable goal
144 2015-02-10 04:46:02 <justanotheruser> dgenr8: the current ruleset is more profitable with even 99.9999% of miners. It doesn't work
145 2015-02-10 04:46:49 <dgenr8> justanotheruser: what do you think would be the effect on the BTC price if it became a 30s technology?
146 2015-02-10 04:52:09 <justanotheruser> dgenr8: what is a 30s technology
147 2015-02-10 04:53:33 <justanotheruser> regardless of the price, miners have an incentive to make more money
148 2015-02-10 04:54:10 <akstunt600> yeah, i mined back in 2010
149 2015-02-10 04:54:15 <akstunt600> it wasnt worth anything then
150 2015-02-10 04:54:20 <akstunt600> it just cost me money
151 2015-02-10 04:54:42 <akstunt600> i was just trying to make magic internet monies >.<
152 2015-02-10 05:11:57 <dgenr8> justanotheruser: 30 seconds, contrast with 10±10 minutes
153 2015-02-10 05:14:37 <justanotheruser> dgenr8: if you have 30 second blocks you will probably have weaker consensus. I'm not sure what the block time optimization point is, but it will probably be found in a sidechain
154 2015-02-10 05:15:14 <akstunt600> Ohhh i see what you are talking about
155 2015-02-10 05:15:50 <akstunt600> I had this same idea i think.. Is it that Sidechains find block by different pool?
156 2015-02-10 05:15:50 <dgenr8> justanotheruser: not 30 second blocks. 30 seconds until you aren't going to see a double-spend. your 99.9999% of mining would see to that
157 2015-02-10 05:15:57 <akstunt600> something like that?
158 2015-02-10 05:16:17 <akstunt600> so that same pool doesnt get sidechain bonus plus btc bonus?
159 2015-02-10 05:16:29 <justanotheruser> dgenr8: 30 second limit on double spending implies some ordering mechanism implies some consensus mechanism implies a blockchain
160 2015-02-10 05:16:55 <akstunt600> ?
161 2015-02-10 05:17:15 <dgenr8> akstunt600: not the same thing
162 2015-02-10 05:17:38 <akstunt600> ahh interesting. i had the above this morning but it doesnt work :-/
163 2015-02-10 05:17:44 <akstunt600> thuoght*^
164 2015-02-10 05:20:14 <dgenr8> justanotheruser: same old familiar blockchain, but miners no longer include in it txes they know to be unconfirmed double-spends. not worth risk. barely worth anything actually
165 2015-02-10 05:28:33 <justanotheruser> dgenr8: without a consensus mechanism, it isn't known to be a double-spend
166 2015-02-10 05:30:56 <dgenr8> justanotheruser: that's why it's 30 seconds, and not immediate. after that amount of time there is only a .094% chance there was a double spend that you missed. or equivalently, only .094% of the network will fail to identify the double-spend that you saw
167 2015-02-10 05:34:58 <justanotheruser> there is no one forcing consensus. If you have a consensus mechanism such as 30s blocks, this can work. If there is nothing forcing consensus on this doublespend prevention, it doesn't do anything.
168 2015-02-10 05:37:12 <dgenr8> people mean 2 different things by consensus. one is the process, and changes can be made to the process and accepted by the community. two is the resulting consensus truth itself, which grows with confirmations
169 2015-02-10 05:38:19 <dgenr8> it is very important that miner not get blindsided by others thinking he included a double-spend. that's why a tx maturation time is also specified. by waiting 30s before including any transaction at all the chance of that is very slim, .010% with reasonable assumptions
170 2015-02-10 05:40:54 <dgenr8> since i did these numbers a few months ago, tx propagation has gotten 25% faster. also, miners are going to have better times than average
171 2015-02-10 05:41:03 <justanotheruser> dgenr8: you are redefining words and obscuring the issue. It is fine if you wait 30s before including double spends. You aren't including or discluding a transaction by mining on top of a block containing that tx.
172 2015-02-10 05:41:44 <justanotheruser> the former is a personal decision and isn't enforcable, the latter is a consensus harming action.
173 2015-02-10 05:49:28 <dgenr8> if a miner continues to include txes knowing other miners will make their block stale because of it, I agree the stale rate has increased. he could easily do it deliberately every time. this attack is not very interesting.
174 2015-02-10 05:50:02 <justanotheruser> why would a miner make their block stale?
175 2015-02-10 05:50:13 <justanotheruser> What is their incentive as an individual miner
176 2015-02-10 05:52:18 <dgenr8> chain work = -1 affects even the block AFTER the block on top of the deprecated one
177 2015-02-10 05:52:54 <justanotheruser> lets say 99% of miners follow this rule
178 2015-02-10 05:53:18 <justanotheruser> that means the two blocks are of the same work to 99%, and to 1% the taller block is actually taller
179 2015-02-10 05:53:42 <dgenr8> "taller" no longer means the same thing
180 2015-02-10 05:53:52 <justanotheruser> I'm not sure why I'm even covering that, but that is a problem. Ultimately, if 95% of miners can agree on what transactions came first, they can also agree on what block came first with 30 second blocks.
181 2015-02-10 05:55:21 <dgenr8> the block interval is not about agreeing on ordering ... it's about basic chain parameters
182 2015-02-10 05:56:14 <justanotheruser> wat
183 2015-02-10 05:58:32 <justanotheruser> Do you not understand what I'm saying
184 2015-02-10 06:00:43 <dgenr8> it's a good question. the block interval was chosen to be >> transaction propagation. that's true
185 2015-02-10 06:02:03 <kanzure> % of miners doesn't matter at all. there could be a billion miners all effectively throwing a grain of sand into the ocean and nobody would care.
186 2015-02-10 06:02:40 <kanzure> [except for some edge cases involving forks]
187 2015-02-10 06:02:45 <justanotheruser> the block interval was chosen so consensus could be established in that time. If consensus on whether a transaction has appeared can happen in 30 seconds, the same can be said of 30 second blocks
188 2015-02-10 06:03:08 <dgenr8> kanzure: i just read that as "hash power"
189 2015-02-10 06:04:13 <kanzure> "the former is a personal decision and isn't enforcable, the latter is a consensus harming action."
190 2015-02-10 06:04:43 <kanzure> justanotheruser: give up and cut your losses. you have better things to be pretending to do :).
191 2015-02-10 06:04:53 <dgenr8> justanotheruser: a double-spend is a unique event which spender has the power to avoid, and miner has the power to exclude. this is a different situation than the basic consensus design
192 2015-02-10 06:04:55 <justanotheruser> kanzure: I have sleeping to do
193 2015-02-10 06:05:03 <justanotheruser> and sleeping is lame
194 2015-02-10 06:05:32 <benjamindees> can't sleep now. someone is wrong on the internet.
195 2015-02-10 06:06:20 <kanzure> future economists are going to be so weird. you will just debate them for 18 hours in a giant gish gallop over irc, and that's how the ietf will decide their new mandatory standards, duh.
196 2015-02-10 06:07:39 <benjamindees> economic gladiatorial combat
197 2015-02-10 06:11:08 <justanotheruser> dgenr8: I've tried to explain it. I'm going to leave it to you to consider the difference between determining the order of a transaction in a 30 second window and having 30 second blocks.
198 2015-02-10 06:12:11 <kanzure> i am going to write a paper regarding a novel form of attack against bitcoin, called the irc blockbuster attack, where you waste developer time
199 2015-02-10 06:12:49 <kanzure> since developers are a finite and scarce resource, their time is doubly or quadratically scarce, so you can quite easily exhaust the available supply
200 2015-02-10 06:13:06 <dgenr8> just scroll past it, i've done the same on many occasions
201 2015-02-10 06:13:18 <justanotheruser> how can someones time be anything but linearly scarce?
202 2015-02-10 06:13:27 <kanzure> unfortunately that gives the impression that your proposals are acceptable and not a waste of time
203 2015-02-10 06:13:41 <kanzure> justanotheruser: time is weird
204 2015-02-10 06:14:17 <kanzure> ACTION sleeps
205 2015-02-10 06:14:18 <dgenr8> kanzure: keep on trying to prevent 100-block reorgs then
206 2015-02-10 06:14:27 <kanzure> why would i want to prevent reorgs?
207 2015-02-10 06:15:16 <dgenr8> or detect them, whatever it is
208 2015-02-10 08:09:00 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/pull/5781
209 2015-02-10 08:09:23 <jonasschnelli> needs GUI tag and LOW-PRIO tag: https://github.com/bitcoin/bitcoin/pull/5777
210 2015-02-10 08:09:35 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/pull/5776/files
211 2015-02-10 08:09:59 <gmaxwell> done-ing.
212 2015-02-10 08:10:56 <sipa> that's past present participle?
213 2015-02-10 08:16:52 <jonasschnelli> thanks
214 2015-02-10 08:18:00 <uiop> will have had gone done-ed
215 2015-02-10 08:19:13 <uiop> ing
216 2015-02-10 08:30:59 <jonasschnelli> rpc: sendtoaddress is horrible slow (1tx per sec). Other ideas to create a regtest wallet with 200'000 tx (context: performance test)?
217 2015-02-10 08:58:17 <wumpus> jonasschnelli: any idea why it is so slow?
218 2015-02-10 08:58:45 <wumpus> jonasschnelli: is it *because* you've created such a large wallet, and the output selection?
219 2015-02-10 08:59:10 <jonasschnelli> wumpus, you mean the rpc sendtoaddress call? not the Qt things?
220 2015-02-10 08:59:12 <wumpus> jonasschnelli: in any case to roll lots of transactions you'd likely want to do something with the raw transaction API and manual input selection
221 2015-02-10 08:59:43 <wumpus> jonasschnelli: huh? I was just responding to your message about sendtoaddress
222 2015-02-10 09:00:20 <jonasschnelli> wumpus, sendtoaddress is slow from the beginning (with a tiny wallet).
223 2015-02-10 09:00:51 <jonasschnelli> its getting slower over time... but not much slower ... maybe from 0.5s to 1.5sec
224 2015-02-10 09:01:00 <wumpus> <kanzure> i am going to write a paper regarding a novel form of attack against bitcoin, called the irc blockbuster attack, where you waste developer time <- there's another practical attack with submitting tons of tiny issues and not-really-solve-anything pull requests, but don't tell anyone
225 2015-02-10 09:01:37 <wumpus> jonasschnelli: I don't think i've ever noticed that for new wallets. may be something with your new wallet then?
226 2015-02-10 09:01:56 <wumpus> I mean the new database stuff
227 2015-02-10 09:02:02 <jonasschnelli> hmm... im testing with the master
228 2015-02-10 09:02:20 <jonasschnelli> no changes on top
229 2015-02-10 09:02:50 <wumpus> ok, try to profile
230 2015-02-10 09:03:05 <jonasschnelli> i created a new rpc test (walletperformance.py) where i do some looping with sendtoaddress. And it takes around 1s/tx.
231 2015-02-10 09:03:09 <jonasschnelli> will do
232 2015-02-10 09:04:56 <wumpus> not that wallet sending transation performance is *that* important in the general case, it's not like the P2P network or block chain takes kindly to flooding, so if your goal is just to generate lots of transactionsn for testing it may be more worthwhile to look at another approach of generating them
233 2015-02-10 09:05:18 <wumpus> (e.g. raw transactions API)
234 2015-02-10 09:06:38 <jonasschnelli> wumpus, Agreed. It's low prio. But i'd like to know where the bottlenecks are... could help in future
235 2015-02-10 09:06:40 <wumpus> e.g. just start with the mined coinbase outputs, then split them into 100x outputs each, then split up those outputs again... lots of transactions
236 2015-02-10 09:07:39 <wumpus> no need for a knapsack algorithm if you know exactly the structure you're going to generate :)
237 2015-02-10 09:07:40 <jonasschnelli> i'm running a rpc sendtoaddress loop since 12h.... (target 200k tx)
238 2015-02-10 09:19:48 <jonasschnelli> wumpus, outside of the rcp-test with a shell script using bitcoin-cli it's a bit faster ~<0.5s/tx. Bottleneck is CWallet::SelectCoins (CWallet::IsMine) as well as CWallet::TopUpKeyPool
239 2015-02-10 09:19:58 <jonasschnelli> so rpc server itself is fast
240 2015-02-10 09:23:18 <wumpus> indeed, the RPC server itself is extremely fast (as long as your number of connections is smaller than rpcthreads, after that the extra connections will just starve)
241 2015-02-10 09:25:06 <jonasschnelli> wumpus, btw. hows you progress #5677 (RPC [PoC]). It's still named as PoC.
242 2015-02-10 09:25:18 <jonasschnelli> s/./?
243 2015-02-10 09:25:24 <wumpus> no progress really, I intend to get back to it at some point though
244 2015-02-10 09:30:30 <wumpus> yes it is a PoC, I'm not entirely convinced of it yet
245 2015-02-10 09:33:33 <wumpus> I'll rebase it at least
246 2015-02-10 09:33:54 <wumpus> completely silly conflict in Makefile.am
247 2015-02-10 09:50:49 <wumpus> wut@ 72ac792b4a544048261f35af859c7bb6d8bdb7a0
248 2015-02-10 09:52:31 <jonasschnelli> wumpus, ha. Has only one utACK
249 2015-02-10 09:52:33 <wumpus> this just rearranges the Makefile.am ... and hardly seems like an improvement, e.g. why is bitcoin_cli_LDADD suddenly split
250 2015-02-10 09:53:57 <jonasschnelli> reverse?
251 2015-02-10 09:54:14 <wumpus> well it works fine, I don't doubt that
252 2015-02-10 09:55:40 <wumpus> there's no pressing reason to reverse it either
253 2015-02-10 09:57:08 <gmaxwell> maybe this was trying to make it more like the old unix makefile?
254 2015-02-10 09:58:03 <wumpus> cfields: what do you think of 72ac792b4a544048261f35af859c7bb6d8bdb7a0 ? you utACKed it, but it seems kind of strange to me
255 2015-02-10 09:58:15 <gmaxwell> can we get in the habbit of asking for better commit messages? both the commit message and the PR text there tell me nothing about what motivated the change.
256 2015-02-10 09:58:50 <wumpus> yes
257 2015-02-10 10:00:21 <wumpus> 'rearrange the deck chairs on the titanic' would be a good commit message, for example
258 2015-02-10 10:00:30 <gmaxwell> hah
259 2015-02-10 10:17:17 <jonasschnelli> what about merging this (https://github.com/bitcoin/bitcoin/pull/5548) before it gets outdated? REST interface makes much more sense with a simple "chaininfos" call.
260 2015-02-10 10:26:19 <wumpus> maybe, I don't know, I don't really know what the goal for the REST interface is
261 2015-02-10 10:26:33 <wumpus> I thought it was just a simple interface to get block in transaction data
262 2015-02-10 10:26:39 <wumpus> s/in/and
263 2015-02-10 10:26:55 <wumpus> and now it gets extended with everything the RPC already exposes too
264 2015-02-10 10:27:12 <wumpus> which is fine with me, but seems a bit duplicated
265 2015-02-10 10:27:33 <jonasschnelli> jgarzik wrote on https://github.com/bitcoin/bitcoin/pull/2844: The beginnings of a block explorer-style API for bitcoind.
266 2015-02-10 10:28:41 <jonasschnelli> Following this paradigm, adding chaininfos would be a step to a completion of that
267 2015-02-10 10:28:52 <wumpus> sure, but did he ever write in more detail what he wanted it to support? 'a block explorer style API' is an open window though which a whole universe of extra functionality could flow in
268 2015-02-10 10:29:46 <holy_ster> / Copyright (c) 2009-2010 Satoshi Nakamoto
269 2015-02-10 10:29:48 <holy_ster> / Copyright (c) 2009-2014 The Bitcoin Core developers
270 2015-02-10 10:29:50 <holy_ster> / Distributed under the MIT software license, see the accompanying
271 2015-02-10 10:29:53 <holy_ster> / file COPYING or http://www.opensource.org/licenses/mit-license.php.
272 2015-02-10 10:29:55 <holy_ster> #include "script.h"
273 2015-02-10 10:29:57 <holy_ster> #include "tinyformat.h"
274 2015-02-10 10:29:59 <holy_ster> #include "utilstrencodings.h"
275 2015-02-10 10:30:01 <holy_ster> namespace {
276 2015-02-10 10:30:04 <holy_ster> inline std::string ValueString(const std::vector<unsigned char>& vch)
277 2015-02-10 10:30:06 <holy_ster> {
278 2015-02-10 10:30:08 <holy_ster> if (vch.size() <= 4)
279 2015-02-10 10:30:10 <holy_ster> return strprintf("%d", CScriptNum(vch, false).getint());
280 2015-02-10 10:30:12 <holy_ster> else
281 2015-02-10 10:30:15 <holy_ster> return HexStr(vch);
282 2015-02-10 10:30:17 <holy_ster> }
283 2015-02-10 10:30:19 <holy_ster> } // anon namespace
284 2015-02-10 10:30:21 <holy_ster> using namespace std;
285 2015-02-10 10:30:23 <holy_ster> const char* GetOpName(opcodetype opcode)
286 2015-02-10 10:30:31 <jonasschnelli> :/
287 2015-02-10 10:31:23 <jonasschnelli> wumpus, I just think chaininfos would allow users to create blockchain like interfaces. Otherwise they need to use the rpc for chaintips etc.
288 2015-02-10 10:31:37 <jonasschnelli> s/blockchain/blockexplorer
289 2015-02-10 10:32:24 <wumpus> jonasschnelli: anyhow, I'm not against it, but I keep wishing it was just an external project
290 2015-02-10 10:33:45 <wumpus> in which case you could have merged it a zillion times already
291 2015-02-10 10:34:05 <jonasschnelli> wumpus, Indeed. It would be good to have more modularization-possibility in the core. So module could be held in a separate repository...
292 2015-02-10 10:34:07 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5752
293 2015-02-10 10:35:14 <wumpus> yes
294 2015-02-10 10:35:26 <jonasschnelli> i know, im cheerleading some of my pull ;) . I'd like to make some steps implementing a new wallet...
295 2015-02-10 10:35:36 <jonasschnelli> s/pull/pulls
296 2015-02-10 10:35:51 <wumpus> I'm tired and have an headache and I'm grumpy, don't mind me
297 2015-02-10 10:36:48 <jonasschnelli> no worries...
298 2015-02-10 11:11:50 <wumpus> tip: don't run bitcoind on a machine that can't even compile without producing junk assembly #5767
299 2015-02-10 12:06:45 <benedikt> If I wanted to use a blockchain (not for another *coin), are there some nice libraries around?
300 2015-02-10 12:26:36 <rabidus> umm... ?
301 2015-02-10 12:27:31 <rabidus> someone has coded his own irc client with some nice bugs :)
302 2015-02-10 12:28:45 <waxwing> is there an easy way to un-import a watch-only address in 0.10? (using RPC)
303 2015-02-10 13:17:03 <shesek> bedeho, you don't really choose between the two
304 2015-02-10 13:17:14 <bedeho> how so?
305 2015-02-10 13:17:22 <shesek> the script itself is a multisig script, used as a p2sh address
306 2015-02-10 13:17:48 <shesek> p2sh can be used with any kind of script, really. multisig is just one thing you can do with it.
307 2015-02-10 13:18:12 <shesek> if you meant "is there any reason to use bare multisig outputs over p2sh outputs", then probably no
308 2015-02-10 13:18:39 <shesek> (other than using it as a way to stuff arbitrary blobs into the blockchain, but we already have OP_RETURN for that now)
309 2015-02-10 13:19:18 <bedeho> shesek: right, I guess I was asking the last one then, thank you
310 2015-02-10 13:19:43 <bedeho> but pure bip11 transactions are still considered standard then, they will be mined and relayed?
311 2015-02-10 13:20:13 <shesek> yep
312 2015-02-10 13:20:26 <bedeho> thanks
313 2015-02-10 13:20:35 <shesek> I don't think anyone uses it for actual multisig, though
314 2015-02-10 13:21:16 <shesek> the main use-case is, as I mentioned, stuffing arbitrary data (usually by meta protocols sitting on the of the blockchain, like mastercoin)
315 2015-02-10 13:21:47 <shesek> (I'm not sure if they're still doing it nowadays, haven't been following mastercoin)
316 2015-02-10 13:22:27 <bedeho> ok, so if you want to do multisig, then the script you use with p2sh, what other type could it be beyond the bip11 script?
317 2015-02-10 13:23:03 <bedeho> as far as I can understand, you cant put whatever you want in there
318 2015-02-10 13:23:39 <shesek> you can use any script that you want, yes
319 2015-02-10 13:24:51 <bedeho> p2sh bip claims: Transactions that redeem these pay-to-script outpoints are only considered standard if the serialized script - also referred to as the redeemScript - is, itself, one of the other standard transaction types
320 2015-02-10 13:25:11 <bedeho> that sounds like it is constrained, but I have never actually seen a full list of standard scripts
321 2015-02-10 13:26:13 <shesek> bedeho, its outdated. see https://gist.github.com/gavinandresen/88be40c141bc67acb247 and https://github.com/bitcoin/bitcoin/pull/4365
322 2015-02-10 13:26:31 <shesek> (its quite a recent change, I'm not sure how common it is with miners)
323 2015-02-10 13:26:54 <shesek> the standard scripts are pay-to-pubkey, pay-to-pubkey-hash, multisig and p2sh
324 2015-02-10 13:27:23 <shesek> and when p2sh is used, anything with less than 15 signature operations is considered standard
325 2015-02-10 13:29:13 <bedeho> shesek: super appreciated! really cleared things up
326 2015-02-10 13:30:15 <shesek> oh, wait, looks like its not as recent as I remember... it got merged on Jun 2014
327 2015-02-10 13:32:15 <shesek> and you're very much welcome :)
328 2015-02-10 13:34:58 <bedeho> shesek: something I still dont get is, the bip says scriptSigs are invalid if there are "..any operations other than "push data" operations in the scriptSig.", however the example on the very same page has OP_CHECKSIG in the scriptSig +
329 2015-02-10 13:34:59 <bedeho> ?
330 2015-02-10 13:37:32 <shesek> bedeho, that scriptSig is the inner script that's provided as part of the spending input (aka redeemScript)
331 2015-02-10 13:37:50 <shesek> that validation rule applies to the p2sh output script
332 2015-02-10 13:39:02 <bedeho> But why would that need to be stated, isnt the output script forced to be: OP_HASH160 [20-byte-hash-value] OP_EQUAL
333 2015-02-10 13:40:18 <shesek> ah, sorry, I think I got confused
334 2015-02-10 13:42:38 <shesek> bedeho, it refers to the spending input that wraps the inner script
335 2015-02-10 13:43:09 <shesek> in that example you see there, the actual spending input is PUSHDATA [signature] PUSHDATA [innerscript]
336 2015-02-10 13:43:17 <shesek> where [innerscript] contains the OP_CHECKSIG
337 2015-02-10 13:45:45 <bedeho> [innerscript] == {serialized script} ?
338 2015-02-10 13:46:38 <shesek> yes
339 2015-02-10 13:47:25 <bedeho> I see
340 2015-02-10 13:47:47 <bedeho> could I ask another question, now that I have your valuable attention?
341 2015-02-10 13:48:53 <shesek> sure, go ahead
342 2015-02-10 13:50:43 <bedeho> how is [signature] actually pushed on the stack? given that [signature] does not have a fixed length, even for one signature?
343 2015-02-10 13:54:59 <shesek> bedeho, OP_PUSHDATA also adds the length of the pushed data
344 2015-02-10 13:55:11 <bedeho> lol yes, just saw it now!
345 2015-02-10 13:55:20 <shesek> but its usually being omitted when writing a script, for brevity
346 2015-02-10 13:55:38 <shesek> (along with the entire PUSHDATA op in most cases)
347 2015-02-10 13:56:06 <shesek> I meant, when writing a script talking to other people / for documentation / etc
348 2015-02-10 13:56:35 <bedeho> yes, I was always confused by that. So they are always present? e.g. when a p2pkh scriptPubKey is executed, then the way the pubkey and sig get on the stack is by pushdata? its not like a hardcoded operation?
349 2015-02-10 13:58:01 <shesek> benedikt, yep, indeed its there
350 2015-02-10 13:58:29 <shesek> (note that for <=75 bytes, there's no actual OP_PUSHDATA in there, its just the length)
351 2015-02-10 13:58:45 <shesek> these bytes were reserved for that
352 2015-02-10 13:59:05 <benedikt> shesek: i think you meant to highlight bedeho
353 2015-02-10 13:59:20 <shesek> benedikt, ah, sorry, I did
354 2015-02-10 14:01:21 <bedeho> shesek: yes, saw that now, great!
355 2015-02-10 14:01:37 <bedeho> I guess that explains why people omit it
356 2015-02-10 14:29:20 <mseeks> is it OK to use the signmessage/verifymessage JSON RPC calls to sign/verify arbitrary messages?
357 2015-02-10 14:38:18 <cfields> wumpus: 72ac792b4a544048261f35af859c7bb6d8bdb7a0 strange how?
358 2015-02-10 14:38:48 <cfields> wumpus: it may be the diff that's throwing you off.. it's pretty hard to read
359 2015-02-10 14:39:43 <cfields> wumpus: been a while since i looked at it, but that basically re-arranges things to group flags together. before, bitcoin-cli and bitcoin-tx (i think, it might've been others) flags were kinda intertwined
360 2015-02-10 14:41:06 <cfields> also, the libs are split between internal deps and external ones. the other bins were already done that way, this change made things consistent
361 2015-02-10 14:41:41 <cfields> i managed to make sense of it at one point and agree with the changes. is it causing issues?
362 2015-02-10 14:55:16 <xabbix> When I create a transaction in my wallet and broadcast it to the network, other nodes propagate the same exact 'message' to other nodes? So for example, let's say I have complete coverage on all internet packets and I wanted to know the IP of the wallet that actually sent the coins, will I just look for the first node that broadcasted that tx?
363 2015-02-10 15:16:57 <mseeks> is it OK to use the signmessage/verifymessage JSON RPC calls to sign/verify arbitrary messages? I noticed that some implementations (like haskoin) restrict the message to 32 bytes.
364 2015-02-10 15:18:59 <kanzure> you should be suspicious of signing extremely short messages
365 2015-02-10 15:19:55 <mseeks> i agree; i want to use it to sign quite long messages comparable in size to p2pk transactions
366 2015-02-10 15:26:14 <Fletch-1> I was looking into zero conf transactions, and found the replace-by-fee pitched as a merchant countermeasure to a doublespend (originally enabled by replace-by-fee). The merchant is to send another TX sending 100% of the TX to fees. (http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02226.html)
367 2015-02-10 15:26:45 <Fletch-1> But I'm not seeing how the merchant gets control over the inputs if the doublespend hasn't confirmed yet.
368 2015-02-10 15:27:10 <Fletch-1> I'm a little green, so I apologize if I'm missing something obvious
369 2015-02-10 15:28:54 <billyJoe> bitcoin Cat
370 2015-02-10 15:28:56 <billyJoe> https://www.youtube.com/watch?v=UBKlU6HCJbs
371 2015-02-10 15:30:41 <mseeks> Fletch-1: this "countermeasure" relies on child-pays-for-parent (http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-large-miners-running-child-pays-for-parent-patch)
372 2015-02-10 15:31:11 <mseeks> which would allow the merchant to propagate a tx spending unconfirmed utxos
373 2015-02-10 15:45:48 <Fletch-1> mseeks: Ahh, this makes sense, but what is the current adoption (or where can I check it) for both of these features? I got the impression replace-by-fee was pretty widely adopted.
374 2015-02-10 15:52:26 <mseeks> the pull request for child-pays-for-parent appears to still be open -- https://github.com/bitcoin/bitcoin/pull/1647
375 2015-02-10 16:30:30 <wumpus> cfields: well it interfered with trying to rebase another pull, and indeed the diff looks pretty weird to me, but it's not that bad :)
376 2015-02-10 16:30:44 <cfields> wumpus: ah, ok
377 2015-02-10 16:32:02 <cfields> wumpus: fyi, i'm getting ready to head to boston for the conf. Not sure how much I'll be around until Thurs morning
378 2015-02-10 18:25:17 <SrPx> Hello, is there any guideline on how to open an exchange? That is - I am a programmer, and I know the Bitcoin protocol reasonably well - but it would be great to have some guidelines such as, what should I be aware, safety advices, how to deal with banks and so on. Thank you...
379 2015-02-10 18:26:25 <bl4ckh4t> Alphapoint does exchange engines if that is what your looking for. I think they provide assitance with setting it up and everything too
380 2015-02-10 18:26:45 <bl4ckh4t> but wrong channel
381 2015-02-10 18:31:16 <SrPx> No, I just want the resources to implement it from scratch. I don't want to depend on a third party engine. Sorry about wrong channel, what is the right one for this kind of question?
382 2015-02-10 18:32:05 <SrPx> please where do I go to know everything about to protocol? Not just the average knowledge I have. Is the bitcoin wiki the to go resource?
383 2015-02-10 19:40:26 <jonasschnelli> SrPx: use https://bitcoin.org/en/developer-documentation
384 2015-02-10 19:40:51 <jonasschnelli> SrPx: please respect that this channel is only for discussiona about the development of bitcoin-core
385 2015-02-10 19:41:10 <SrPx> thanks :)
386 2015-02-10 19:41:22 <SrPx> my bad, I didn't know that! sorry guys.
387 2015-02-10 19:42:37 <SrPx> I assumed he meant exchanges specifically aren't in topic, but I understand now! Quitting. Hope I didn't disturb your channel. Thanks again!
388 2015-02-10 20:25:35 <sipa> jonasschnelli: i'd say it's more than bitcoin core, but still things related to bitcoin the blockchain or protocol at least
389 2015-02-10 20:26:39 <jonasschnelli> sipa, Okay. Agreed.
390 2015-02-10 20:49:25 <rnicoll> General feedback I've received has been it should be Bitcoin related, and ideally Bitcoin Core. Even inter-chain is pushing it a bit, although I'm not aware of a cross-chain channel that's lived any significant length of time
391 2015-02-10 22:40:32 <sipa> ;;nethash
392 2015-02-10 22:40:33 <gribble> 325051584.272