| 00:00:00 | amiller: | not every user has to be mining, even with pos |
| 00:00:11 | amiller: | you don't have to make every signature a one time signautre |
| 00:00:16 | amiller: | only the ones eligible for use in pos |
| 00:01:01 | amiller: | i gues you're aying to use it for other things not pos |
| 00:01:03 | amiller: | i see |
| 00:01:03 | adam3us: | 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:37 | amiller: | adam3us, yeah, something like that. |
| 00:01:52 | adam3us: | amiller: the sender is limited to aborting the transaction by paying to miner (rather than taking the funds himself maybe) |
| 00:03:34 | adam3us: | 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:11 | amiller: | no you have to lose real coins not just your vote, that's the "somethings at stake" part |
| 00:06:12 | adam3us: | 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:30 | adam3us: | amiller: for actual payments |
| 00:06:31 | amiller: | if you're using your coins to mine, then write your vote to a log first |
| 00:06:48 | amiller: | 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:20 | amiller: | 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:30 | sipa: | amiller: what "log" ? |
| 00:12:04 | sipa: | there is no log that you could meaningfully append that that remains consistent in the presence of blockchain reorgs |
| 00:12:35 | amiller: | sipa, this is for a really specific use case, burning coins for pos mining |
| 00:12:38 | sipa: | 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:52 | amiller: | it only needs to be locally consistent |
| 00:12:54 | sipa: | is, which |
| 00:13:14 | sipa: | how so? |
| 00:15:00 | tt_away: | i'm not sure that pure PoS can work, although it sort of does with nxt. |
| 00:15:15 | sipa: | nxt is a joke, sorry |
| 00:15:19 | tt_away: | nxt is so poorly documented that not a lot of people understand it though. |
| 00:15:32 | tt_away: | the block generation mechanism anyway. |
| 00:16:03 | sipa: | i'm pretty sure that pure nxt cannot work |
| 00:16:13 | tt_away: | sipa: well, you can tell that from the looking at the one file source code... |
| 00:16:17 | tt_away: | pure nxt? |
| 00:16:34 | sipa: | unless you get all miners to agree to never to try to extend forks |
| 00:16:36 | amiller: | 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:40 | sipa: | without any good reasom |
| 00:16:55 | tt_away: | sipa: there's no possibility of that because the list of miners is ordered and predetermined. |
| 00:17:15 | amiller: | 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:24 | tt_away: | i'm implementing another type of pos system soon too, but that's dependent on pow to prevent forks. |
| 00:18:07 | sipa: | amiller: where do you write the vote? |
| 00:18:13 | amiller: | to a file |
| 00:18:22 | amiller: | to a dozen files |
| 00:19:01 | amiller: | 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:19 | sipa: | so, if i try ton reuse the same coin to vote on a fork |
| 00:19:34 | sipa: | any peer who has seen my old vote will reject the new block if it wins |
| 00:19:43 | tt_away: | yeah. |
| 00:19:46 | sipa: | but those who have not seem the old vote will accept it |
| 00:19:53 | amiller: | 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:55 | sipa: | sounds like a great way to cause more forks |
| 00:20:13 | tt_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:27 | gmaxwell: | 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:58 | amiller: | 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:53 | sipa: | i'm saying that the criteria for acceptance of a block must be consistent across the network |
| 00:23:12 | sipa: | which means if cannot rely on state outside of the chain being verified |
| 00:23:26 | sipa: | unless you have something to force consistency |
| 00:23:39 | sipa: | which is the whole point we're trying to solve |
| 00:24:51 | andytoshi: | 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:24 | nsh: | (sounds like an unrelated problem) |
| 00:25:36 | amiller: | sipa, ok so is that a clear way to argue that nothing like pos can work? |
| 00:25:48 | amiller: | it's not possible to have anything at stake if you have choice about which future fork you're voting for |
| 00:25:52 | andytoshi: | 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:14 | amiller: | 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:22 | andytoshi: | but these guys are talking about PoS anyway, i'll shut up and maybe i'll learn something |
| 00:26:39 | nsh: | andytoshi, i meant rather that it's mostly-orthogonal to the problem of network consistency/convergence |
| 00:26:42 | tt_away: | well, a nxt style follow the satoshi scheme sort of works, unless you get a string of malevolent miners. |
| 00:26:46 | nsh: | but there will be interrelations, undoubtedly |
| 00:31:32 | sipa: | amiller: i'm not sure it's enough of an argument to construct a proof |
| 00:32:08 | amiller: | 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:30 | sipa: | 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:06 | tt_away: | yeah, there are many proposals for pos systems. |
| 00:33:09 | sipa: | 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:29 | tt_away: | if sipa's description is correct, that's the scheme i'm using. |
| 00:33:45 | sipa: | and i'm not sure whether shunning adds anything at all, in theory |
| 00:34:13 | tt_away: | it can at least force miners to include tx on the network that were broadcast to all of them. |
| 00:34:37 | tt_away: | and destroy the pow reward if they don't. |
| 00:35:32 | tt_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:52 | sipa: | that still builds consensus |
| 00:36:01 | tt_away: | this is true. |
| 00:36:02 | sipa: | it may not be one that non-miners want |
| 00:36:13 | sipa: | but that's a different (and much harder) issue |
| 00:36:17 | Luke-Jr: | sipa: what consensus does it build? :p |
| 00:36:19 | tt_away: | i mostly want to play around with it and see how well it works. |
| 00:36:42 | sipa: | Luke-Jr: a globally eventually-consistent transaction history |
| 00:38:08 | tt_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:43 | Sangheil-: | Sangheil- is now known as Sangheili |
| 04:29:28 | hno: | 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:13 | gmaxwell: | they are, but they're non-standard. I wish they were invalid. |
| 04:42:53 | Luke-Jr: | hno: p2pool does it |
| 04:56:58 | nOgAnOo: | gmaxwell, how's your relationship with Jesus Christ? |
| 04:57:10 | nOgAnOo: | You can't take your bitcoins to hell with you you know.. |
| 04:59:40 | Luke-Jr: | nOgAnOo: that's totally off-topic here.. |
| 05:07:26 | fanquake: | fanquake has left #bitcoin-wizards |
| 05:10:51 | nOgAnOo: | nOgAnOo is now known as n0g |
| 05:11:02 | n0g: | n0g is now known as nOgAnOo |
| 06:49:10 | maaku_: | gmaxwell: why? isn't it useful to have a txout as a semaphore object? |
| 06:52:57 | gmaxwell: | 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:48 | copumpkin: | Luke-Jr: ^ :) |
| 06:56:12 | Luke-Jr: | ? |
| 06:56:26 | copumpkin: | ssj4mo is in here too :P |
| 06:56:32 | copumpkin: | oh wait, he survived this time |
| 06:56:33 | copumpkin: | nevermind |
| 06:57:23 | maaku_: | true |
| 06:58:41 | gmaxwell: | you can just use a very low value utxo as a semaphore. |
| 09:05:54 | gmaxwell: | 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:18 | Luke-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:51 | phantomcircuit: | Luke-Jr, that's correct, if anything it reduces it |
| 09:19:00 | phantomcircuit: | (although not by very much...) |
| 09:25:47 | gmaxwell: | 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:43 | gmaxwell: | 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:54 | gmaxwell: | 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:52 | gmaxwell: | 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:58 | phantomcircuit: | gmaxwell, but but you mean BOBBYTABLES12# isn't secure??? |
| 10:28:17 | hno: | gmaxwell, or insisting on setting that tool on bad settings they think is more secure |
| 10:29:21 | gmaxwell: | 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:54 | gmaxwell: | "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:32 | hno: | "and where did I write down my password??" |
| 10:31:55 | gmaxwell: | 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:38 | ghtdak: | ghtdak has left #bitcoin-wizards |
| 17:04:10 | maaku: | maaku is now known as Guest54951 |
| 17:41:02 | azariah4: | maaku_: it's very close to c: https://www.wolframalpha.com/input/?i=speed+of+light+in+air |
| 17:43:58 | azariah4: | 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:28 | azariah4: | what kind of validation is done by nodes on the timestamp in a block btw? |
| 17:44:36 | maaku_: | azariah4: how does that relate to decryption? |
| 17:44:49 | maaku_: | azariah4: +/- 2hrs, approximately |
| 17:45:32 | Persopolis: | maaku: I thought it was +2hrs but -far less |
| 17:47:30 | sipa: | azariah4: this channel is nit about basic bitcoin questions |
| 17:48:15 | maaku_: | azariah4: diffferences in speed of light give rise to refraction, refraction leads to image distortion |
| 17:48:54 | maaku_: | the maximum resolution of unassisted imagry at oblique angles should give you a bound on atmosopheric distortions |
| 17:51:42 | azariah4: | 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:25 | maaku_: | azariah4: but everything input into an etherium contract is public |
| 17:55:54 | azariah4: | maaku_: yepp, maybe crypto code obfuscation could be used to hide one part of the key in the data of the contract? |
| 17:56:39 | maaku_: | if the contract has the capability to decrypt, then anyone observing the chain has the capability to decrypt |
| 17:56:46 | maaku_: | you can't magically push it off into the future |
| 17:57:33 | maaku_: | 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:40 | maaku_: | 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:48 | maaku_: | which means the keys must be secret/unknown until then |
| 17:59:04 | maaku_: | which means the *private keys* must be secret/unknown until then |
| 17:59:17 | maaku_: | but the public keys necessarily known because that's what you are encrypting against |
| 17:59:49 | maaku_: | doing that in a decentralized way is not easy |
| 17:59:49 | azariah4: | maaku_: right, good point, someone could just manually run the contract script with a fake time |
| 18:02:18 | nsh: | 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:28 | nsh: | (for timelock encryption) |
| 18:04:15 | andytoshi: | 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:47 | nsh: | can you give a sketch? |
| 18:05:02 | nsh: | (or intuition) |
| 18:05:29 | andytoshi: | sure, one sec |
| 18:06:03 | Luke-Jr: | hm |
| 18:06:13 | Luke-Jr: | SCIP makes timelock encryption possible with bitcoin I think |
| 18:06:31 | Luke-Jr: | maybe |
| 18:06:36 | andytoshi: | 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:07 | andytoshi: | 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:28 | andytoshi: | 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:43 | andytoshi: | but that information is public anyway, there is no assymetry here |
| 18:08:20 | nsh: | mm |
| 18:08:41 | andytoshi: | 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:12 | nsh: | but with a consensus system with the right transactional constraints you can put an upper-bound on the diffusion of private keys |
| 18:10:20 | nsh: | and private keys can be secret-shares |
| 18:10:53 | andytoshi: | no, the people with the shares don't have to obey the consensus, they can collude on their own |
| 18:11:20 | nsh: | mm, right. |
| 18:11:43 | andytoshi: | now, i think you might be able to do this in the CRS model, i'll have to think about it |
| 18:11:51 | nsh: | * nsh nods |
| 18:12:09 | andytoshi: | but imo that's more a blow to the CRS model than a claim that this idea makes sense :P |
| 18:12:35 | nsh: | heh |
| 18:12:45 | azariah4: | interesting, how does this relate (or not relate) to this crypto primitive? ftp://ftp.deas.harvard.edu/techreports/tr-22-06.pdf |
| 18:13:35 | maaku_: | 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:05 | andytoshi: | 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:58 | andytoshi: | 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:02 | just[dead]: | just[dead] is now known as justanotheruser |
| 19:35:15 | GabNet: | An interesting, dangerous and possibly profitable site... what do you think about it? h ttps://leancy.com/~GabNet |
| 19:35:16 | GabNet: | GabNet has left #bitcoin-wizards |
| 19:40:11 | azariah4: | so in the Time-Lapse Cryptography paper they assume: |
| 19:40:26 | azariah4: | "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:40 | azariah4: | so there some form of distributed time blockchain would be needed to plugin to avoid centralization |
| 19:43:04 | azariah4: | also, it seems their approach relies on nodes performing computations secretly, and also stores its own data in a secret way |
| 19:49:08 | Luke-Jr: | no |
| 19:49:21 | Luke-Jr: | atomic clocks are not centralisation |
| 19:49:29 | Luke-Jr: | and the blockchain itself depends on a reliable timesource |
| 19:50:41 | nsh: | perhaps more accurately: consistent timekeeping |
| 19:50:43 | azariah4: | a single atomic clock is a central point, which could be a adversary |
| 19:51:11 | nsh: | (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:26 | Luke-Jr: | azariah4: nobody suggested a single atomic clock AFAIK |
| 19:51:27 | nsh: | (it's just much more likely the consistency results from using reliable sources) |
| 19:51:37 | Luke-Jr: | azariah4: obviously the ideal is every node to have their own atomic clock |
| 19:52:58 | DBordello: | Atomic clocks can only provide relative time, not absolute. So, not sure how that'd help |
| 19:54:20 | azariah4: | 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:55:04 | Luke-Jr: | lame |
| 19:56:10 | nsh: | magic is hard... |
| 19:56:50 | Luke-Jr: | is it? |
| 19:58:07 | azariah4: | still, they way they propose distributed key generation and verifiable secret sharing of the splitted private key is interesting |
| 19:59:09 | azariah4: | combined with a blockchain enabling decentralized time consensus and some magic, it should work to extend their approach |
| 19:59:24 | gmaxwell: | azariah4: you can search the logs here for my MPC suggestion from time ago but it doesn't really work |
| 19:59:25 | azariah4: | just have to figure out what the magic is :| |
| 19:59:53 | gmaxwell: | 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:01 | gmaxwell: | which sounds like what you're talking about. |
| 20:00:26 | gmaxwell: | 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:37 | gmaxwell: | and wouldn't really have an incentive not to. |
| 20:02:20 | gmaxwell: | So far the timelock pow is the best timelocky thing I've seen/come up with, but its still kinda lame. |
| 20:06:15 | azariah4: | 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:26 | azariah4: | thanks, will search the logs for that |
| 20:07:01 | HM: | gah CryptoPP documentation sucks |
| 20:07:29 | gmaxwell: | azariah4: the distinction with time-lock pow is that you could dual use a timelock encryption tick with a blockchain cryptocurrency pow. |
| 20:44:06 | petertodd: | 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:23 | jcorgan: | why do you discriminate against planets with more than one sun? |
| 20:46:59 | sipa: | you just need a consensus algorithm to decide on which sun to use |
| 20:54:44 | petertodd: | sipa: we have that, proof-of-position, based on the speed of light |
| 20:55:21 | petertodd: | 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:39 | petertodd: | (wormholes and FTL comms are a potential problem to this protocol) |
| 20:56:41 | HM: | If you have 2 suns can you grow twice the number of hash trees? |
| 20:56:59 | HM: | You have to think about scaleability |
| 20:57:35 | petertodd: | HM: risk creating a blackhole following inward spiral and colission |
| 20:58:20 | azariah4: | 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:38 | azariah4: | assuming the geometry of the wormhole is stable long-term, enough for all parties to agree on the geometry |
| 20:59:12 | petertodd: | lol! |
| 21:00:29 | michagogo|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:12 | petertodd: | 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:14 | petertodd: | 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:42 | petertodd: | especially with a demo of how that BIP could be made SPV-compatible... |
| 21:10:06 | wallet42: | i dont think not checking the signatures is very safe |
| 21:10:14 | sipa: | ... |
| 21:10:27 | sipa: | < petertodd> hmm... this might make for a good april 1st BIP |
| 21:11:02 | sipa: | petertodd: how about allowing miners to vote for their own subsidy? |
| 21:11:11 | sipa: | petertodd: at least that'd be obviously bad |
| 21:11:29 | petertodd: | 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:41 | wallet42: | BIP april 1st should be creating lost gox coins out of thin air |
| 21:11:46 | sipa: | (you never now someone might actually implement your april 1st BIP, and some miners might adopt it) |
| 21:11:59 | petertodd: | sipa: it *is* that too: they can create invalid txs making coins out of thin air that way |
| 21:12:11 | sipa: | petertodd: no need to convince me :) |
| 21:12:39 | sipa: | petertodd: i just fear some people may take it seriously |
| 21:12:56 | petertodd: | 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:09 | petertodd: | anyway, the best april fools jokes are the ones that people take seriously, and this one raises important questions about SPV |
| 21:15:10 | wallet42: | i think i should reread https://code.google.com/p/bitcoinj/wiki/SecurityModel |
| 21:16:04 | petertodd: | wallet42: the tl;dr: is "bitcoinj outsources trust to miners" |
| 21:16:23 | petertodd: | wallet42: equally "with bitcoinj, miners can fuck you over" |
| 21:16:37 | wallet42: | so you trust all the miners dont conspire |
| 21:16:58 | wallet42: | to create and feed you invalid blocks |
| 21:17:13 | petertodd: | wallet42: worse than that actualy, they might get hacked, or even only a % of hashing power gets hacked |
| 21:18:40 | michagogo|cloud: | Hm, maybe an extension to HTCPCP for bitcoin activation and payment? |
| 21:19:21 | petertodd: | 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:50 | petertodd: | wallet42: (mastercoin was asking me for what's the biggest reorg you might see, my answere: who the fuck knows?) |
| 21:22:11 | wallet42: | afaik the longest reorg was the chainfork last year. about 25 blocks or so |
| 21:22:40 | petertodd: | the overflow chainfork was longer I thought, >50 blocks? |
| 21:22:52 | gmaxwell: | IIRC it was. |
| 21:22:55 | wallet42: | before my time :/ |
| 21:23:06 | wallet42: | anyone knows the height/ time? |
| 21:23:30 | gmaxwell: | 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:42 | wallet42: | another question: since all blocks (connecting to the latest checkpoint) are always accepted by nodes, how many blocks have ever been mined? |
| 21:24:29 | petertodd: | wallet42: orphan rate is almost certainely in the single digits, so close to bestblockcount |
| 21:24:29 | michagogo|cloud: | wallet42: probably not many more than ,,blocks |
| 21:24:36 | michagogo|cloud: | Er |
| 21:24:53 | michagogo|cloud: | Right, forgot that for some reason inline commands don't work here |
| 21:24:59 | michagogo|cloud: | ;;blocks |
| 21:24:59 | gmaxwell: | (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:00 | gribble: | 288644 |
| 21:25:02 | phantomcircuit: | gmaxwell, i wrote that into the ch pool at one point |
| 21:25:08 | phantomcircuit: | but it was buggy so i removed it |
| 21:25:28 | michagogo|cloud: | wallet42: probably at least a couple hundred more than 288644 |
| 21:25:28 | phantomcircuit: | replaced it with a fast network connection between all the bitcoin daemons |
| 21:25:43 | michagogo|cloud: | But not more by a huge number |
| 21:27:33 | wallet42: | https://blockchain.info/de/orphaned-blocks?offset=1350 |
| 21:29:18 | wallet42: | but there are a lot of obvious fakes |
| 21:29:32 | wallet42: | 2013 trying to mine on block height 5 |
| 21:34:12 | wallet42: | but rate is less than 1% atm: 261907-288644 = 200/26737 = 0.00748 |
| 22:28:17 | justanotheruser: | justanotheruser is now known as just[dead] |
| 22:50:16 | Luke-Jr: | sigh |
| 22:50:27 | Luke-Jr: | flight got cancelled -_- |
| 23:00:59 | maaku_: | Luke-Jr: to california? |
| 23:04:03 | gmaxwell: | 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:13 | gmaxwell: | But you have to ask them to do this— they usually won't offer. |
| 23:04:41 | gmaxwell: | E.g. tell them "arriving is really going to screw me up, is there a flight on another airline you can put me on?" |