00:18:51 | wallet421: | wallet421 is now known as wallet42 |
01:45:55 | jgarzik: | crowd, |
01:46:12 | jgarzik: | where is a good place to steal a sha256 implementation in C or C++? |
01:46:39 | jgarzik: | openssl is license-unclean. cryptopp code is too C++-convoluted to cherrypick. |
01:55:43 | jgarzik: | our own is all hacked to pieces |
01:58:20 | Luke-Jr: | jgarzik: BFGMiner? |
01:58:42 | Luke-Jr: | though really, that code originated from your cpuminer O.o\ |
02:03:21 | jgarzik: | Luke-Jr, yah, GPL is incompatible with moxiebox sadly |
02:03:39 | jgarzik: | I think I found one. Shooting for 'simple' rather than 'performant' |
02:04:42 | jgarzik: | something that is easy to stuff into a sandbox :) |
02:09:48 | Luke-Jr: | jgarzik: why openssl? |
02:12:56 | amiller: | jgarzik, what license do you want? |
02:13:31 | amiller: | jgarzik, here's CC license one in javascript you could port pretty easy http://www.movable-type.co.uk/scripts/sha256.html |
02:16:16 | jgarzik: | Luke-Jr, ITYM "why not openssl?" answer: license unclean |
02:16:25 | jgarzik: | amiller, mit/x11 |
02:16:39 | jgarzik: | ideal is simple-C |
02:16:40 | amiller: | CC is close enough i think |
02:16:53 | Luke-Jr: | jgarzik: no, I thought you were saying GPL is an issue because of OpenSSL |
02:17:16 | jgarzik: | Luke-Jr, moxiebox is mit/x11, so GPL is an issue for moxiebox |
02:17:21 | jgarzik: | sorry for being unclear |
02:17:29 | Luke-Jr: | MIT/X11 is GPL-compatible, isn't it? |
02:17:42 | jgarzik: | Luke-Jr, unidirectional |
02:17:44 | amiller: | https://github.com/B-Con/crypto-algorithms/blob/master/sha256.c this one is public domian |
02:39:14 | gwillen: | there's one in cgminer that appears to be permissively licensed? https://github.com/ckolivas/cgminer/blob/master/sha2.c#L93 |
04:35:03 | wallet42: | wallet42 is now known as Guest40763 |
04:35:03 | wallet421: | wallet421 is now known as wallet42 |
04:50:32 | wallet42: | wallet42 is now known as Guest22778 |
04:50:32 | wallet421: | wallet421 is now known as wallet42 |
05:03:00 | wallet42: | wallet42 is now known as Guest78110 |
05:03:00 | wallet421: | wallet421 is now known as wallet42 |
05:09:26 | wallet42: | wallet42 is now known as Guest57057 |
05:09:27 | wallet421: | wallet421 is now known as wallet42 |
05:19:33 | wallet42: | wallet42 is now known as Guest62214 |
05:19:33 | wallet421: | wallet421 is now known as wallet42 |
05:24:35 | wallet42: | wallet42 is now known as Guest47060 |
05:24:35 | wallet421: | wallet421 is now known as wallet42 |
06:02:14 | wallet42: | wallet42 is now known as Guest87334 |
06:02:14 | wallet421: | wallet421 is now known as wallet42 |
06:17:42 | contrapumpkin: | contrapumpkin is now known as copumpkin |
06:22:41 | jgarzik: | woot. |
06:23:01 | jgarzik: | moxiebox builds the runtime and test (32-bit moxie) in the host environment, and now has "make check" |
06:23:06 | jgarzik: | time for bed |
06:23:19 | phantomcircuit: | moxiebox? |
07:05:01 | wallet421: | wallet421 is now known as wallet42 |
07:33:27 | wallet42: | wallet42 is now known as Guest81318 |
07:33:27 | wallet421: | wallet421 is now known as wallet42 |
08:14:40 | wallet421: | wallet421 is now known as wallet42 |
09:40:35 | wallet42: | wallet42 is now known as Guest92729 |
09:40:35 | wallet421: | wallet421 is now known as wallet42 |
09:48:13 | wallet421: | wallet421 is now known as wallet42 |
09:51:21 | wallet421: | wallet421 is now known as wallet42 |
09:56:58 | wallet42: | wallet42 is now known as Guest82252 |
09:56:58 | wallet421: | wallet421 is now known as wallet42 |
10:02:52 | wallet42: | wallet42 is now known as Guest74094 |
10:02:52 | wallet421: | wallet421 is now known as wallet42 |
10:10:01 | wallet421: | wallet421 is now known as wallet42 |
10:12:02 | wallet42: | wallet42 is now known as Guest85269 |
10:12:02 | wallet421: | wallet421 is now known as wallet42 |
10:20:25 | wallet421: | wallet421 is now known as wallet42 |
10:24:45 | wallet421: | wallet421 is now known as wallet42 |
10:33:06 | wallet42: | wallet42 is now known as Guest80410 |
10:33:06 | wallet421: | wallet421 is now known as wallet42 |
11:00:10 | wallet42: | wallet42 is now known as Guest96673 |
11:00:10 | wallet421: | wallet421 is now known as wallet42 |
11:20:40 | atgreen`: | jgarzik: I'm just prepping the toolchain changes for commit now |
11:20:56 | atgreen`: | phantomcircuit: http://github.com/jgarzik/moxiebox |
11:25:19 | fanquake: | fanquake has left #bitcoin-wizards |
12:07:29 | amiller: | you know how eyal&sirer made a version of nonoutsourceable puzzle that can use existing bitcoin mining rigs |
12:08:39 | amiller: | i wonder what would happen if i made the puzzle merge-mineable too |
12:13:15 | amiller: | it would only work for p2pool |
12:13:48 | amiller: | because you have to be able to choose data in your coinbase, in order to put your commitment to the public key you used in a second phase |
12:38:26 | amiller: | well it wouldn't necessarily steer you to p2pool, maybe just to some other pool that lets you choose enoguh of your extranonce space though |
13:27:18 | sipa: | jgarzik: what's the problem with the sha256 implementation in the bitcoin source? |
13:27:49 | sipa: | ah, not simple c |
13:41:33 | wallet42: | wallet42 is now known as Guest96735 |
13:41:33 | wallet421: | wallet421 is now known as wallet42 |
13:48:46 | wallet421: | wallet421 is now known as wallet42 |
13:57:19 | wallet421: | wallet421 is now known as wallet42 |
14:16:20 | wallet42: | wallet42 is now known as Guest99250 |
14:16:20 | wallet421: | wallet421 is now known as wallet42 |
14:35:31 | jgarzik: | Excellent. amiller your sha256 link works nicely, thanks. |
14:35:45 | amiller: | np |
14:35:46 | jgarzik: | as simple-c as it gets |
15:04:32 | amiller: | petertodd, merkle mountain range is essentially the merkle tree accumulator version (rather than rsa accumulator) of the update scheme in this ecash paper http://nozdr.ru/data/media/biblioteka/kolxo3/Cs_Computer_science/CsLn_Lecture%20notes/F/Financial%20Cryptography,%204%20conf.,%20FC%202000%20Anguilla(LNCS1962,%20Springer,%202001)(ISBN%203540427007)(389s)_CsLn_.pdf#page=63 |
15:04:46 | amiller: | which i finally understand after being confused about it for dunno months |
15:04:55 | cfields: | jgarzik: i'll ignore the host/target thing for now, since it's something that every project ends up having to solve in its own way. |
15:05:42 | jgarzik: | cfields, if you cross-compile, then sandbox is built for your cross compile target system. |
15:05:57 | jgarzik: | cfields, nevertheless, runtime/ and tests/ remain moxie-elf, always. that is constant. |
15:06:17 | jgarzik: | cfields, that's the root of the configure.ac/*.am weirdness |
15:06:20 | jgarzik: | |
15:06:23 | cfields: | jgarzik: i see. so it's pretty backwards from the way most projects are built (and understandably so) |
15:06:37 | cfields: | ok, understood now. thanks. |
15:06:59 | cfields: | jgarzik: to save me a bit of poking: are libcrypto/libelf used by the moxie toolchain or host? |
15:07:01 | jgarzik: | cfields, "sandbox" is a normal application, and should be considered such. Any build/host/target abnormalities should highlighted and crushed. |
15:07:19 | jgarzik: | cfields, those are just used by "sandbox" |
15:07:27 | cfields: | ok |
15:07:56 | cfields: | jgarzik: those need proper location checks, rather than just ac_check_lib |
15:08:01 | jgarzik: | cfields, +1 |
15:08:21 | cfields: | not sure about libelf, but openssl is pkg-config'd for sure. you can just steal that one from bitcoin |
15:08:54 | cfields: | jgarzik: want me to fork it and hack and send along a PR? or were you just looking for criticisms? |
15:10:55 | cfields: | jgarzik: ok, i've got the build/host/target thing worked out now. target is forced, but build/host should be treated normally. In that sense, it's not all that strange. |
15:23:24 | atgreen`: | jgarzik: I just committed changes for a moxiebox-* toolchain upstream. |
15:23:50 | atgreen`: | jgarzik: also sent you email w/ the one missing bit (config.sub). it has to go through a separate process. |
15:23:51 | atgreen`: | it' |
15:24:24 | atgreen`: | s nice because moxiebox-gcc knows about endianness, libsandboxrt.a, etc, and - eventually - the new crypto instructions. |
15:31:34 | jgarzik: | cfields, target is not forced in all cases |
15:31:42 | jgarzik: | cfields, just certain subdirs |
15:31:54 | jgarzik: | atgreen`, cool |
15:32:08 | jgarzik: | cfields, PRs appreciated! |
15:32:15 | cfields: | jgarzik: right, i meant in the moxie target cases |
15:33:15 | cfields: | jgarzik: ok, will do when i can find some time this week |
15:50:42 | atgreen`: | jgarzik: you can just update your gcc, binutils-gdb, src trees, copy in the config.sub file to each of those, and run the build script |
15:50:52 | atgreen`: | I have to run now, but I'll be on email |
15:51:15 | jgarzik: | atgreen`, ACK. I'm off-moxiebox for most of the day |
17:01:41 | maaku: | maaku is now known as Guest89655 |
19:22:22 | go1111111: | andytoshi: I notice a decent amount of missing days at http://download.wpsoftware.net/bitcoin/wizards/, most recently July 21 through July 24th is gone. any plans to fill in the gaps? |
20:15:55 | gmaxwell_: | gmaxwell_ is now known as nullc |
20:16:04 | nullc: | nullc is now known as gmaxwell |
20:31:45 | wyager: | wyager has left #bitcoin-wizards |
21:17:52 | andytoshi: | go1111111: not -plan- plans.. |
21:18:05 | andytoshi: | but yeah, i should fill them in. several people here have offered me complete logs |
21:20:47 | petertodd: | amiller: yup - MMR's are only a minor optimization of sparse merkle trees for cases where you want proofs of recently inserted items to be small. I'm dubious the extra complexity of them compared to sparse merkle trees is actually worthwhile in anything but timestamping. |
21:29:14 | go1111111: | ok, if you don't think you'll fill them in soon, I'd be interested in directly getting a set of complete logs from one of the people who has them. can anyone help? |
21:29:38 | go1111111: | andytoshi: or if I can somehow help make the process less of a hassle for you, i'm happy to help fill in your copy |
21:33:42 | andytoshi: | go1111111: so, you can look at the existing HTML files. they have a very simple format... if you can convert your logs to that, that's all that needs to be done |
21:33:56 | andytoshi: | one sec, i'll gist the file that i'm currently using to translate the andytoshi-logbot logs to HTML.. |
21:34:32 | go1111111: | i sadly have super sparse logs, but if someone else were to send me complete logs, I could do that. |
21:35:03 | andytoshi: | https://gist.github.com/apoelstra/3b1b765f0d4db485886f |
21:36:12 | andytoshi: | so, andytoshi-logbot is a terrible perl script which is dumping plaintext logs to an irritating adhoc format. i have a cronjob which (a) runs that python script, (b) ships the output over to the server |
21:36:28 | andytoshi: | web server*. every ten minutes or something |
21:51:48 | Guest75730: | Guest75730 is now known as DonnchaC |
22:38:14 | tifozi: | tifozi has left #bitcoin-wizards |
22:40:42 | kanzure_: | kanzure_ is now known as kanzure |
22:46:07 | nsh: | Providing better confidentiality and authentication on the Internet using Namecoin and MinimaLT. (arXiv:1407.645... http://ift.tt/1nYNaKI (@arXiv_cs) |
22:51:40 | petertodd: | wiretapped: so, what's interesting about PoW PoP is that the more users you get on any given system the more secure it is, as to attack one user/class-of-users you have to attack everyone |
22:52:16 | petertodd: | wiretapped: equally, it's interesting that any given user/class-of-users will be annoyed that the other users/class-of-users exists... which is exactly what we're seeing on bitcoin |
22:52:38 | wallet42: | wallet42 is now known as Guest26214 |
22:52:38 | wallet421: | wallet421 is now known as wallet42 |
22:52:40 | wiretapped: | Eliel: why is your system only interested in PoE and not PoP? |
22:53:30 | Eliel: | wiretapped: mostly because I have not had an epiphany about a nice way to make the system do PoP too yet. |
22:54:10 | wallet421: | wallet421 is now known as wallet42 |
22:54:46 | petertodd: | Eliel: well, timestamping isn't a very interesting problem frankly... I'd be inclined to stick with bitcoin if all you can do is timestamp stuff |
22:54:52 | pigeons: | well "annoyed" cause there's no real way to charge them for resource usage, so there comes a point you can't donate relaying and verification and storage to all these other uses |
22:55:00 | jgarzik: | sigh. PoP? |
22:55:00 | petertodd: | pigeons: yes there is, tx fees |
22:55:07 | petertodd: | jgarzik: proof-of-publication |
22:55:30 | pigeons: | how do tx fees pay the annoyed non-mining nodes that are paying to relay, verify, and store |
22:55:40 | nsh: | if bitcoin fails at everything else, at least it's enabled a vein of empirical theoretical cryptographic research that's without precedent (modulo my ignorance)... |
22:55:48 | nsh: | (thoughts looking at https://bitcointalk.org/index.php?topic=697291.0) |
22:55:54 | jgarzik: | nsh, that's it's greatest legacy |
22:56:04 | nsh: | time will tell, but it wouldn't surprise me |
22:56:16 | dsnrk: | * dsnrk glances at the 1.4M posts in the altcoins subforum |
22:56:21 | petertodd: | pigeons: by participating at bitcoin you have agreed to participate in a system with known costs. |
22:56:33 | jgarzik: | nsh, bitcoin is far from perfect itself. but it leaves a legacy as a catalyst of crypto research, creation of "digital friction" and scarce digital resources |
22:56:44 | nsh: | * nsh nods |
22:56:56 | wiretapped: | petertodd: i do like systems which cause people with seemingly conflicting interests to cooperate :) |
22:57:31 | petertodd: | pigeons: tx fees just provide a market mechanism to proportion access to that limited capacity system. equally, with tree-chains notice how it's the exact same situation, but you can trade-off security for capacity |
22:58:31 | petertodd: | wiretapped: well, "cooperate" might be a bit of a strong word here - what's interesting about pop is the other side has no choice about it - either you accept that people can use bitcoin to publish data at some cost, or you destroy bitcoin. There's no way to avoid it. |
22:58:40 | randy-waterhouse: | king solomon's mines |
23:00:10 | dsnrk: | petertodd: alienating people with influence over development isn't a technical limitation, but probably has the largest impact of all. |
23:00:31 | wiretapped: | petertodd: i don't know how your system works, but i think actual data storage in bitcoin can be made *very9 expensive without destroying bitcoin's primary function |
23:00:35 | petertodd: | dsnrk: it used too, until people realised that those people with influence couldn't actually do anything |
23:00:46 | wiretapped: | eg gmaxwell's preimage proposal |
23:00:55 | petertodd: | wiretapped: ah, you're thinking of P2SH^2, unfortunately it actually makes the problem *worse*, not better |
23:01:18 | wiretapped: | how so? |
23:01:23 | petertodd: | wiretapped: with P2SH^2 you still get proof-of-publication, but now every publication is guaranteed to create a unspendable UTXO |
23:02:00 | wiretapped: | how do you even get proof of publication? if i mine my own block i can still include a hash of something nobody has ever seen |
23:02:21 | petertodd: | wiretapped: because to relay your block you have to provide the preimage according to the rules of P2SH^2 |
23:02:39 | dsnrk: | petertodd: well that's nonsense. if people are annoyed enough they just stop contributing to bitcoin, and that's the end of that. you've seen how altcoins go without the right people at the helm. |
23:02:43 | wiretapped: | ah for blocks too, i was thinking just for txns relaying |
23:04:07 | petertodd: | wiretapped: yup. also notice how you'd need to radically limit the scripting system for it to be useful - you can always put your data in scriptSigs, as my blockpop library implements |
23:04:26 | petertodd: | dsnrk: like I said, you can stop PoP, but at the cost of destroying bitcoin |
23:05:09 | dsnrk: | petertodd: that's not what I said. if people are annoyed enough that this sort of thing is happening, it has the same effect. |
23:06:32 | petertodd: | dsnrk: you're still missing my point: all the outrage in the world hasn't succeeded in stopping people from using bitcoin as a PoP system. Outrage can't overcome the fact that it's a very useful capability that nothing else can offer with the same security level. |
23:07:36 | dsnrk: | petertodd: I wouldn't say that, just because you can't measure disdain doesn't mean it doesn't have a tangible impact on community and development. |
23:08:52 | petertodd: | dsnrk: look, it's a very simple measurement: Does Counterparty, Mastercoin, Coloredcoins etc. still exist? Yup. |
23:11:44 | randy-waterhouse: | higher fees will solve any perceived blockchain bloat |
23:11:51 | randy-waterhouse: | maybe lower the block limit? |
23:12:01 | dsnrk: | petertodd: you're ignoring what I'm saying. their continued existence doesn't say anything as to the opinions of the people that contribute to the bitcoin core. equate it to mistletoe, suck too much and you kill the host. |
23:12:06 | nsh: | cf. http://www.dmoz.org/ :) |
23:13:10 | nsh: | (or, existence is a poor proxy for potential, in the long tail of great web museum) |
23:19:23 | gmaxwell: | petertodd: lots of trivially insecure things sill exist, just because no one (currently) cares to do anything about the... existance isn't an argument for soundness in the slightest. |
23:30:07 | petertodd: | gmaxwell: you just proved my point - even if pop isn't sound, people will still do it |
23:31:36 | petertodd: | dsnrk: if this is a mistletoe situation, then bitcoin damn well better figure out how to deal with it sooner rather than later, before we do silly things like utxo commitments that force storing the entire utxo set for eternity |
23:33:45 | dsnrk: | petertodd: that's a terrible argument. there's an altcoin which is based around the idea that you can stop people from mining more than one block every 100 by monitoring addresses. the fact that it exists says nothing about it's security or reasonability, just that it exists. |
23:35:55 | dsnrk: | petertodd: what if we can't stop it? the only outcome is to buckle under the force of all the people who want to "build on the block chain". the only reason it works now is because there's a low number of peopel trying to do it, and that nobody uses those services because they're clucky and ill conceived. |
23:36:29 | randy-waterhouse: | clucky or clunky? |
23:36:37 | dsnrk: | clunky. |
23:36:56 | randy-waterhouse: | i liked clucky |
23:37:07 | dsnrk: | IPO scams, not chooks. |
23:37:11 | petertodd: | dsnrk: lol, services like "make sure I'm downloading the non-backdoored copy of tor as everyone else" aren't clunky |
23:37:59 | petertodd: | dsnrk: equally zerocash will very likely be implemented as a 51% proof embedded consensus system |
23:39:01 | randy-waterhouse: | dsnrk: one way to stop it would be to build better alternatives |
23:39:12 | randy-waterhouse: | cheaper, faster, better alternatives |
23:39:51 | petertodd: | randy-waterhouse: indeed, unfortunately all those alteratives have worse security, which appears to be a fundemental issue |
23:40:37 | randy-waterhouse: | those would not be the better ones then |
23:41:11 | petertodd: | randy-waterhouse: you realzie that if you come up with a better alternative, you've come up with a better version of bitcoin itself right? |
23:41:23 | randy-waterhouse: | not necessarily |
23:41:43 | randy-waterhouse: | there's some wiggle room in there ... if you look close enough |
23:42:14 | dsnrk: | petertodd: what I've seen of things "built on bitcoin" are all completely ill formed and make strange assumptions about their use. as far as I'm concerned the only reason Mastercoin and Maidsafecoin exist are to make their owners rich, far from their stated goal of saving the world with computation/shares/whatever. to that end they don't have any desire *not* to be clunky, it's not a required part of the process. see: mastercoin not even maintaining c |
23:42:15 | petertodd: | randy-waterhouse: yes I know, I proposed one of the first versions of that wiggle room over a year ago with zookeyv on this same channel, but that wiggle room is limited |
23:42:50 | petertodd: | dsnrk: those are all limitations of particular implementtions of an idea; again, consider my zerocash example |
23:42:59 | sipa: | not even maintaining c? |
23:43:24 | dsnrk: | when I looked into it there were at least 3 different mastercoin clients with different ideas of what was going on in their network. |
23:43:28 | petertodd: | dsnrk: if you want a zerocash scheme with the same security as bitcoin without the co-operation of bitcoin miners, it will end up being an embedded consensus system. |
23:44:05 | petertodd: | dsnrk: like I said, limitations of an idea. it's unfortunate that the first people doing stuff with embedded consensus systems happened to be not smart enough, but that's life |
23:44:30 | dsnrk: | petertodd: I think I'm missing zerocash background, I have no idea what you're talking about. |
23:44:53 | petertodd: | dsnrk: simple: how would you implement zerocash with the same 51% security as bitcoin? |
23:45:09 | dsnrk: | merge mining? |
23:45:21 | petertodd: | dsnrk: that's less secure than bitcoin, significantly less |
23:45:49 | randy-waterhouse: | aren't they suggesting side-chains? |
23:46:11 | petertodd: | side-chains are significantly less secure than bitcoin |
23:46:25 | nsh: | petertodd, (sorry if this is stupid) what exactly does embedded consensus mean? |
23:46:41 | nsh: | (or in what is it embedded...) |
23:46:50 | dsnrk: | nsh: it's the whole pegging other things to bitcoin by shoving crap into our block chain. |
23:46:51 | gmaxwell: | No one can know what the embedded consensus means, you must expirence it for yourself. |
23:46:52 | petertodd: | nsh: you achieve consensus by examining a host consensus system's blockchain data |
23:47:01 | nsh: | ah, okay |
23:47:05 | nsh: | * nsh nods |
23:47:10 | randy-waterhouse: | you will know it when you see it? |
23:47:50 | petertodd: | nsh: main property is obviously it has the same reorg security as the host blockchain, and tends to require at least linear-sized history proofs of whatever you are doing |
23:48:39 | randy-waterhouse: | "tends to"? |
23:48:43 | nsh: | mm, and the host requirements can be reduced to (partial-)ordering and uniqueness of commitments? |
23:49:02 | petertodd: | nsh: yup, which utxo commitments will do... |
23:49:34 | petertodd: | randy-waterhouse: there's some clever stuff you can do with moon math, but O(n) is certainly doable for many applications |
23:49:52 | nsh: | * nsh envisions all sorts of pseudo-ecological papers on hierarchical distributed-systems carrying capacities... |
23:50:12 | randy-waterhouse: | moon math = rocket science? |
23:50:52 | petertodd: | randy-waterhouse: rocket surgery at least - rocket science is a lot easier than most people think |
23:51:02 | randy-waterhouse: | oh really? |
23:51:27 | petertodd: | randy-waterhouse: yes! compared to the hardest fields out there it sure is. what makes rocket science hard is mostly that if you fuck up the consequences are huge |
23:51:36 | nsh: | or maybe more like rocket science without the rockets because there's this giant orbiting common-reference-string that can sky-crane all of your load up to infinite and beyond... |
23:51:45 | nsh: | *infinity |
23:52:12 | petertodd: | randy-waterhouse: I mean, hell, my last job was for a company that was doing stuff about an order of magnitude more difficult than rocket science. (measuring gravity in an airplane) |
23:52:13 | randy-waterhouse: | played with shock equations recently have you? |
23:52:41 | petertodd: | randy-waterhouse: lol, nope - I'm not a rocket scientist |
23:53:13 | nsh: | petertodd used to do that thing with y-shaped sticks where you wobble them about to find water, except with more money and more gyroscopes :) |
23:53:25 | randy-waterhouse: | ah moon math |
23:53:29 | sipa: | and _science_ |
23:53:42 | nsh: | all science is subsumed within the gyroscope |
23:53:54 | petertodd: | sipa: well... last I heard they're on the verge of bankruptcy, so I dunno about that... |
23:54:40 | petertodd: | sipa: 80% of the staff got laid off just after I left |