| 04:46:24 | CryptOprah-ZzZzZ: | CryptOprah-ZzZzZ is now known as CryptOprah |
| 07:16:45 | iddo: | looking for comments on deniable encryption for (BIP32) wallets: https://bitcointalk.org/index.php?topic=19137.msg7766059#msg7766059 |
| 08:06:15 | sl01: | the first rule of deniable encryption is you don't talk about deniable encryption |
| 08:24:20 | sl01: | iddo: isn't the issue extremely simple when you're using HD key generation? |
| 08:30:17 | sl01: | random thought: public in person electron microscope service centers... anyone can walk in with a chip, pay $X, and get a png of their chip, then can compare it with others of the same model or compare it against open source specs? Is there a way to manufacture chips with "transparent" tops so they are electron microscope-able with no extra work/damage? |
| 09:37:29 | iddo: | sl01: what issue? |
| 09:46:34 | sl01: | iddo: deniable encryption |
| 09:48:03 | iddo: | sl01: why more simple? |
| 09:49:06 | sl01: | iddo: i guess it's no different it's just when all you need to "hide" is 8 bytes it seems like a simpler problem, but maybe it's not |
| 09:50:05 | sl01: | what if the standard was just: all wallets have 100 HD key slots pre-allocated, and whatever pwd you put in, it checks all 100 slots to see if any decrypt correctly |
| 09:51:28 | iddo: | did you look at posts 298 and 192 ? |
| 09:52:55 | iddo: | smaller size is good because of extra size blowup required for deniability, but BIP32 wallet should store much more than the seed, to avoid re-computations |
| 09:56:43 | sl01: | iddo: apologies missed that you mentioned HD already |
| 11:55:48 | cym: | cym is now known as pen |
| 13:18:57 | Emcy: | https://gist.github.com/irungentoo/58a8b5da5b2becd09e0f who likes crypto challenges |
| 13:19:50 | nshsome: | (the National Crime Agency doesn't) |
| 13:20:45 | Emcy: | https://blog.libtoxcore.so/251/how-the-crypto-tox-uses-works does this crypto schema look at all secure |
| 13:20:52 | Emcy: | i have no idea myself |
| 13:21:22 | fanquake: | fanquake has left #bitcoin-wizards |
| 13:21:59 | Emcy: | nshsome if youre talking about the uk NCA theyre just rebranded SOCA and with more paedoterrism budget afaik |
| 13:22:16 | Emcy: | their cars are black instead of panda coloured |
| 13:30:13 | Emcy: | huh tox has a foundation now..... |
| 14:03:01 | nsh: | Emcy, yeah, they served me with a section 6 RIPA order to 'compel' my disclosure of encryption keying material |
| 14:05:54 | nsh: | Emcy, perhaps ##crypto to discuss this puzzle as it's out-of-scope here |
| 14:28:03 | Emcy: | never mind, i thought it was a crypto challenge |
| 17:19:09 | cym: | cym is now known as pen |
| 19:23:10 | kazcw: | kazcw is now known as justanotherjusta |
| 19:23:18 | justanotherjusta: | justanotherjusta is now known as kazcw |
| 20:08:27 | nshsome: | nshsome is now known as [nsh] |
| 21:18:20 | super3: | hello |
| 21:28:08 | justanotheruser: | hello |
| 21:28:33 | super3: | justanotheruser: how are you? |
| 21:31:32 | justanotheruser: | good, you? |
| 21:32:19 | super3: | just fine, just making some progress on a whitepaper |
| 21:32:22 | justanotheruser: | * justanotheruser is wondering if SNARKs will help me and whether disk space is even worth considering compared to bandwidth used and CPU usage |
| 21:32:25 | justanotheruser: | s/me/Bitcoin |
| 21:32:45 | justanotheruser: | A whitepaper on what? |
| 21:32:56 | super3: | have you heard of Storj? |
| 21:33:35 | super3: | not the gmaxwell bitcoin agents one, the decentralized cloud one |
| 21:33:42 | justanotheruser: | yes |
| 21:34:03 | super3: | yup that. |
| 21:34:06 | justanotheruser: | I'm wondering why a blockchain is necessary for storj |
| 21:34:13 | mappum: | ^ |
| 21:34:28 | mappum: | there is no part of it that needs concensus, right? |
| 21:35:19 | mappum: | file hashes and signatures can live on their own |
| 21:35:33 | super3: | its just a method of organizing and managing the metadata, which can point to any network |
| 21:35:58 | super3: | data is not stored on the blockchain, just the metadata |
| 21:36:15 | justanotheruser: | super3: why does metadata need to be in a blockchain |
| 21:36:36 | justanotheruser: | mappum: I think blockchains are good for consensus AND being used as a buzzword |
| 21:36:49 | super3: | well for example if i wanted to send you a file |
| 21:37:35 | super3: | on the protocol level i would send a standard transaction to your public address containing the metadata for that file |
| 21:37:48 | mappum: | gg germany BTW |
| 21:38:25 | super3: | your client can read the transaction and retrieve the file from the network |
| 21:38:51 | super3: | which can be a url, ip, p2p network, another blockchain, etc |
| 21:38:54 | mappum: | so it's being used as a method of indirect communication? |
| 21:38:58 | justanotheruser: | super3: why is a blockchain necessary |
| 21:39:00 | jgarzik: | super3, So the chain is used for person-to-person messaging, essentially? |
| 21:39:12 | jgarzik: | ephemeral comms |
| 21:39:25 | mappum: | why not just send me an email? |
| 21:40:24 | justanotheruser: | you could just broadcast the "transaction" (more like message) and have the file sent to you and not include it in a blockchain |
| 21:40:48 | super3: | jgarzik: it gets a little blurrier than person-to-person |
| 21:41:04 | super3: | jgarzik: because we can execute application logic based on the data |
| 21:42:03 | justanotheruser: | super3: why does the data need to be in a blockchain? |
| 21:43:39 | super3: | justanotheruser: because node a stores a file on node b, we needs a distributed and open communication system to allow them to operate in a trustless manner |
| 21:44:50 | super3: | node a issues hash challenges to node b to verify that node b is honest |
| 21:45:06 | super3: | and node a issues payment to node b if he is happy |
| 21:45:19 | justanotheruser: | super3: you don't need a blockchain for a distributed open comunication system |
| 21:45:31 | justanotheruser: | you could just remove the blockchain and have everything in the mempool |
| 21:45:32 | mappum: | why not use bitcoin for the payments? |
| 21:45:48 | super3: | but lets say node a wanted to be dishonest |
| 21:46:00 | mappum: | you could even technically use it for the file hashes, except some may not be happy with it |
| 21:46:13 | super3: | a merkle root of the challenges is the the blockchain |
| 21:46:18 | super3: | so node a can't cheat |
| 21:46:47 | super3: | mappum: i want to reintegrate with bitcoin whenever treechains or sidechains magically become a thing |
| 21:47:35 | super3: | justanotheruser: i agree that we can move away from a blockchain with time |
| 21:47:51 | super3: | justanotheruser: but it works quite well for now and also facilitates payment |
| 21:49:05 | super3: | mappum: already have plans to reintegrate as long as we have some sort of pegged asset |
| 21:50:07 | super3: | mappum: i think storj will have to put some developers behind microchannels or micropayments on the bitcoin protocol to make it work nicely |
| 21:50:36 | super3: | bitcoinj is nice, but it would add a bunch of headache to our code base |
| 21:51:02 | contrapumpkin: | contrapumpkin is now known as copumpkin |
| 21:52:23 | super3: | has there been any progress on that outside of bitcoinj that i'm not aware of? |
| 21:55:38 | mappum: | on micropayment channels? |
| 21:55:44 | super3: | ya |
| 21:56:01 | mappum: | i don't think so, but it wouldn't be too difficult to implement |
| 21:56:50 | super3: | essentially just port the bitcoinj's implementation to python |
| 21:57:07 | super3: | somehow... |
| 21:57:24 | super3: | i haven't dived too deep into those waters |
| 21:58:06 | mappum: | well any implementation will be pretty similar. you just make the deposit tx, make the refund tx, have the receiver sign the refund, then broadcast the deposit |
| 21:59:06 | mappum: | i started working on a distributed storage thing kind of like storj a while ago: http://filecoin.org |
| 22:00:09 | super3: | node that storj is focused on building apps and protocol |
| 22:00:17 | mappum: | also blockchain-based, but in this case its because storage is the resource securing the chain, and miners get paid for their storage |
| 22:00:29 | super3: | we would like to implement multiple file algorithms |
| 22:00:39 | super3: | the market and applications can decided which one is best |
| 22:01:06 | mappum: | that's an interesting order of work, usually you design the system before you sell it |
| 22:02:06 | super3: | if you start having something working i'd be happy to support it, and integrate it into our apps |
| 22:02:34 | super3: | yeah its kinda of flipping the model, but i think it works best for this platform and our market |
| 22:03:25 | super3: | you can build file storage application that is distributed and doesn't have points of failures |
| 22:03:40 | super3: | and you build better and better algorithms to make it scale |
| 22:04:20 | super3: | you avoid the two weeks(tm) |
| 22:04:42 | super3: | and it designed to get better with time without actually affecting usability |
| 22:07:12 | super3: | mappum: i like that website, what did you use to build it? |
| 22:09:16 | mappum: | html. |
| 22:10:03 | super3: | ah i see bootstrap in there |
| 22:10:50 | mappum: | i don't think i really used it much though, it would probably look pretty much the same without it |
| 22:11:27 | mappum: | but that was only like 1/1000th of my concern when making that, it's the actual content taht matters |
| 22:11:40 | mappum: | i think that could be a viable solution for asic-proof mining |
| 22:12:52 | super3: | well you would still have large space mining hardware |
| 22:13:21 | super3: | but unlike ASICs, hard drives are quite accessible |
| 22:13:48 | mappum: | preventing big mining operations is a way harder problem to solve |
| 22:14:06 | mappum: | this also doesn't prevent pools or botnets |
| 22:14:41 | super3: | https://speakerdeck.com/super3/storj-crowdfunding-deck |
| 22:14:43 | super3: | slide 8 |
| 22:15:09 | super3: | userspace has more storage space than the entire cloud by orders of magnitude |
| 22:16:00 | super3: | initially it will be very profitable while its a new concept |
| 22:16:25 | super3: | but over a few years it could trend to nearer to zero |
| 22:16:31 | mappum: | you're fundraising? where do you expect to make money? |
| 22:16:44 | mappum: | oh, crowdfunding |
| 22:17:18 | super3: | all the hardware for users is a sunk costs |
| 22:18:54 | super3: | the users will be happy, but it could be the ultimate checkmate for centralized mining in the long term |
| 23:16:59 | rdponticelli: | join bitcoin-dev |