00:21:54 adam3us has quit 00:30:57 liteStrikening has quit 00:31:08 liteStrikening has joined #bitcoin-wizards 00:39:12 tromp has joined #bitcoin-wizards 00:41:04 wallet421 has joined #bitcoin-wizards 00:41:05 wallet42 has quit 00:41:05 wallet421 is now known as wallet42 00:53:01 adam3us has joined #bitcoin-wizards 01:01:44 TD has quit 01:06:39 <[\\\]> [\\\] has joined #bitcoin-wizards 01:14:35 just[dead] is now known as justanotheruser 01:34:03 Luke-Jr has quit 01:36:34 Luke-Jr has joined #bitcoin-wizards 01:45:56 justanotheruser is now known as just[dead] 01:55:51 licnep has joined #bitcoin-wizards 02:00:12 DougieBot5000 has quit 02:11:13 Krellan_ has quit 02:40:17 antephialtic has joined #bitcoin-wizards 02:53:15 just[dead] is now known as justanotheruser 03:01:24 wallet42 has quit 03:02:21 gavinandresen has joined #bitcoin-wizards 03:05:42 justanotheruser is now known as just[dead] 03:11:59 wallet42 has joined #bitcoin-wizards 03:16:05 ssj4mo has quit 03:16:49 wallet42 has quit 03:22:36 just[dead] is now known as justanotheruser 03:33:20 antephialtic has quit 03:33:51 antephialtic has joined #bitcoin-wizards 03:35:17 shinybro_ has joined #bitcoin-wizards 03:42:10 gavinandresen has quit 03:48:29 Emcy has quit 03:48:58 Emcy has joined #bitcoin-wizards 03:48:58 Emcy has quit 03:48:58 Emcy has joined #bitcoin-wizards 04:00:00 Emcy has quit 04:00:30 Emcy has joined #bitcoin-wizards 04:00:30 Emcy has quit 04:00:30 Emcy has joined #bitcoin-wizards 04:20:01 antephialtic has quit 04:31:31 roconnor has quit 04:39:28 <[\\\]> [\\\] has quit 04:45:41 EasyAt is now known as EasyAt|Sofa 04:54:10 justanotheruser is now known as just[dead] 05:12:16 just[dead] is now known as justanotheruser 05:15:18 shinybro_ has quit 05:18:18 roidster has joined #bitcoin-wizards 05:25:23 tromp has quit 05:25:56 tromp has joined #bitcoin-wizards 05:26:48 shinybro_ has joined #bitcoin-wizards 05:27:08 maaku has quit 05:30:01 tromp has quit 05:30:18 andytoshi: should I try to get you a ticket⁇ 05:30:37 antephialtic has joined #bitcoin-wizards 05:30:44 maaku has joined #bitcoin-wizards 05:31:07 maaku is now known as Guest63600 05:31:24 antephialtic has quit 05:32:00 antephialtic has joined #bitcoin-wizards 05:36:16 <[\\\]> [\\\] has joined #bitcoin-wizards 05:40:22 realazthat has quit 05:50:09 antephialtic has quit 05:53:00 licnep has quit 06:03:50 liteStrikening has quit 06:07:13 shesek has quit 06:21:02 ielo has joined #bitcoin-wizards 06:29:03 c0rw1n has quit 06:30:38 shinybro_ has quit 06:33:00 Ursium has quit 06:36:12 iddo has quit 06:36:14 rdymac has quit 06:37:02 rdymac has joined #bitcoin-wizards 06:38:55 antephialtic has joined #bitcoin-wizards 06:43:14 iddo has joined #bitcoin-wizards 06:44:36 justanotheruser is now known as just[dead] 07:13:52 iddo has quit 07:34:46 antephialtic has quit 07:35:25 antephialtic has joined #bitcoin-wizards 07:37:09 oooooo has joined #bitcoin-wizards 07:37:28 MoALTz_ has joined #bitcoin-wizards 07:39:38 antephialtic has quit 07:40:18 antephialtic has joined #bitcoin-wizards 07:48:32 iddo has joined #bitcoin-wizards 08:04:57 ebfull has joined #bitcoin-wizards 08:10:24 roidster has quit 08:10:36 i'm wondering if this idea has been explored at all with developers 08:11:01 right now PoW is used to identify the block which is committed at a particular time (and the transactions it's committing at that moment) 08:11:25 but it has the disadvantage of leaving all of the transactions that occur before the 'next block' unconfirmed, and in limbo (could be double-spent) 08:12:01 what if PoW was used to identify a node which had the 'permission' from the network to begin streaming which transactions they are committing to the UTXO 08:12:04 you propose to equipt people with time machines so they can know about the future? blocks are found instantly... 08:12:28 mmmm let me explain it 08:12:38 ebfull: then then that node could give out multiple feeds of this history in order to make you think that transactions had been confirmed which hadn't. 08:13:17 and could do so indefantly into the future, e.g. years later replacing the content of transactions to a node pulling the chain, with what you've described so far. 08:13:59 ok what i'm saying is, you mine a block which contains your public key, if you're lucky to mine it it's relayed to everybody very fast 08:14:18 now nodes listen for signed messages that the miner uses to demonstrate it has committed a transaction (hash) to the UTXO 08:14:23 but it includes maybe like a sequence number in it 08:14:44 you could prove if the miner is trying to feed multiple accounts of UTXO state to the network at a given time 08:15:09 if he is, then the entire block is discarded and the miner loses their reward naturally 08:15:41 this way, as soon as the miner mines the block, and until the next miner mines a block, transactions are being 'confirmed' (with some degree) 08:15:57 I don't see what you think you've accomplished here. 08:16:23 Transactions already flow through the network and you can't tell for sure if they'll stay in the commitment or not until later. 08:16:46 e4xit has joined #bitcoin-wizards 08:17:07 and you still haven't suggested how the process stops such that the miner can't keep adding transactions forever (thus invalidating future miners signatures) 08:17:31 the block contains a reference to the last transaction the miner saw the previous miner submit to the network 08:17:57 nodes ignore the 'committment' signatures the previous miner propagated right after this reference 08:18:05 which could just be the first one, meaning the next miner can happily remove all the transactions and replace them. 08:19:20 Perhaps you should think it through completely and address these details and post it up, rather than leaving me to discuss guesses at what it might do. :) I don't think this is an especially promising area since everything I've heard that sounded like it turned out to be broken, but I've been wrong many times before. 08:19:36 no i've thought of that already lol 08:20:15 witness miners could be involved in asserting which transaction they saw last propagated by the miner 08:20:16 if the blocks don't contain any transactions, how does a node later on join the network and catch up with what the network consensus of the history is? 08:20:31 And please be clear on what you hope to gain over the current process and demonstrate that you know that mining is effectively instantanious and doesn't involve any fixed delay. 08:22:15 too many points being raised before i can even fully write the idea down and explain the purpose 08:22:19 ebfull: "witness miners" ? so some(?) parties that decided I left out too many transactions from the prior block? How do you decide this? another nested blockchain? :) 08:22:48 e4xit has quit 08:23:09 e4xit has joined #bitcoin-wizards 08:23:56 not a nested blockchain, perhaps in the sense that every 10th block contains the public key of the next miner, and in between are blocks which checkpoint the miner's signed committments that they've witnessed 08:24:18 or perhaps just blocks in between which meet a lower target 08:24:22 not every 10th block 08:24:34 sorry higher target* 08:24:50 basically the point of what i'm doing isn't to prevent double-spends 08:25:05 it's so that point of sale transactions can be 'cleared' quickly with some merit 08:25:27 right now you can't say with any confidence how much of the hashrate is actually preparing to commit a transaction until you see the block 08:25:37 ... then why the complexity ... p2pool already solves this 08:26:11 (or, rather, currently gives you a nice public gauge of hashrate— it could also bind consensus but it doesn't already) 08:26:52 ebfull: though the merit for 'fast' clearance will never be especially good, because you cannot guarentee global communications instantly. 08:26:53 lol 08:26:56 that's true 08:26:59 (not in an anonymous system) 08:28:05 yeah i guess if most miners were using p2pool or it was baked into the protocol it would allow us to determine confidence in a transaction's commitment 08:28:42 you don't even have to change them to use p2pool so much as just have them publish similar data in a similar way... if you do just want a measurement. 08:29:05 and it's also nicely compatible with the existing system. 08:29:09 yeah 08:29:17 what inspired the idea i posted moments ago was an even worse idea 08:29:26 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:29:45 that is, making miners publicly commit to include a transaction in the next block 08:29:58 within a merge mined chain with smaller difficulty than main chain 08:30:26 though I'd like to see you write up your streaming stuff some more. I'm not sure the construction is analyzable... maybe you get something interesting out of the ability to invalidate their subsidy if they conflict. 08:31:03 they could redeem the 'stales' to increase the target of the next block they are trying to mine 08:31:22 and if they lie and don't include transaction, proof of that lie can be used by any node 08:31:53 but this just adds so much overhead and messes with difficulty adjustment in ways i can't imagine so i tried thinking of other ways to make commitment faster 08:32:40 you're vastly overcomplicating that. 08:32:41 basically my streaming idea was just letting the miner say "seq 1 tx " "seq 2 tx " ... until the next block is discovered and a new miner begins streaming the commitment 08:32:45 yeah i know 08:33:24 Emcy has quit 08:33:45 i don't know what you mean by 08:33:50 maybe you get something interesting out of the ability to invalidate their subsidy if they conflict. 08:36:13 sigh yet another pipe dream demolished by gmaxwell :P 08:36:17 thx for walking me through it 08:36:24 wallet42 has joined #bitcoin-wizards 08:44:24 stonecoldpat has joined #bitcoin-wizards 08:44:59 wallet42 has quit 08:52:08 e4xit has quit 08:55:19 e4xit has joined #bitcoin-wizards 08:55:42 MoALTz_ has quit 08:55:51 airbreather_1 has joined #bitcoin-wizards 08:55:54 MoALTz has joined #bitcoin-wizards 08:59:01 airbreather has quit 09:11:20 ens_ has joined #bitcoin-wizards 09:12:59 ielo has quit 09:13:13 ens has quit 09:15:11 ens has joined #bitcoin-wizards 09:16:07 ens_ has quit 09:18:19 ens_ has joined #bitcoin-wizards 09:19:37 ens has quit 09:24:48 adam3us has quit 09:33:38 Hunger- has quit 09:35:38 Persopolis has joined #bitcoin-wizards 09:36:38 ens_ has quit 09:38:39 adam3us has joined #bitcoin-wizards 09:54:45 fanquake has joined #bitcoin-wizards 10:21:31 liteStrikening has joined #bitcoin-wizards 10:23:58 nsh has quit 10:24:20 thrasher1 has quit 10:24:49 thrasher has joined #bitcoin-wizards 10:29:17 cpacia has joined #bitcoin-wizards 10:33:58 TD has joined #bitcoin-wizards 10:52:32 rdymac has quit 10:53:58 go1111111 has quit 10:59:02 rdymac has joined #bitcoin-wizards 11:04:28 antephialtic has quit 11:10:58 iddo has quit 11:12:55 iddo has joined #bitcoin-wizards 11:13:24 adam3us has quit 11:14:20 antephialtic has joined #bitcoin-wizards 11:14:39 Emcy has joined #bitcoin-wizards 11:18:25 antephialtic has quit 11:28:05 adam3us has joined #bitcoin-wizards 11:29:20 Emcy has quit 11:29:57 Emcy has joined #bitcoin-wizards 11:40:53 Is it normal that the network have periods of this bad luck? Two times today with about one hour to next block (ca 70 and 50 min) 11:43:25 airbreather_1 is now known as airbreather 11:44:47 #bitcoin-dev please 11:44:56 this channel is about post-bitcoin development 11:57:07 Emcy has quit 12:00:03 Emcy has joined #bitcoin-wizards 12:00:38 TD has quit 12:04:38 jtimon has quit 12:08:36 rdymac has quit 12:16:42 Emcy has quit 12:17:43 Emcy has joined #bitcoin-wizards 12:21:21 TD has joined #bitcoin-wizards 12:45:37 cpacia has quit 12:46:36 cpacia has joined #bitcoin-wizards 12:56:24 fanquake has quit 13:06:50 asoltys has joined #bitcoin-wizards 13:07:49 Ursium has joined #bitcoin-wizards 13:07:57 rdymac has joined #bitcoin-wizards 13:10:48 ielo has joined #bitcoin-wizards 13:13:24 orperelman has quit 13:23:21 tromp has joined #bitcoin-wizards 13:25:51 shesek has joined #bitcoin-wizards 13:29:51 realazthat has joined #bitcoin-wizards 13:37:01 Luke-Jr: yeah, i'll be around, that'd be cool 13:37:07 tromp has quit 13:37:39 tromp has joined #bitcoin-wizards 13:42:16 tromp has quit 14:05:19 <_ingsoc> _ingsoc has quit 14:08:38 c0rw1n has joined #bitcoin-wizards 14:12:23 cpacia1 has joined #bitcoin-wizards 14:14:10 cpacia has quit 14:43:30 ielo has quit 14:46:49 Guest63600 has quit 14:53:30 maaku has joined #bitcoin-wizards 14:53:54 maaku is now known as Guest24413 14:59:07 Guest24413 has quit 14:59:48 roidster has joined #bitcoin-wizards 15:15:30 shinybro has quit 15:24:18 just[dead] has quit 15:29:08 just[dead] has joined #bitcoin-wizards 15:36:58 <_ingsoc> _ingsoc has joined #bitcoin-wizards 15:39:54 DougieBot5000 has joined #bitcoin-wizards 15:45:53 ielo has joined #bitcoin-wizards 15:51:15 samesong has joined #bitcoin-wizards 16:03:27 cpacia1 has quit 16:03:59 cpacia has joined #bitcoin-wizards 16:12:39 c0rw1n has quit 16:15:24 samson_ has quit 16:15:34 samson_ has joined #bitcoin-wizards 16:20:50 jtimon has joined #bitcoin-wizards 16:31:55 Emcy has quit 16:33:44 Emcy has joined #bitcoin-wizards 16:44:39 WOODMAN has joined #bitcoin-wizards 16:44:46 morning 16:45:07 vdo has joined #bitcoin-wizards 16:45:54 any jobs exist in the world of bitcoin? 16:46:09 try #bitcoin-hosting 16:46:13 research/media/? 16:46:17 thanks pigeons 16:46:47 im interested in new business development and promotions 16:46:56 done cooperative advertisement programs 16:47:07 would rather take on the status quo 16:47:12 than work for the corporation 16:47:17 ill check it out 16:47:51 yeah this isnt the channel 16:49:18 wha tis the "research" going down here? 16:49:31 maaku has joined #bitcoin-wizards 16:49:37 take a look at the topic for starters. 16:49:47 ideas for the future 16:49:54 maaku is now known as Guest82279 16:49:57 that could entail number of things 16:50:03 including new business development and media 16:50:07 andd prommotions 16:50:10 no this is technical 16:50:39 technical doesnt help gain momentum 16:50:48 look at the flaws at litecoin for example 16:51:00 there is a place for everything, and this place is for technical research 16:51:09 theyd just assume cover it up so mainstream gets screwed 16:51:29 this is your job you do for a career? 16:52:34 WOODMAN: If you want an idea of what this channel is, see http://download.wpsoftware.net/bitcoin/wizards/ 16:53:11 vdo has quit 16:59:39 rdymac has quit 17:00:57 rdymac has joined #bitcoin-wizards 17:01:08 e4xit has quit 17:03:47 c0rw1n has joined #bitcoin-wizards 17:04:02 e4xit has joined #bitcoin-wizards 17:14:37 shinybro has joined #bitcoin-wizards 17:15:07 shinybro has quit 17:15:55 jtimon has quit 17:16:43 jtimon has joined #bitcoin-wizards 17:16:54 shinybro has joined #bitcoin-wizards 17:21:28 e4xit has quit 17:21:44 e4xit has joined #bitcoin-wizards 17:42:13 antephialtic has joined #bitcoin-wizards 17:47:13 <_ingsoc> _ingsoc has quit 17:49:10 <_ingsoc> _ingsoc has joined #bitcoin-wizards 17:52:05 c0rw1n has quit 17:52:09 midnightmagic_ has joined #bitcoin-wizards 17:53:06 eristisk has quit 17:53:07 midnightmagic has quit 17:56:14 andytoshi reading this http://download.wpsoftware.net/bitcoin/alts.pdf very well written, tell me when is finished so I can tweet about it (I hope Freicoin doesn't appear as a an example but maybe based on another macroeconomic school or something ;) ) 17:56:41 s/example/example of economic stupidity 17:59:15 jtimon: I've always thought that freicoin was one of the more justified alts (along with namecoin), in that it's trying to achieve something different... even if the differences turn out to be bad. 18:02:08 gmaxwell thank you (of course I think the differences turn out to be good), anything that changes the hasing impeding merged mining already looks suspicious to me, so yeah, I would also say nmc and frc are the "good ones" 18:05:08 i agree; i personally don't find economic changes that interesting (independent of godd/bad, just my personal interest), but at least freicoin isn't "stupid" 18:10:10 eristisk has joined #bitcoin-wizards 18:10:30 I'm sure if I went digging through frecoin I'd find some more conventional altcoiny changes that I'd have an issue with, but I think that anything who's main point of depature justifies their existance is allowed to make their own mistakes in the details. 18:15:53 jedunnigan has joined #bitcoin-wizards 18:16:19 sipa: gmaxwell: i bumped an old thread on txn malleability, please respond there when you can, i'm curious:) https://bitcointalk.org/index.php?topic=405200.0 18:16:38 TD has quit 18:16:38 samesong has quit 18:17:28 iddo: you may want to read https://gist.github.com/sipa/8907691 18:17:32 samesong has joined #bitcoin-wizards 18:17:55 ok looking... 18:17:57 jedunnigan has quit 18:18:08 the main altcoiny change in freicoin that i also think gmaxell might not like is the difficulty adjustment filter, but it was designed and tested for what friecoin needed and seems to do a good job 18:18:57 iddo: that proposal is severely broken and would require a really deep redesign with a lot of difficult to reason about compromises. 18:19:47 pigeons: I think their choise of filter is bad, just from a DSP perspective... I worry about its overshoot creating problems, but since its working in practice I don't see too much reason to whine about it. 18:20:27 the multiprecision integer stuff in it looked scarry to me. 18:20:37 But I'm not sure how much that impacts the consensus code. 18:20:45 spinza has quit 18:20:48 spin123456 has joined #bitcoin-wizards 18:21:05 gmaxwell: ok but i'm trying to understand why exactly it's broken, are there more severe problems than the scenario i described in thread (assuming that we were designing a new cryptocurrency from scratch) ? maybe reply in thread when you have time, so other can see the reasons 18:21:52 gmaxwell: what problems do you see with it? 18:22:05 for a from-scratch designed altcoin, i would certainly consider it 18:22:18 sipa: has the problem of not being able to selectively conflict. 18:22:30 <_ingsoc> _ingsoc has quit 18:22:35 btw that paper is also bad for unrelated reasons, the protocol in figure 3 doesn't enforce the ZK proof to be inside the MPC, so a corrupt party can just switch his share, i.e. their description is sloppy.. 18:22:51 e.g. say you have 10 1btc txouts with a common scriptpubkey. 18:23:24 hmm 18:24:06 Guest82279 is now known as maaku 18:24:09 <_ingsoc> _ingsoc has joined #bitcoin-wizards 18:24:31 samesong has quit 18:24:37 You use 5 of them to pay alice, and 4 of them to pay bob. Then alice complains "hey, this txn isn't confirming, please add fee and reissue, otherwise I'm going to have to take back the icecream I just sold you" ... so you do.. and oops. alice gets paid twice and bob not at all. 18:25:13 gmaxwell: at some point I would like to pick your brain about difficulty adjustment filters 18:25:19 we're not locked into the one we're currently using 18:25:21 gmaxwell, as of today you cant really conflict at all since they wont be relayed 18:25:26 unless you have a special deal 18:25:47 maaku: my general feeling about them is "simpler is better" (and more formally: more linear == better) 18:26:26 gmaxwell: the individual input coins still have unique identifiers 18:26:27 MoALTz has quit 18:26:34 gmaxwell: they just don't depend on signatures 18:26:50 sipa: ah if you're only talking about the signatures then the _only_ issue that remains is that not all signatures are equal. 18:26:59 (that I'm aware of) 18:27:25 it sort of makes signatures "attachments" to transactions that aren't committed to 18:27:49 I'd certantly make the signature an attachment the question is commiting to it. 18:27:51 so seeing a transaction with an invalid signature means it's not necessarily an invalid transaction - someone could just have replaced the signature 18:28:19 but apart from that, i don't see any problems with it 18:29:03 jtimon: don't worry, i agree with gmaxwell's assessment of freicoin (and i sometimes wonder if it's really good for economic analysis because coins do not have indeterminate states, i.e. there are no ancient massive utxos threatening to shock the system) 18:29:03 e.g. I mentioned this on #bitcoin-dev? two weeks ago. e.g. say that a coin can be redeemed in one of two ways— those ways may be legally or technically pretty distinct. e.g. was the coin released by the president or was it released by the board of an org. Did the signature reveal a challenge string or did it not? 18:29:40 jtimon: also you and maaku are completely NOT incompetent charlatons ;) 18:29:57 also the multi-precision math stuff had me worried as well, but deterministic floating point calculations is somewhat a requirement for demurrage calculations... 18:30:28 c0rw1n has joined #bitcoin-wizards 18:30:29 maaku: it's certainly better than using ieee 754 floating point :) 18:30:55 actual IEEE-754 is fine. :P too bad it's impossible to reliably gain access to on common platforms. :P 18:30:58 i decided it was better to add dependencies on MPFR and GMP (which are cross-platform, deterministic by design), even though those are some big added dependencies... 18:31:07 i'd rather not take the risk of consensus mistakes 18:31:17 maaku: yea, has some risk of the issues we've had with openssl however. 18:31:19 maaku: libsecp256k1 will add GMP too, to bitcoin 18:31:31 Dizzle has joined #bitcoin-wizards 18:31:41 e.g. that its authors don't guarentee quite the level of determinism we need. Hard to analyize. 18:32:22 e.g. internal represenation is not determinstic, and maybe something there gets exposed— a behavior difference when the size of the object is different. 18:32:38 samesong has joined #bitcoin-wizards 18:32:50 ... 18:32:50 10:32 < vocodork> lnovy: though afaik scrypt and sha256 start from the same elliptic curve math 18:33:24 gmaxwell: yeah, at some point I want to pull out the handful of functions we actually use and do those as a separate library w/o platform specific optimizations 18:33:27 gmaxwell: ? 18:33:32 gmaxwell: huh> 18:33:36 s/>/?/ 18:33:41 [18:22:51] e.g. say you have 10 1btc txouts with a common scriptpubkey. <-- I don't think it's a problem if this breaks 18:33:44 re: filters, if you have a deterministic way of evaluating filters, I would be happy to evolve a neural network to maximize the "reward" on that creiterion 18:34:19 i'm not sure that i understand the first problem that you were discussing, about signature "attachments" 18:34:39 iddo: Sounds like I was confusing the proposal with a broader one people make. 18:35:29 iddo: Some people suggest leaving out the input txid entirely. It sounds like that this was only proposing leaving the signatures out... in which case my concern is exactly the same as yours. 18:35:51 jtimon: isn't that basically what we did in selecting parameters for our current filter? 18:35:52 jedunnigan has joined #bitcoin-wizards 18:35:58 I don't think it's such an issue though, since you could just have two IDs. The ID with everything and the ID without the signature. 18:36:06 and use the ID with everything where thats applicable. 18:36:09 we manually did a hill-climbing beam search of parameter space 18:36:10 gmaxwell: ok... but sipa and you did mention signature "attachments" that i didn't udnerstand... 18:36:14 However, this doesn't really solve malleability at all. 18:36:36 iddo: sipa means leaving the signature outside of the transaction itself, just a bit of data that proves the transaction valid that you carry along with it. 18:36:40 jtimon: the larger issue I think is seeing if we should have selected an entirely different category of filters 18:36:56 ahh 18:37:21 However, this doesn't really solve malleability at all. 18:37:35 maaku there's an equivalent neural network for any filter of any category you can think of 18:37:38 Because we intentionally want to permit varrious kinds of malleability. 18:37:52 jtimon: doesn't mean you'll ever find it. 18:37:53 :P 18:38:14 hmm 18:38:19 linear filters all have nice closed form least squares optimizations if you can actually name the properties you want. 18:38:22 gmaxwell: if you have a criterion, I'll find it ;p 18:38:30 tacotime is now known as tt_texas 18:39:00 iddo: e.g. as soon as you author an ANYONECANPAY transaction all that behavior tidying goes out the window. 18:39:35 sipa: could make commiting to the signature just a flag in the transaction. 18:39:44 gmaxwell: what kinds of malleability are good to permit? 18:40:06 you really just need to extend this interface https://github.com/jtimon/preann/blob/master/src/genetic/task.h 18:40:06 here's an example for generic classification taks https://github.com/jtimon/preann/blob/master/src/tasks/classificationTask.h 18:40:47 iddo: all kinds are good when you want them. An obvious case is when you want to allow people (e.g. the reciver of a transaction) to later add fees. This can be important for a locked transaction left in storage for a long time. 18:41:07 ahh 18:41:38 (and I think if I were to build a new bitcoin I'd add _more_ of those mechenisms... as the existing ones are a bit blunt) 18:42:16 including, perhaps, just having the signature itself fully decide what its checking in the transaction. 18:42:23 well, this function is probably more useful to undesrtand whet I mean by a deterministic creterion https://github.com/jtimon/preann/blob/master/src/tasks/classificationTask.cpp#L30 18:42:50 e.g. "I sign this coin to be spent in any transaction which pays at least 1 BTC to 1apple or 1dog" 18:43:17 jtimon: I think we're all familar with machine optimization. :) 18:43:46 gmaxwell ok sorry 18:45:23 forrestv has quit 18:46:24 ageis has quit 18:47:14 pigeons has quit 18:48:18 my point is, I have no idea what kind of filter is best, but it's a certainty that there's an equivalent nn which is imo easier to find, you don't have to analize each filter category separatedly 18:49:29 jtimon: having spent basically 15 years working with machine learning regularly in my work, I don't share your enthusiasm. 18:49:49 Its fine as a last resort or when you don't know at all what you even need to start with. 18:50:22 Emcy has quit 18:50:47 gmaxwell and it's not fine when...? because...? 18:50:48 Emcy has joined #bitcoin-wizards 18:51:32 but the training in all of these things is at best a local optimization, e.g. if you try to find filter coefficients with back propagation you'd never find one that doesn't ring— even if the objective loves that, where as adopting a slightly different filter structure eliminates 90% of the dimensions and promises that every filter won't ring. 18:51:47 Humans continues to be surprised cheap, for complex tasks ;p 18:51:52 [*continue 18:52:03 gmaxwell I'm not using back propagation but genetic algorithms 18:52:22 no local minimum problems 18:52:43 jtimon: there is only no local minimum problem if your dimensionality is very small. 18:53:49 with hundreds of dimensions it never is. Maybe you find a good solution, maybe you don't. Reducing the dimensionality in advance via knoweldge of the structure of the problem usually makes things hugely more effective. 18:54:03 gmaxwell you can create random individuals at each step apart from using mutations and cross-over on the existing ones 18:54:39 yes so? go use your genetic optimization to go find my ECC private key. :) 18:54:54 maybe it takes too much time to get the absolute optimal solution but it's not about the algo getting stuck 18:55:42 good point (hmm, maybe I actually try... ;) ) 18:56:26 jtimon: e.g. say that the good solutions are all laying in the hyperplain when 1/4 of the dimensions are exactly 0 and another 1/4 are exactly 1. and there are only bad solutions surrounding the good ones. It is very very unlikely— like guessing my private key— unlikely to ever probe the good space. 18:56:41 ;;later tell nsh here is a short writeup about satoshi-chain based timelock encryption being impossible in real life but easy in CRS: http://wpsoftware.net/andrew/blog/?post=impossible-crs 18:56:41 The operation succeeded. 18:56:54 And at least in my expirence this crops up all the time once you get beyond probablems with 6 or so dimensions. 18:57:15 problems* 18:57:43 so I think that optimization techniques are seldom a replacement for trying to reduce the problem structurally. 18:57:45 gmaxwell yeah I got your point with your ECC example, at that point you're practically doing a random search with the completely new individuals 18:58:19 jtimon: right its an extreme example because the space is completely non-differentiable. 18:58:59 filters in particular seem to be hard to search for, at least in z-space or in direct taps because they're quite numerically sensitive. 18:59:49 maaku: the fact that the filtering isn't on regular uniformly sampled time series data throws out a lot of my expirence and intution. 18:59:52 still I think nn + ga has lots of unexplored potential, one day I'll find time to train my go player that beats human pros with it ;) 18:59:59 antephialtic has quit 19:00:03 ens has joined #bitcoin-wizards 19:02:19 I tend to assume "time tends to infinitive" very often, which is not realistic in too many cases 19:02:49 s/inifinitive/infinite 19:04:41 midnightmagic_ is now known as midnightmagic 19:04:44 eristisk has quit 19:06:35 so there's no particular unknown around malleability now right? ie plug all of the tolerant decoder issues from openSSL, define a single canonicalized valid encoding. the remaining crypto question is if ecdsa is non-malleable now that negative s is declared invalid. people assume so but no proof i guess. 19:07:03 adam3us: andytoshi was trying for a proof but hasn't found one. he does appear to have one for schnorr. 19:08:05 my define the problem away solution to avoid dealing with that question was to hash the public key not the signature. maybe that creates problems? there is no 1:1 commitment between block hash, tx, and txid then. 19:08:07 adam3us: but it depends on what you mean by unknown. All thats stuff just solves the known issues for regular sighash_all transactions with common pubkeys. Do something unusual and it's either unknown again or provably 'unsolvable'. 19:09:25 Persopolis has quit 19:09:30 gmaxwell: hm what is that a complexity argument? to complex to be categorically sure? we need hard non-malleability for dependent transactions to be secure for smart contracts. 19:10:54 WOODMAN has quit 19:11:11 how do you hash the pubkey but not the sig? then the txid algo needs to know the semantics of the input scripts no? 19:11:12 adam3us: you can intentionally write transactions which are _inherently_ malleable. It's a feature, not a bug. 19:13:42 andytoshi: i mean if the addresses are one use, and people writing dependent transactions for smart contracts could reasonably enforce that. then a txid hash replacing the sig for the addr that made it seems equally unique, non-malleable and not to assume the crypto level sig is non malleable 19:15:32 gmaxwell: ok and your example was increasing fees later if something gets stuck. so rather that the tx author can choose up front whether a tx is malleable or not by design. seems slighty conflicted.. for a dependent tx you have to prevent that, and then dependent tx can get stuck because it cant be malleated to add extra fees? or can extra fees be defined as not changing the txid? 19:16:22 EasyAt|Sofa is now known as EasyAt|Stool 19:16:47 so you are suggesting referencing utxos by their hash rather than txid:index? 19:17:27 adam3us: they can decide. 19:17:37 But that doesn't eliminate malleability as a concern. 19:18:13 andytoshi: you can't do that for the conflict-control reasons I mentioned previously. 19:19:30 andytoshi: no just changing the serialization the txid is computed over to be the address, not the signature. ie its a way of saying for serialization purposes any signature from this key is viewed as valid and equivalent. ie precisely what we want: that the siganture is just defined to be non-malleable not by crypto properties but by serialization definition 19:19:48 MoALTz has joined #bitcoin-wizards 19:20:34 adam3us: oh, gotcha, i thought you were suggesting parsing the signature to skip only the ecdsa part 19:21:40 andytoshi: to replace the ecdsa part of Q,r,s with an unambiguous serialization of "a sig by Q" 19:22:14 ok, but right now the only thing that even indicates that you have a Q,r,s pair is the presense of OP_CHECKSIG 19:22:43 so it seems like in doing this, your txid calculation can become intricate because it has to evaluate the script 19:23:38 e4xit has quit 19:24:11 andytoshi: well Q,r,s go into block and the txid now. i am saying Q,r,s go into the block and an (unverified and unverifiable) assertion that there was an r,s made by Q but not the actual r,s bits goes into the txid. if someone wants to vrify the sig, they go do that from the serialization of the tx in the block. the txid then doesnt even change if someone swapped s for -s is the point. 19:24:25 as far khth 19:24:28 ageis_ has joined #bitcoin-wizards 19:24:50 (ssh connection dropped, sorry) 19:25:24 pigeons has joined #bitcoin-wizards 19:25:32 gmaxwell: "but that doesnt eliminate malleability" i am not understanding.. are you saying there is something inherently hard? or that it has to remain possible for the tx originator to chose malleable vs non-malleable on a per tx basis depending on the use case 19:25:48 pigeons is now known as Guest38203 19:26:20 The latter at a minimum. 19:26:28 forrestv has joined #bitcoin-wizards 19:27:15 rdymac has quit 19:28:10 adam3us: ok, understood. i am just hung up on the fact that right now txid is a property of the serialization, with this change txid actually depends on the meaning of the data (eg if i OP_PUSH 70 bytes in an input script, but it's not an (r,s) pair, how is the txid calculation supposed to know this). but i guess that is an implementation detail 19:30:56 adam3us: Right and thats all well and find but it doesn't address two issues: the author of the transaction can (for good reason) not put parts of the transaction under the signature, and not all signatures are necessarily equal. 19:31:16 gmaxwell, i demand signature equality! 19:31:27 rdymac has joined #bitcoin-wizards 19:31:33 For example, of a transaction can be satisfied with one key or another this may have huge significance to an external system. 19:32:38 antephialtic has joined #bitcoin-wizards 19:32:42 Guest38203 is now known as pigeons 19:35:01 gmaxwell: so you are exploring further the multisig case and that if the encoding is at the level of serializing "valid 1 of 3, multisig from keys Q1,Q2,Q3" and maybe someone cares that the sig from Q1 vs Q3. i was not really thinking of that level. but in that case would it not be an encoding of the actual sig slots present? eg serialization of "valid sig fom Q1" and "valid sig from Q2" however that gets encoded - a 19:35:09 ageis_ is now known as ageis 19:36:31 gmaxwell: at least that convention would result in a different txid depending on which keys were used, but within that malleated crypto-sig level are ignored 19:39:01 adam3us: it doesn't have to be key releated. The scriptpubkey could require you to provide a hash preimage for example. 19:39:51 if you're thinking about ECDSA you're thinking at the wrong layer I think— bitcoin transactions are not signed with ecdsa, they're signed with bitcoin script (that includes ECDSA) 19:39:53 gmaxwell: yes i am proposing something quite narrow tho. to replace the serialization of the bits of crypto-sig from Q,r,s to Q 19:40:27 so you would have something like OP_PUSHSIG which the txid calc treats differently (because it is expecting an (r,s) pair instead of just raw data)? 19:40:31 gmaxwell: and analogous for each other crypto-sig type (schnorr etc) if the script doesnt involve a crypt-sig then this serialization is not used 19:40:46 yuck. 19:41:40 I'm yucky because its a bad layering violation. 19:41:42 it's also pointless, since conventional means can remove the malleability completely when you opt out of it without changing anything. 19:41:43 gmaxwell: i suppose the controversial thing would be tht there is a different serialization for txid hash purposes than for tx serialization 19:42:07 suppose you had OP_PUSH_BUT_DONT_HASH, then you could push (r,s) without affecting the txid then push Q and have that affect the txid. would that get what adam wants? 19:42:14 adam3us: you couldn't even compute the hash without having a script execution engine. 19:42:37 andytoshi: no, because I just replace those with regular pushes. 19:43:02 gmaxwell: well. that was my point seemingly there is no proof of non-malleabiliy at the crypto level for dsa. we removed the s,-s one. but we dont know if there are others 19:43:32 gmaxwell: i dont mean to execute, just to serialize the script 19:43:41 gmaxwell: if OP_CHECKSIG would ignore regular pushes for (r,s) then that might work without any layering violations 19:43:41 adam3us: but if you're talking about messy break everything incompatible hardforks: you just use schnorr and we have a proof. 19:44:02 gmaxwell: there being a serialize, deserialize and a txid-hash-serialize 19:44:09 gmaxwell: yeah there is that 19:44:33 gmaxwell: but that also is a layering violation: now its only proven safe for some sigs :) 19:44:33 adam3us: but your txid-hash-seralize has to do non-trivial parsing of the script, e.g. to figure out which values are r,s. 19:45:20 gmaxwell: yes. i suppose there are extremely light bits of code that try to understand as little as possible - enough to verify a tx id i guess. 19:45:45 EasyAt|Stool is now known as EasyAt 19:46:48 so i guess what i am saying is some complexity, but it means you no longer have to care or think about a novel signature property (sig non malleability) that people dont consider as part of signature crypto proofs in other uses. 19:47:28 so from that point of view its more generic. no pointy bits sticking up from a lower layer that you have to be aware of. 19:47:40 adam3us: I can suggest something which is less of a mess there, which is to just drop _all_ the scriptsigs out of the hash if a bit is set that indicate that they aren't in the hash— they'd still get committed to in the block. 19:48:27 so applications which care which sig was used can still check it against the block.. and if the whole scriptsig is dropped out the hashing behavior is much better. 19:48:43 gmaxwell: that'd do it. 19:49:21 fwiw then you do lose the commitment to the specific key used 19:49:43 andytoshi: it would be in the block. 19:50:13 (and I did suggest it as optional in the transaction, though I'm not sure if thats worth the complexity.) 19:50:15 andytoshi: yes. in dependent smart contracts sense you would be saying you dont care. and actually that *is* what the smart contract says 19:50:38 adam3us: right, that's what i'm saying. but maybe there are contracts where you do care, it'd be nice to support that 19:51:00 it's in general a direction I've wanted these systems to go— being able to eliminate all signatures from the historic chain is interesting. 19:51:17 for repudiability? 19:51:22 no, scaling. 19:51:27 though I'd only though of it in the sense of leaving a commitment and taking away the data. 19:51:34 oooooo has quit 19:51:36 most of a transaction size is the signature(s). 19:51:50 adam3us: but i don't see how to support both cases (caring and not caring) without a bunch of complexity, so i guess if you want to support one or the other go with the simpler one 19:51:55 but for verification of the long ago the signatures are completely disinteresting. 19:52:30 andytoshi: well, caring can still be implemented via a block commitment, and I suspect thats enough for most caring applications. 19:52:42 yeah, that's a good point 19:52:49 e.g. a seperate tree of signatures in the block. 19:53:30 (doing things like tearing out the signatures starts to seem even more appealing once you imagine using hash based signatures or SNARKS with moderately large proofs, or things like the 2 way peg which had long proofs) 19:53:35 gmaxwell: i was musing a week or so back (might have said something on here briefly) that you could hypothetically define an spv only system intentionally. eg you discard everything after some block height. (Or only the winning miners even see the data) and just trust the state. 19:54:04 adam3us: thats one of the things on my altcoin page. (also it's something I tried to get namecoin to do) 19:54:18 I have mixed feelings about it generally, certantly it has some applicablity. 19:54:40 <_ingsoc> _ingsoc has quit 19:55:43 gmaxwell: yes its a curious thing. because we defined some new ultimate level of assurance (broadcast and hashrate based sybil resistant assertions), we remain attached to using that ultimate assurance everywhere, even tho its costly and high assurance than any competing system in several ways (eg the sheer number of all full nodes fully verifying at significant cost) 19:56:28 yea... the fact that I'm aware that there is a tradeoff is why I'd ever think it worth bothering thinking about. 19:56:56 gmaxwell: maybe a symptom of the generic threat model observation (unrelated to bitcoin) that if your threat is undefined you protect against anything you could at any cost. where a specific threat you may feel more able to make tradeoffs and optimizations 19:56:58 Hunger- has joined #bitcoin-wizards 19:57:51 the nature of bitcoin really encourages a very broad set of threat assumptions. 19:59:30 gmaxwell: my what-if spv-only variant was relating to committed transactions: what if you only disclosed transactions to winning miners, and everyone else relies on their spv assertion. then you could have privacy, and yet rely on the spv security (except that full nodes cant check, unless they win the hash race so its weaker) 20:01:41 sounds very trusty. E.g. "oh no, all these coins? they were really ours. see here the majority of the moment says so, trust us." 20:02:05 doesn't achieve much privacy either, unless mining is very centeralized. (and if it is, it still doesn't achieve much privacy) 20:02:07 a new what-if. so gmaxwell came up with 2-way pegs between chains. what-if you did a 2-way peg against a private-chain (open transactions like server) which is sort of semi-trusted to declare transaction ordering, but time-stamps its assertions (eg in the blockchain via a time-stamp merkle root) and is audited. a quieting period for returning pegged coins to the main chain, would give auditors time to provide proof o 20:03:00 adam3us: I mean, thats the whole point of my coinwitness thread anti-replay oracle stuff. But it's assuming that the rule for checking the transcripts on return is implemented as a ZK-SNARK proof. 20:03:01 gmaxwell: yeah it was a hokey idea. just a curiosity. poking around the edges because its disappointing that you seemingly cant get long term privacy from committed tx 20:03:21 gmaxwell: yes. committted tx + snark is the other direction. 20:03:27 adam3us: I think you can, if you just have a ZK proof of knoweldge .. yea. 20:05:20 e4xit has joined #bitcoin-wizards 20:06:17 so more on the 2-way-peg to private chain: whats the failure mode. i think the failure is someone completely DoSes all auditors for the duration of the quieting period. and presuming the number of auditors is less than the number of miners. is that worse than bitcoin vulnerability? maybe so because in bitcoin (via router hacker or DoS) people notice and react to hash-rate dips 20:10:15 *(in theory) 20:10:50 I don't think people really do react to hashrate dips today. ... but that can be just some software updates away from being true. 20:11:21 adam3us: you can reshape that, you just have it fail so the coins get stuck if the auditors are down. 20:11:30 e.g. by requiring an affirmitive action by the auditers. 20:11:48 and then you have the classic multisig-chaum-bank offchain model. 20:15:47 gmaxwell: yeah i thought of that but who are the auditors. it should be p2p and anyone-can audit. 20:16:27 well if you want privacy (without fancy zkp stuff) you can't have that. :) 20:16:29 gmaxwell: i guess you could have a mix of affirmative (i verified and see nothing wrong to this timestamp) and anonymous negative auditors 20:16:49 yes, if there is a queting period you could do that. 20:17:59 c0rw1n has quit 20:18:10 gmaxwell: so how do u feel that compares to a side-chain for zero-trust security. the open-tx server feels like a difficulty 0, single miner chain as an analogy (it has a monopoly authority to signing things rather than hashing them) 20:19:22 Well, I think that {too low}-diff pow and 'trusted signers' are very different kinds of insecurity that fail in different ways. 20:19:58 the security difference is less than i was thinking. the known trusted, must answer for tx to clear auditors feel like ripple gws: a group of static known entities k of n of which must reply for tx to clear feels bad/weak. central known things can be DoSed. also the block chain coming from the open-tx server is more easily DoSable as its in a known location / IP address etc 20:20:08 Too low diff pow is so vulerable to disruption that I'm not sure if it would be useful at any wide scale. vs a couple trusted signers scales to any size... it's just fairly brittle. 20:20:42 gmaxwell: yah i dont mean literally, just thta you could think loosely of a signature as a 0-diff hash with only one miner allowed (eg it has a secret key that prevents anyone else mining) 20:21:32 gmaxwell: (just as a mental statement to reason about open-tx server model vs block chain model) 20:21:33 adam3us: right though assuming you have two miners there are better (faster!) consensus mechenisms when you can enumerate the participants. 20:23:26 c0rw1n has joined #bitcoin-wizards 20:26:18 gmaxwell: you can think the main observation of open-tx is that its trivial for one node to scalably order tx; and reasonably easy for third parties to audit the non-double spent status (reordering) relative to an independent timestamp server (which could use bitcion hash rate to commit to its periodic merkleroot) 20:26:59 antephialtic has quit 20:27:58 gmaxwell: however i think so far they envisaged escrowing btc and issuing btc ious at best via a "voting pool". being able to 2-way peg btc to an open-tx server that can be audited is a new variant with slightly better properties - there does not exist an escrow server nor a k of n pool of escrow server that could take all the btc 20:31:04 hm. I may not be following what you're proposing there then. 20:31:29 If it doesn't involve a K of N pool, how do you avoid pushing gigantic full transcripts into the blockchain? 20:36:24 oO 20:36:36 andytoshi: someone who needs your paper https://bitcointalk.org/index.php?topic=492969.0 20:38:53 o.O i'll post it at him and spend a few hours working on it today.. 20:40:06 gmaxwell: well ownership transfer of coins happens as usual (owner has to sign), blocks of tx are constructed. blocks are signed to indicate an assertion by the tx server that all the tx are valid. so in an even lighter spv sense you can just trust the assertion of the open-tx server. there are auditors who download all the blocks, validate them and shout loudly if the server ever misbehaves. now to move a pegged co 20:41:09 adam3us: to me that sounds like k of n pool but perhaps with a very active verifyable consensus thing going on in the pool? 20:41:11 gmaxwell: move pegged coin back to block chain, you provide a signed move tx to the block chain. during the quieting period anyone can step forward to prove something wrong about that. the proof could be a double spend (merkle path for two conflicting values) or something bigger and more basic like it doesnt add up 20:41:33 Okay thats interesting. 20:41:35 gmaxwell: well the k of n pool idea is that the pool actually controls the private keys of the escrowed bitcoins. 20:42:08 Have I shown you the interactive verifyable computation paper that shows that you can get verifyable computation which is secure if at least one server is honest? 20:42:12 gmaxwell: here the bitcoins are still owned by the user. so its still zero trust. your only way to get hacked is to suppress all dissent for the period of the cooling period. 20:43:40 Simple notion: Ask multiple servers to execute your x86 program or whatever and compute a hashtree over every instruction and state transition. They return you your answer and your hashroot. If all of the servers agree you're done. 20:43:47 gmaxwell: i think i may have read your description of it here. but i am more saying trust no one, than trust 1 of n 20:44:00 If the servers disagree you can use log2() probing to find out who is lying. 20:44:15 adam3us: well I think actually you're not.. you're saying these k of n servers are building a transcript. 20:44:27 gmaxwell: i see so it has some similarity with open-tx audit model 20:44:46 and you can then redeem coins on the blockchain.. and if your redeem is invalid you can go start showing parts of the transcript to the block chain to convince it that its invalid. 20:45:35 which actually sounds a lot like that kind of transcript model to me. two people have compeating claims about what the transcript permits... they can't both have followed the rules, so eventually with enough queries you can show that one is lying. 20:45:36 gmaxwell: well i'm saying there is a single open-tx server, that is semi-trusted to do the right thing, but heavily audited, and anyone can provide proof of misbehavior. if proof of misbehaviour happens, all coins are moved back to the block chain rebuilding up to the point before the double-spend happened. and a new server is chosen 20:46:33 okay, I see. thats interesting, but one problem there is that what happens if you attack by bloating the history so that they can't be moved back? (e.g. there is now 500 gbytes of history) 20:48:03 gmaxwell: well u dont need the history, only for no one to have proof of valid object objection a candidate allocation 20:49:41 gmaxwell: i am thinking eg the auditor validation is relatively real time, and so if the open-tx server gets hacked or goes rogue they'll notice within minutes, broadcast their proof, and begin moving back . they just transmit the last indisputable utxo to the block chain 20:50:48 gmaxwell: if utxo is small enough to make that possible, they can thereby transact at higher rate on the open-tx server for the duration of time between server hack/server going rogue. so as the server doesnt gain anything by going rogue its not so useful to hack it. 20:57:59 spin123456 has quit 21:01:14 spinza has joined #bitcoin-wizards 21:06:42 licnep has joined #bitcoin-wizards 21:19:30 crescendo has quit 21:22:49 rdymac has quit 21:24:15 e4xit has quit 21:26:19 e4xit has joined #bitcoin-wizards 21:28:27 rdymac has joined #bitcoin-wizards 21:37:56 jedunnigan has quit 21:38:18 MoALTz has quit 21:38:21 jedunnigan has joined #bitcoin-wizards 21:48:01 Emcy has quit 21:48:25 Emcy has joined #bitcoin-wizards 21:53:12 zooko has joined #bitcoin-wizards 22:08:20 spinza has quit 22:08:21 spin123456 has joined #bitcoin-wizards 22:18:18 Emcy has quit 22:18:55 Emcy has joined #bitcoin-wizards 22:29:36 HM is now known as HM2 22:31:47 jedunnigan has quit 22:32:39 after grepping my logs some apparently flexcoin was a ponzi-looking operation: http://bitcoin.stackexchange.com/a/1430 22:33:54 weren't they going to pay interest or something 22:34:10 thats why I'm saying "ponzi looking" 22:35:30 not if they were lending 22:35:31 go1111111 has joined #bitcoin-wizards 22:35:54 HM2: the interest came out of transaction fees rather than profit on loans, it was a bit of a silly model 22:36:15 last i looked at it, when it first started.. maybe they changed since then 22:37:42 not really a bank then was it 22:37:56 nope 22:39:44 basically they charged fees on outbound tx, and putting funds in/out of a 'cold wallet'. And then paid those fees to people without funds in the cold wallet. 22:47:22 Dizzle has quit 22:48:31 Emcy has quit 22:48:54 pajarillo has quit 22:48:56 Emcy has joined #bitcoin-wizards 22:55:39 samesong has quit 22:58:51 zooko has quit 22:59:03 zooko has joined #bitcoin-wizards 22:59:28 samesong has joined #bitcoin-wizards 23:01:02 cpacia has quit 23:06:49 samesong has quit 23:08:22 samesong has joined #bitcoin-wizards 23:17:24 pajarillo has joined #bitcoin-wizards 23:33:08 there is an exchange that gives 15% of their profits as "interest" of sorts 23:33:23 I think that is bad practice, since it encourages people to keep their coins with them 23:33:37 ielo has quit 23:34:18 jtimon has quit 23:41:08 Krellan has quit 23:41:34 Krellan has joined #bitcoin-wizards 23:52:32 gmaxwell: https://bitcointalk.org/index.php?topic=492969.0 my document is false and i don't represent the community, i'm afraid 23:53:18 lol 23:56:47 i think i've had enough of that board, the stupidity is just too much and every single one of my posts has been met with "your bct post count is too low so i don't believe you" 23:57:23 rdymac has quit 23:57:47 andytoshi: "that board" = bitcointalk.org ? 23:58:05 protip: ignore bitcointalk 23:58:07 zooko: yeah, i guess i mean "that entire site" 23:58:19 sipa: thx, i'm still learning to be pro :P 23:59:47 andytoshi: keep in mind that I asked you specifically to respond to that guy because he was a fool.