00:27:24maaku:maaku is now known as Guest27286
00:28:59Guest27286:Guest27286 is now known as maaku
00:29:29airbreather:I guess open-source code doesn't just review itself...
00:31:27nsh_:* nsh_ muses on the licensing status of human DNA
00:31:52maaku:nsh_: patented unfortunately :(
00:32:08maaku:* maaku thinks LHC should have put a patent on the Higgs boson
00:33:01nsh_:it would have to be a method for isolating the higgs boson, i guess
00:33:55vetch:trademark?
00:36:08maaku:nsh_: well, in the U.S. at least if you discover a gene you are able to patent to get monopoly over any process that uses the biology derived from the gene ...
00:38:28kanzure:yes, but in practice judges don't realize that everyone already has those human genes
00:38:54ielo:maaku, its too general a method
00:39:09ielo:its a logical conclusion method
00:39:13ielo:not a particular method
00:39:34ielo:maaku, very different from discovering a gene or something like that
00:40:15amiller:speaking of bitcoin-wizardry, i announced the Bitcoin survey paper project today https://lists.cs.princeton.edu/pipermail/bitcoin-research/20140417/000004.html
00:40:26ielo:oh wow how interesting
00:42:45maaku:ielo: meh, i think it is analagous. isolating and sequencing a gene is not the same as developing drugs to treat mutations of that gene, and yet one grants monopoly over the other ... sorry, OT for -wizards
00:44:14ielo:maaku, i'm talking about particle detection
00:44:29ielo:there are many synchrotrons in the world
00:44:51ielo:basically also its a many step process
00:44:57ielo:detection, data analysis etc.
00:45:13Guest89342:Guest89342 is now known as roidster
00:48:49nsh_:amiller, accepting (typographical) corrections/suggestions via pullreq?
00:49:24amiller:nsh_, it's probably a bit early for that, but definitely would be welcomed
00:49:39nsh_:* nsh_ nods
00:53:31ielo:off topic
01:02:59ielo:ielo is now known as amillers_boyfrie
01:03:22amillers_boyfrie:amillers_boyfrie is now known as jamesz
01:17:45maaku:maaku is now known as Guest59959
01:29:46justanot1eruser:Looking at the scrollback for the interplanetary Bitcoin, is there a way to prove you're on a certain planet that is cryptographically verifiable?
01:52:49midnightmagic:justanot1eruser: you could make it economically costly to lie.
01:53:20midnightmagic:(that you were a greater distance away than you claim to be)
02:35:00amiller:justanot1eruser, if you have someone you can trust on that planet, you can get cryptographic proof that the person you're probing is within a short communication radius of them
02:40:12amiller:justanot1eruser, i heard a talk about a quantum cryptography "position-verification" scheme last year
02:40:26amiller:that might satisfy your curiosity for interplanetary cryptosystems today. http://arxiv.org/pdf/1109.2563.pdf
02:41:27jtimon:"bitcoin has the limitation of not being able to validate outputs spends in parallel, ripple.com doesn't have that problem because it serializes accounts as a protocol contraint" joelkatz/david swarzth https://www.youtube.com/watch?v=rMGHO90zwhw or "our system is not broken by malleability because it was braken beforehand"
02:41:47jtimon:inputs and otputs, once I doubt about them, it's so clear now that it was a good decision...
02:42:47kanzure:amiller: oh yeah, it doesn't have to be a person, could be a satellite or terrestrial radio tower
03:31:50nsh_:amiller, was it "Position-Based Quantum Cryptography: Impossibility and Constructions"??
03:31:54nsh_:*?
03:34:06nsh_:fascinating territory
03:41:48nsh_:* nsh_ reads http://link.springer.com/chapter/10.1007/978-3-642-03356-8_23
03:46:39Guest59959:justanot1eruser: if you are willing to accept some sort of threshold key signing system, it's relatively easy to tell someone's proximity via an interactive protocol
03:47:00Guest59959:Guest59959 is now known as maaku
03:47:54maaku:that could work for driving consensus forward, but as soon as someone distant gets access to keys they would be able to overwrite with a longer history
03:51:10maaku:amiller: cool, this looks to be just what I was looking for
03:51:18maaku:still lots of work to be done though
04:31:01petertodd:jtimon: in hindsight I probably could have explained it more concretely in my blog post, but even so-called "balance-based" systems end up actually having transactions under the hood if they are going to have any hope of working properly: http://blog.mastercoin.org/2014/02/27/transaction-malleability-and-mastercoin/
04:32:36petertodd:jtimon: specifically “I authorize 1 Mastercoin to be deducted from the balance of address Alice, provided that 1 Mastercoin is added to the balance associated with address Bob, oh, and BTW, this signature is only valid if present in a Bitcoin transaction spending transaction output 0x1234abcde”
04:34:21petertodd:jtimon: the transaction output part is why it works - without it there's no clear ordering. yet trying to imagine that applied to a pure publication system without nicely available transaction outputs to do ordering quickly gets into the problems of having signatures that can be re-used... I'm not quite sure how to express it succinctly, but smells like there is something fundemental about transactions that's required
05:03:58super3:can someone explain to be the bad things that might happen if I have a large number of transactions lets say 100,000 to a single bitcoin address
05:04:29super3:not all at once, of course, but over the course of a few months
05:04:33copumpkin:bad things would happen?
05:05:12phantomcircuit:nothing would happen
05:05:22super3:seems like it would be very difficult for wallet software to be able handle a large number of inputs
05:05:35super3:and we are talking about small transactions like tx fee size transactions
05:05:51petertodd:super3: some wallet software can't handle that kind of thing; other wallet software can
05:05:59copumpkin:oh, if you tried to spend it later you mean?
05:06:04petertodd:super3: if the addresses aren't yours however, your wallet doesn't care
05:06:04copumpkin:and generated a massive transaction?
05:06:58copumpkin:if that's your only source of coin, you might be forced to consolidate it into large units in smaller transactions, then spend those
05:07:01petertodd:super3: e.g. I once wrote a custom python script - AKA wallet software - to spend the "correct horse" txouts, and that script could handle basically any number of txouts efficiently
05:07:26super3:well i'm thinking about a top level application in which you are sending transactions(with data attached) to a specific address
05:07:39super3:so there might be 100,000s of transactions to a "genesis" address
05:08:08copumpkin:remember that addresses aren't really the unit
05:08:28petertodd:well, like I say, there is nothing inherent about such usecases that makes wallet software unable to handle so many txouts - it's just a matter of how your wallet works internally. the bitcoin core one has a number of cases with very bad scaling due to its design
05:08:39super3:ok
05:10:08super3:so can you educate me on perhaps fees(disregarding wallet software) of actually trying to spend the coins consistent of a large amount of small transactions
05:10:41super3:so if i have 100,000 transactions that each sent 0.0001 BTC and i want to spend my total 10 BTC on something
05:11:15phantomcircuit:super3, the basic scaling issue is deciding which outputs to spend to generate a new transaction
05:11:15petertodd:the dead simple "add outputs until I have enough bitcoins" loops here are a good starting point: https://github.com/petertodd/replace-by-fee-tools
05:11:24phantomcircuit:"dust" doesn't much factor into that
05:11:28phantomcircuit:since you can mostly just ignore it
05:12:04phantomcircuit:unless you're sending around like $0.01 worth of btc constantly
05:12:07petertodd:nothing special - just a matter of thinking through what O() complexity your solution has
05:12:38phantomcircuit:petertodd, a lot of it has to do with figuring out how to cache things
05:12:41petertodd:and yeah, just ignoring dust that can't be spent economically is a great starting point to quickly making something efficient
05:12:44phantomcircuit:bitcoin core doesn't cache anything
05:13:10petertodd:phantomcircuit: yup
05:13:20phantomcircuit:that's intentional though
05:13:33phantomcircuit:caching is hard
05:14:15petertodd:phantomcircuit: indeed, which is why I suggest super3 just do something really simple and not try to optimize it on the first try
05:15:44super3:whats the easist and least expensive way to fill a wallet with something like 100,000 transactions
05:15:51super3:basically dust attack my own wallet
05:15:59petertodd:super3: testnet :P
05:16:03super3:ha ha
05:16:06super3:good point
05:17:08super3:although a dying altcoin blockchain would be more fun
05:17:24petertodd:just work out how many bytes each txout will consume, and add up size*fee-per-byte + dust amount for every one of those 100,000 txouts. remember there's a max 100,000 limit on tx size
05:17:46petertodd:super3: nah, huge pain in the ass to get libraries - on bitcoin python-bitcoinlib could do it in something like 10 lines of code
05:18:20super3:oh there is a tx size limit, didn't think of that
05:18:47petertodd:super3: 100,000 "soft" limit, and a ~1,000,000 hard limit - obviously a tx can't be larger than a block...
05:19:23super3:so how many do you think i can fit into a single transaction
05:19:38petertodd:super3: dunno, work it out on a pad of paper!
05:24:29kanzure:regtest is probably the easiest in comparison to testnet
05:24:47petertodd:kanzure: +1
05:39:48super3:is that only in bitcoinj?
05:40:07super3:looking that up now
05:40:24petertodd:super3: bitcoin core has it
05:40:38super3:ok
05:40:49petertodd:python-bitcoinlib has it too, although there isn't yet any code where it matters (compared to testnet)
05:41:38super3:ok that gives me some ideas on that front
05:58:00super3:so how far along is this "sidechains" thing?
05:58:37super3:i've heard the idea, but no whitepaper or proposed implementation
06:07:54justanotheruser:super3: there is a bitcoin talk thread that is more in depth, but from what ive heard, there is no code written for sidechains
06:09:06super3:is this the one? https://bitcointalk.org/index.php?topic=566704.0
06:14:47justanotheruser:super3: https://bitcointalk.org/index.php?topic=277389.0
06:15:17justanotheruser:It is about coinwitness in general
06:15:36justanotheruser:Nothing like a white paper AFAIK though
07:12:05Sangheil-:Sangheil- is now known as Sangheili
08:35:25nsh__:nsh__ is now known as nsh
09:07:12nsh_:nsh_ is now known as nsh
10:35:46airbreather_1:airbreather_1 is now known as airbreather
12:45:13Guest38638:Guest38638 is now known as [Tristan]
13:21:51zzyzx:zzyzx is now known as roidster
13:30:05zzyzx:zzyzx is now known as roidster
13:30:35roidster:roidster is now known as Guest48122
14:03:34jamesz:if we each give x amount of dollars the wikipedia fundraiser would be over in 1 hour, but there will be a new one next year
14:34:26[\\\\]:[\\\\] is now known as [\\\]
14:36:34Guest48122:Guest48122 is now known as roidster
15:10:23maaku:no one hit super3 over the head for proposing a chain spam application?
15:15:54maaku:justanotheruser: the code for side chains would not be very complex
15:15:59maaku:it's an idea not an implementation
15:27:31Luke-Jr:maaku: everyone's too paranoid about breaking his Google Glass
15:27:33Luke-Jr::P
16:46:56shinybro__:shinybro__ is now known as shinybro_
19:17:52c0rw1n_:c0rw1n_ is now known as c0rw1n
20:14:47shinybro__:shinybro__ is now known as shinybro
21:18:51contrapumpkin:contrapumpkin is now known as copumpkin
22:07:27gmaxwell:Y'all will like the fedora signature verification procedure: https://fedoraproject.org/verify basically, download a sha256sum file and a pgp key from the same server... and if it verifies you're good to go. Nevermind that the fedora gpg key they give you is not signed by any other key.
22:09:14copumpkin:lol
22:09:17Apocalyptic:sounds secure
22:09:47copumpkin:I'm glad they give me an HTML page with more details about the key
22:09:52copumpkin:so I can double check their key
22:09:54copumpkin:(on the same server)
22:10:49gmaxwell:they also link to a keyserver at one point, using the 32bit ID.
22:11:22warren:gmaxwell: probably a good idea to raise it on #fedora-admin and #fedora-security
22:11:28warren:or want me to?
22:11:56gmaxwell:I went and asked in #fedora and got a ... not very smart response. (the person did not agree with me that the current setup was pointless)
22:12:10warren:#fedora is useless
22:12:17warren:kind of like #bitcoin is useless
22:12:20gmaxwell:I'm not sure where to raise it. I'd recommend each release be signed by the prior release and some fedora master key that they keep offline.
22:12:36warren:you want me to just copy your messages?
22:13:00warren:#fedora-admin and #fedora-security are the right places to raise it, although its unlikely anyone in charge is there now.
22:13:04gmaxwell:(even more offline than however they manage their rpm signing keys)
22:13:35gmaxwell:warren: sure whatever you think is best. It should be a relatively easy thing to improve.
22:23:28artifexd:artifexd is now known as benkay
22:23:42benkay:benkay is now known as artifexd
22:24:38artifexd:artifexd is now known as benkay
22:24:49benkay:benkay is now known as artifexd
22:25:49rdponticelli:rdponticelli has left #bitcoin-wizards