00:00:00amiller:not every user has to be mining, even with pos
00:00:11amiller:you don't have to make every signature a one time signautre
00:00:16amiller:only the ones eligible for use in pos
00:01:01amiller:i gues you're aying to use it for other things not pos
00:01:03amiller:i see
00:01:03adam3us:amiller: so you mean the kind of PoS where you sign something proving stake, publish it on the block chain, then are able to vote some blocks later?
00:01:37amiller:adam3us, yeah, something like that.
00:01:52adam3us:amiller: the sender is limited to aborting the transaction by paying to miner (rather than taking the funds himself maybe)
00:03:34adam3us:amiller: well if the definition of what to sign is extremely unambiguous (so you'd sign the bitwise same thing again if you crashed) then it could be safe. or do you mean that worst that happens is someone takes your vote? if its a separate voting key to avoid risk of needing spending keys online to vote
00:06:11amiller:no you have to lose real coins not just your vote, that's the "somethings at stake" part
00:06:12adam3us:amiller: other than the transactional / crash / accidental double-spend issue, it could be quite interesting to use as the standard way to sign
00:06:30adam3us:amiller: for actual payments
00:06:31amiller:if you're using your coins to mine, then write your vote to a log first
00:06:48amiller:if you can't do that, then you're basically making the network be lenient when you double vote and say "oops, forgot my file"
00:09:20amiller:fwiw i do *not* think that pos can work and i want to prove some kind of an impossibility result explaining just what "burnt work" gets you that pushing around virtual data doesn't
00:11:30sipa:amiller: what "log" ?
00:12:04sipa:there is no log that you could meaningfully append that that remains consistent in the presence of blockchain reorgs
00:12:35amiller:sipa, this is for a really specific use case, burning coins for pos mining
00:12:38sipa:unless we get a meta blockchain, whose only purpose os to record which coins have been used as a vote to mine whivh blocks
00:12:52amiller:it only needs to be locally consistent
00:12:54sipa:is, which
00:13:14sipa:how so?
00:15:00tt_away:i'm not sure that pure PoS can work, although it sort of does with nxt.
00:15:15sipa:nxt is a joke, sorry
00:15:19tt_away:nxt is so poorly documented that not a lot of people understand it though.
00:15:32tt_away:the block generation mechanism anyway.
00:16:03sipa:i'm pretty sure that pure nxt cannot work
00:16:13tt_away:sipa: well, you can tell that from the looking at the one file source code...
00:16:17tt_away:pure nxt?
00:16:34sipa:unless you get all miners to agree to never to try to extend forks
00:16:36amiller:sipa, suppose you can only pos-vote with coins that are 20 blocks old and we dont have to worry about reorgs that far
00:16:40sipa:without any good reasom
00:16:55tt_away:sipa: there's no possibility of that because the list of miners is ordered and predetermined.
00:17:15amiller:sipa, if you 'burn' a coin by writing a signature to vote for a block, it doesn't matter if there's a small reorg, you don't need to unwrite that burn event, the whole point is it should stay burnt and you shouldn't use it even if there's a small reorg
00:17:24tt_away:i'm implementing another type of pos system soon too, but that's dependent on pow to prevent forks.
00:18:07sipa:amiller: where do you write the vote?
00:18:13amiller:to a file
00:18:22amiller:to a dozen files
00:19:01amiller:you just want to be sure that if you publish it to a peer on the network, you don't crash, forget you did that, and try to use the same coin to vote for some different block, which would lose your coin
00:19:19sipa:so, if i try ton reuse the same coin to vote on a fork
00:19:34sipa:any peer who has seen my old vote will reject the new block if it wins
00:19:46sipa:but those who have not seem the old vote will accept it
00:19:53amiller:worse, they'll reject the peer and *spend* your whole coin, which otherwise you'd have gotten some of back somehow or something liek that
00:19:55sipa:sounds like a great way to cause more forks
00:20:13tt_away:i couldn't figure out how to do pos without pow to select the chain and i spent at least a little while on it.
00:20:27gmaxwell:midnightmagic: most altcoins that fail do so without extensive analysis. Unfortunately because they are almost universally based on really old codebases or known stupid changes the probablity that they failed for dumb reasons is too great to make it worth the effort.
00:20:58amiller:hm, you're saying that a block could be accepted for a while, *then* you publish a second vote, and if that 'cancels' the vote then you'd have to rewrite a bunch of history
00:22:53sipa:i'm saying that the criteria for acceptance of a block must be consistent across the network
00:23:12sipa:which means if cannot rely on state outside of the chain being verified
00:23:26sipa:unless you have something to force consistency
00:23:39sipa:which is the whole point we're trying to solve
00:24:51andytoshi:if we identified txouts by their content rather than txid:index, i think consistency would be easy. but still maybe not desirable for payments eg if you want to change fees
00:25:24nsh:(sounds like an unrelated problem)
00:25:36amiller:sipa, ok so is that a clear way to argue that nothing like pos can work?
00:25:48amiller:it's not possible to have anything at stake if you have choice about which future fork you're voting for
00:25:52andytoshi:well, not really, there are lots of cases where you want to change your outputs and there is no context-free way to determine which are "malicious" double-spends
00:26:14amiller:because the consistency of one fork can't depend on the non-existence of an unrelated fork since that's necessarily 'external' of the fokr
00:26:22andytoshi:but these guys are talking about PoS anyway, i'll shut up and maybe i'll learn something
00:26:39nsh:andytoshi, i meant rather that it's mostly-orthogonal to the problem of network consistency/convergence
00:26:42tt_away:well, a nxt style follow the satoshi scheme sort of works, unless you get a string of malevolent miners.
00:26:46nsh:but there will be interrelations, undoubtedly
00:31:32sipa:amiller: i'm not sure it's enough of an argument to construct a proof
00:32:08amiller:it's a start, it would be nice to characterize a large class of attempts towards PoS and give a general argument why they don't do what they claim
00:32:30sipa:amiller: i think the mechanism you describe (have txouts used for voting recorded out-of-chain locally in each node) can work for block shunning
00:33:06tt_away:yeah, there are many proposals for pos systems.
00:33:09sipa:amiller: but it can't be used for validity (you have to accept a block if it's being built upon by others, as they may not agree with you that the signature was seen already)
00:33:29tt_away:if sipa's description is correct, that's the scheme i'm using.
00:33:45sipa:and i'm not sure whether shunning adds anything at all, in theory
00:34:13tt_away:it can at least force miners to include tx on the network that were broadcast to all of them.
00:34:37tt_away:and destroy the pow reward if they don't.
00:35:32tt_away:nothing enforces bitcoin to be a consensus network of tx, really. every miner can just broadcast empty blocks if they really want, although they're incentivized not to.
00:35:52sipa:that still builds consensus
00:36:01tt_away:this is true.
00:36:02sipa:it may not be one that non-miners want
00:36:13sipa:but that's a different (and much harder) issue
00:36:17Luke-Jr:sipa: what consensus does it build? :p
00:36:19tt_away:i mostly want to play around with it and see how well it works.
00:36:42sipa:Luke-Jr: a globally eventually-consistent transaction history
00:38:08tt_away:i hope to have an alpha out in 3-6 months, then i'll see how badly people can mangle it i guess.
04:00:43Sangheil-:Sangheil- is now known as Sangheili
04:29:28hno:Is transactions with a value of 0 valid? Looking at a pool implementation and notice that it can easily include 0 value transactions in it's generation transaction.
04:30:13gmaxwell:they are, but they're non-standard. I wish they were invalid.
04:42:53Luke-Jr:hno: p2pool does it
04:56:58nOgAnOo:gmaxwell, how's your relationship with Jesus Christ?
04:57:10nOgAnOo:You can't take your bitcoins to hell with you you know..
04:59:40Luke-Jr:nOgAnOo: that's totally off-topic here..
05:07:26fanquake:fanquake has left #bitcoin-wizards
05:10:51nOgAnOo:nOgAnOo is now known as n0g
05:11:02n0g:n0g is now known as nOgAnOo
06:49:10maaku_:gmaxwell: why? isn't it useful to have a txout as a semaphore object?
06:52:57gmaxwell:maaku_: makes the maximum size of the utxo infinite instead of 44 petabytes, and leaves you with absolutely no incentive to clean up your dangling semaphors.
06:55:48copumpkin:Luke-Jr: ^ :)
06:56:26copumpkin:ssj4mo is in here too :P
06:56:32copumpkin:oh wait, he survived this time
06:58:41gmaxwell:you can just use a very low value utxo as a semaphore.
09:05:54gmaxwell:someone feel free to link that crazy raving/ranting forum post I made about brainwallets here: https://bitcointalk.org/index.php?topic=495504.0
09:16:18Luke-Jr:gmaxwell: is it correct to say key stretching does nothing to increase entropy? it seems obvious to me that this is true, but maybe I am missing something
09:18:51phantomcircuit:Luke-Jr, that's correct, if anything it reduces it
09:19:00phantomcircuit:(although not by very much...)
09:25:47gmaxwell:what phantomcircuit said. (though the reduction is probably not at all meaningful unless your starting entropy is very close to the output size)
09:26:43gmaxwell:It can slow down attacks and it's a good practice... but really because of precomputation gains, I don't think I'd ever recommend someone use an unsalted publically attackable password based cryptosystem. It's just too unsafe to put in the hands of users.
09:27:54gmaxwell:e.g. the attacker gets a speedup linear in the number of users. So with a million users, even if they can only compute 1000 passwords per second, they're still making a billion effective attempts per second.
09:28:52gmaxwell:plus then there is the whole issue of memory being surprisingly unreliable... and users being unable to resist making up their own even if you give them a secure generation tool.
09:31:58phantomcircuit:gmaxwell, but but you mean BOBBYTABLES12# isn't secure???
10:28:17hno:gmaxwell, or insisting on setting that tool on bad settings they think is more secure
10:29:21gmaxwell:yea, "the defaults have it use only 12 engish words with no puncuation! I set it to use 8 totally random characters for uber security!"
10:29:54gmaxwell:"hey, why did my coins move in a second transaction the moment I added them to my wallet? why is my balance 0?!?"
10:30:32hno:"and where did I write down my password??"
10:31:55gmaxwell:one thing I worry about is that we can't reliably estimate the level of loss from pasword forgetting because people do not report them (because they are 'at fault')
15:58:38ghtdak:ghtdak has left #bitcoin-wizards
17:04:10maaku:maaku is now known as Guest54951
17:41:02azariah4:maaku_: it's very close to c: https://www.wolframalpha.com/input/?i=speed+of+light+in+air
17:43:58azariah4:HM: about ensuring something is decryptable at a certain point in the future: it could use a blockchain for distributed time consensus perhaps? maybe even use the timestamp bytes in the bitcoin blocks?
17:44:28azariah4:what kind of validation is done by nodes on the timestamp in a block btw?
17:44:36maaku_:azariah4: how does that relate to decryption?
17:44:49maaku_:azariah4: +/- 2hrs, approximately
17:45:32Persopolis:maaku: I thought it was +2hrs but -far less
17:47:30sipa:azariah4: this channel is nit about basic bitcoin questions
17:48:15maaku_:azariah4: diffferences in speed of light give rise to refraction, refraction leads to image distortion
17:48:54maaku_:the maximum resolution of unassisted imagry at oblique angles should give you a bound on atmosopheric distortions
17:51:42azariah4:maaku_: not sure how it could be connected, perhaps by splitting the key, and having say a ethereum-like contract which given parts of the key would perform a decryption only if the timestamp in its blockchain is after a time lock
17:52:25maaku_:azariah4: but everything input into an etherium contract is public
17:55:54azariah4:maaku_: yepp, maybe crypto code obfuscation could be used to hide one part of the key in the data of the contract?
17:56:39maaku_:if the contract has the capability to decrypt, then anyone observing the chain has the capability to decrypt
17:56:46maaku_:you can't magically push it off into the future
17:57:33maaku_:you can prevent consensus about something happening until some point in the future, simply by a "if time < X: fail" check, but that doesn't stop people from pretending time is something else and seeing what would happen
17:58:40maaku_:when you're asking for something to be timelock encrypted, you're saying you don't want anyone to have the capability to decrypt it until some time in the future
17:58:48maaku_:which means the keys must be secret/unknown until then
17:59:04maaku_:which means the *private keys* must be secret/unknown until then
17:59:17maaku_:but the public keys necessarily known because that's what you are encrypting against
17:59:49maaku_:doing that in a decentralized way is not easy
17:59:49azariah4:maaku_: right, good point, someone could just manually run the contract script with a fake time
18:02:18nsh:see the /alt_ideas link in the topic of one proposed scheme. not sure if anyone else has come up with something plausible
18:02:28nsh:(for timelock encryption)
18:04:15andytoshi:nsh: the timelock scheme uses a POW dedicated to cracking keys. i'm pretty sure (but haven't proven) that with a random-oracle POW it is impossible to get timelock encryption
18:04:47nsh:can you give a sketch?
18:05:02nsh:(or intuition)
18:05:29andytoshi:sure, one sec
18:06:13Luke-Jr:SCIP makes timelock encryption possible with bitcoin I think
18:06:36andytoshi:to do public-key encryption all parties need some information about the private key d. eg for ECC the encryptor needs to know what dG is. (mathematically speaking this tells you exactly what d is, but computationally it tells you pretty-much nothing)
18:07:07andytoshi:so to encrypt you need some piece of information about the private key. here we want the private key to be derived from some future hash, or the preimage of some future hash
18:07:28andytoshi:but we have no information about that hash by the random oracle assumption, except what is defined in the protocol (eg it has to be in some small range)
18:07:43andytoshi:but that information is public anyway, there is no assymetry here
18:08:41andytoshi:so my claim is, with a random-oracle hash the information asymmetry between today's world and the future world is complete, and therefore you do not have enough info today to encrypt stuff against future knowledge
18:10:12nsh:but with a consensus system with the right transactional constraints you can put an upper-bound on the diffusion of private keys
18:10:20nsh:and private keys can be secret-shares
18:10:53andytoshi:no, the people with the shares don't have to obey the consensus, they can collude on their own
18:11:20nsh:mm, right.
18:11:43andytoshi:now, i think you might be able to do this in the CRS model, i'll have to think about it
18:11:51nsh:* nsh nods
18:12:09andytoshi:but imo that's more a blow to the CRS model than a claim that this idea makes sense :P
18:12:45azariah4:interesting, how does this relate (or not relate) to this crypto primitive? ftp://ftp.deas.harvard.edu/techreports/tr-22-06.pdf
18:13:35maaku_:andytoshi: well gmaxwell's scheme uses the HD trapdoor to derive future public keys (and the proof of work is derivation of private keys)
18:15:05andytoshi:here's a way to do it with SHA256 in CRS: the reference string is an obfuscated program which demands a valid blockchain with some minimum difficulty. if you give it one, it decrypts with some secret key (known only to the program and its obfuscator), otherwise it will only encrypt
18:17:58andytoshi:but i really do think this is impossible irl because of what i said before (total information asymmetry) so this might be a kernel of a proof that you can't obviate all CRS assumptions in the random oracle model (which is what i was hoping to do with public-key fhe)
18:46:02just[dead]:just[dead] is now known as justanotheruser
19:35:15GabNet:An interesting, dangerous and possibly profitable site... what do you think about it? h ttps://leancy.com/~GabNet
19:35:16GabNet:GabNet has left #bitcoin-wizards
19:40:11azariah4:so in the Time-Lapse Cryptography paper they assume:
19:40:26azariah4:"a universally accessible and tamper-resistant clock, such as provided by the US NIST, that determines times for actions taken by the Service"
19:41:40azariah4:so there some form of distributed time blockchain would be needed to plugin to avoid centralization
19:43:04azariah4:also, it seems their approach relies on nodes performing computations secretly, and also stores its own data in a secret way
19:49:21Luke-Jr:atomic clocks are not centralisation
19:49:29Luke-Jr:and the blockchain itself depends on a reliable timesource
19:50:41nsh:perhaps more accurately: consistent timekeeping
19:50:43azariah4:a single atomic clock is a central point, which could be a adversary
19:51:11nsh:(everyone running bitcoin could have clocks that bear no relation to 'official' time without it being a problem as long as they were sufficiently consistent)
19:51:26Luke-Jr:azariah4: nobody suggested a single atomic clock AFAIK
19:51:27nsh:(it's just much more likely the consistency results from using reliable sources)
19:51:37Luke-Jr:azariah4: obviously the ideal is every node to have their own atomic clock
19:52:58DBordello:Atomic clocks can only provide relative time, not absolute. So, not sure how that'd help
19:54:20azariah4:Luke-Jr: ah sorry, forgot to mention: the authors of this paper actually explicit define that each node in their protocol does not rely on a internal clock, but on a universally accessible clock
19:56:10nsh:magic is hard...
19:56:50Luke-Jr:is it?
19:58:07azariah4:still, they way they propose distributed key generation and verifiable secret sharing of the splitted private key is interesting
19:59:09azariah4:combined with a blockchain enabling decentralized time consensus and some magic, it should work to extend their approach
19:59:24gmaxwell:azariah4: you can search the logs here for my MPC suggestion from time ago but it doesn't really work
19:59:25azariah4:just have to figure out what the magic is :|
19:59:53gmaxwell:azariah4: e.g. you can use the block chain to decide who is a member of a group of key holders, and MPC to move a key set known to no single member from one group to another over time.
20:00:01gmaxwell:which sounds like what you're talking about.
20:00:26gmaxwell:but the problem is that once the initial N members are out of the current group they can just collaborate to recover the keys outside of the mpc system
20:00:37gmaxwell:and wouldn't really have an incentive not to.
20:02:20gmaxwell:So far the timelock pow is the best timelocky thing I've seen/come up with, but its still kinda lame.
20:06:15azariah4:gmaxwell: yepp, if not using timelock pow (the authors of Time-Lapse Cryptography actually briefly discussed this as "time-lock puzzles") the issue seems to be tradeoffs around handling the private key parts
20:06:26azariah4:thanks, will search the logs for that
20:07:01HM:gah CryptoPP documentation sucks
20:07:29gmaxwell:azariah4: the distinction with time-lock pow is that you could dual use a timelock encryption tick with a blockchain cryptocurrency pow.
20:44:06petertodd:Luke-Jr: it's notable that the precision of time required for bitcoin to function is more than low enough that you can set your computer's clock via manual observations of the sun. thus while bitcoin depends on a centralized timesource, it is a level of centralization that I think we can deem acceptable to all
20:46:23jcorgan:why do you discriminate against planets with more than one sun?
20:46:59sipa:you just need a consensus algorithm to decide on which sun to use
20:54:44petertodd:sipa: we have that, proof-of-position, based on the speed of light
20:55:21petertodd:sipa: see, I can incluence the bitcoin blockchian in a provable way, and I can see that my influence is recorded in less time it takes than to get to the closest star other than the sun
20:55:39petertodd:(wormholes and FTL comms are a potential problem to this protocol)
20:56:41HM:If you have 2 suns can you grow twice the number of hash trees?
20:56:59HM:You have to think about scaleability
20:57:35petertodd:HM: risk creating a blackhole following inward spiral and colission
20:58:20azariah4:petertodd: the wormhole would not affect the speed of light though, just the geometry of the space, which can be included when calculating the proof-of-position
20:58:38azariah4:assuming the geometry of the wormhole is stable long-term, enough for all parties to agree on the geometry
21:00:29michagogo|cloud:* michagogo|cloud finds it incredibly amusing to see how discussions in here turn into talking about choosing which sun to use, or proof-of-pizza, or...
21:01:12petertodd:hmm... this might make for a good april 1st BIP - "Timekeeping and Bitcoin" - particularly if I can get some nice line-art drawings of how to take the noon sun measurements... (how do you determine position? can we just assume the participants knows where they are?)
21:02:14petertodd:either that, or write a BIP for miners to vote to allow a particular transaction into the blockchain without checkings the txin scriptSigs... heh, actually I think that'd be a *very* topical BIP to write...
21:02:42petertodd:especially with a demo of how that BIP could be made SPV-compatible...
21:10:06wallet42:i dont think not checking the signatures is very safe
21:10:27sipa:< petertodd> hmm... this might make for a good april 1st BIP
21:11:02sipa:petertodd: how about allowing miners to vote for their own subsidy?
21:11:11sipa:petertodd: at least that'd be obviously bad
21:11:29petertodd:wallet42: I think you misunderstand, it's a proposal to allow miners to vote to do whatever the fuck they want, point being SPV clients won't even know
21:11:41wallet42:BIP april 1st should be creating lost gox coins out of thin air
21:11:46sipa:(you never now someone might actually implement your april 1st BIP, and some miners might adopt it)
21:11:59petertodd:sipa: it *is* that too: they can create invalid txs making coins out of thin air that way
21:12:11sipa:petertodd: no need to convince me :)
21:12:39sipa:petertodd: i just fear some people may take it seriously
21:12:56petertodd:sipa: hmm.. actually, that's a good point, I'd want miners to be able to vote to steal money too, so no, that's not *quite* the same as vote to change the subsidy...
21:14:09petertodd:anyway, the best april fools jokes are the ones that people take seriously, and this one raises important questions about SPV
21:15:10wallet42:i think i should reread https://code.google.com/p/bitcoinj/wiki/SecurityModel
21:16:04petertodd:wallet42: the tl;dr: is "bitcoinj outsources trust to miners"
21:16:23petertodd:wallet42: equally "with bitcoinj, miners can fuck you over"
21:16:37wallet42:so you trust all the miners dont conspire
21:16:58wallet42:to create and feed you invalid blocks
21:17:13petertodd:wallet42: worse than that actualy, they might get hacked, or even only a % of hashing power gets hacked
21:18:40michagogo|cloud:Hm, maybe an extension to HTCPCP for bitcoin activation and payment?
21:19:21petertodd:wallet42: a really crazy example is how currently with hashing software some big pools could get hacked to redirect a portion of the hashing power to create a long-fork with >50% hashing power, then reorg dozens of blocks at a time. it'd be easy to not notice that blocks are being particularly slow, and most hashing software doesn't do any checks
21:19:50petertodd:wallet42: (mastercoin was asking me for what's the biggest reorg you might see, my answere: who the fuck knows?)
21:22:11wallet42:afaik the longest reorg was the chainfork last year. about 25 blocks or so
21:22:40petertodd:the overflow chainfork was longer I thought, >50 blocks?
21:22:52gmaxwell:IIRC it was.
21:22:55wallet42:before my time :/
21:23:06wallet42:anyone knows the height/ time?
21:23:30gmaxwell:FWIW, luke's miner software detect the miner being directed to fork its own work, and will fail the pool. But only luke's software does this and I expect it's not the most popular software.
21:23:42wallet42:another question: since all blocks (connecting to the latest checkpoint) are always accepted by nodes, how many blocks have ever been mined?
21:24:29petertodd:wallet42: orphan rate is almost certainely in the single digits, so close to bestblockcount
21:24:29michagogo|cloud:wallet42: probably not many more than ,,blocks
21:24:53michagogo|cloud:Right, forgot that for some reason inline commands don't work here
21:24:59gmaxwell:(that safty functionality in bfgminer might also be under-tested, I'm not aware of luke having a testharness to test it— though I know it succesfully detected moron pools forking themselves until it was weakened somewhat)
21:25:02phantomcircuit:gmaxwell, i wrote that into the ch pool at one point
21:25:08phantomcircuit:but it was buggy so i removed it
21:25:28michagogo|cloud:wallet42: probably at least a couple hundred more than 288644
21:25:28phantomcircuit:replaced it with a fast network connection between all the bitcoin daemons
21:25:43michagogo|cloud:But not more by a huge number
21:29:18wallet42:but there are a lot of obvious fakes
21:29:32wallet42:2013 trying to mine on block height 5
21:34:12wallet42:but rate is less than 1% atm: 261907-288644 = 200/26737 = 0.00748
22:28:17justanotheruser:justanotheruser is now known as just[dead]
22:50:27Luke-Jr:flight got cancelled -_-
23:00:59maaku_:Luke-Jr: to california?
23:04:03gmaxwell:Luke-Jr: usually airline contracts require that they get you to your destination within 2 hours of your scheduled time by any available means, even if that involves putting you onto another airline
23:04:13gmaxwell:But you have to ask them to do this— they usually won't offer.
23:04:41gmaxwell:E.g. tell them "arriving is really going to screw me up, is there a flight on another airline you can put me on?"