02:02:16gmaxwell:[OT] oh neat: HP Z3805A clocks have forth interperters in them: http://www.febo.com/pipermail/time-nuts/2013-May/076641.html
02:02:54sipa:yes, but do they run linux?
02:19:26c0rw1n:c0rw1n is now known as c0rw|sleep
03:13:16maaku:maaku is now known as Guest84807
03:13:48zzyzx:zzyzx is now known as roidster
03:14:18roidster:roidster is now known as Guest52910
04:19:05gmaxwell:I wonder if we could talk NIST into running a timelock beacon.
04:49:27Guest84807:Guest84807 is now known as maaku
04:52:13maaku:gmaxwell: I would be surprised if you couldn't
04:52:51maaku:and it'd probably be more than sufficient for most apps
04:53:55gmaxwell:ideally you'd convince many parties to do this and use threshold cryptography.
05:11:46maaku:so hard fork changes to the block chain structures is not as easy as I'd hoped
05:12:23maaku:it's mostly a matter of extending the serialization primitives to take a CChainParams and integer block height
05:12:59maaku:but unfortunately sometimes block height is not readily available, so restructuring is needed
05:52:03sipa:maaku: what change in particular?
06:17:23QuantumQrack:QuantumQrack has left #bitcoin-wizards
08:30:42c0rw|sle_:c0rw|sle_ is now known as c0rw1n
09:30:10wallet421:wallet421 is now known as wallet42
10:06:54Luke-Jr:bash: cd: /home/jcorgan: No such file or directory
10:29:05gmaxwell:[ignore] dabeeec36d2319c3156271e76d6d45b0d64db31bd6e3803a5783aae52316ca47
10:32:01Luke-Jr:gmaxwell: O.o?
11:02:37fanquake:fanquake has left #bitcoin-wizards
17:18:20maaku:sipa: pretty much every point where core.h data is serialized or GetHash() is called
17:19:57maaku:I'm putting together a more complete list, I'll have a better idea on Monday of what changes are required
17:53:30sipa:maaku: with the headers-first changes i'm making some things may improve
17:53:46sipa:maaku: as it means you only download transactions after knowing the path from genesis
20:46:44Ademan_:Ademan_ is now known as Ademan
20:47:51Ademan:Has anyone looked at https://bitcointalk.org/index.php?topic=558904.0 yet? I have NFI if it's interesting at all but someone mentioned it on reddit and I haven't gotten around to reading it yet myself.
20:49:40pigeons:pigeons is now known as Guest52399
20:52:27andytosh1:Ademan: lol, it's completely retarded. basically "how about everyone is able to create money just by making transactions; to make this sybil-resistant we restrict the number of transactions (and their number of outputs) so the system is unusable for transferring value"
20:52:57andytosh1:also it makes the consensus code (a) aware of addresses, (b) aware of from addresses
20:55:32k0val:k0val is now known as koval
20:57:28andytosh1:andytosh1 is now known as andytoshi
21:02:07gmaxwell:andytoshi: it's grindable too.
21:03:35andytoshi:oh, that's what i meant by "everyone is able to create money".. the example given is a 12-bit match, i didn't even consider that 'grinding' :P
21:06:35andytoshi:also i'm unclear on what problem this is supposed to solve
21:08:35gmaxwell:they promoted it on reddit as a 'solution' to miners not including transactions. ... though it's silly to propose as that because it looks like it encourages miners to include only their own transactions (in order to maximize their subsidy)
21:12:57Ademan:I need to stop getting excited about proof of work alternatives, they seem to always be broken (although this still requires PoW?)
21:15:00Ademan:also is there a name for the class of algorithms PoW, PoS, PoB etc?
21:18:42gmaxwell:Ademan: you just need to find more interesting things to get excited about.
21:19:05tacotime:Most of the PoW alternatives tend to be broken, those that aren't tend to be hybrid systems heavily biased to PoW.
21:19:51gmaxwell:s/those that aren't/some are just too complex to analyize to say for sure precisely what they are at all, such as/
21:21:39tacotime:Isn't Bitshares using some kind of wacky PoS based around transactions?
21:21:42Ademan:I'd argue that a real replacement for PoW which, without sacrificing PoW's paramount properties, while improving distribution of "mining", addressing the "end-of-the-block-subsidy", and/or improves energy efficiency would be very interesting indeed. Although this might just be cold fusion for crypto-currencies
21:22:20tacotime:Yeah http://the-iland.net/static/downloads/TransactionsAsProofOfStake.pdf
21:23:39tacotime:It's kind of "let's exacerbate the Bitcoins and Red Balloons Problem as severely as we can."
21:25:40Ademan:tacotime: red balloons ?
21:26:03tacotime:Ademan: http://research.microsoft.com/apps/pubs/?id=156072
21:31:56Ademan:tacotime: thanks, I'll give that a read as well
22:07:22koval:koval is now known as koval-afk
23:10:48maaku_:maaku_ is now known as maaku
23:11:37maaku:sipa: yes orphan blocks are the big trouble point
23:12:08maaku:a smaller issue is CCoins - it should have nHeight first, not last, since the height + version values might determine which fields follow
23:21:12sipa:maaku: why does the serialization matter?
23:21:59sipa:maaku: in headers-based syhc, orohan blocks don't exist :)
23:22:18sipa:*sync, orphan
23:23:51phantomcircuit:phantomcircuit is now known as Guest50603
23:25:01maaku:sipa: serialization of CCoins? because you don't know what fields to read until you know the height
23:25:38maaku:imagine we say after height 500,000 version >=3 transactions have an extra field Y per output
23:25:56maaku:then the UTXO for those transactions need to serialize that field Y
23:26:20maaku:but a version==3 transaction at height 499,999 does not
23:26:48sipa:well, as i said, we likely will need to store effective version rather than nVersion
23:27:00maaku:so I need to rewrite the UTXO set to put nHeight first in that serialization, so on read back it gets nHeight, nVersion and then knows which format the tx is
23:27:14maaku:yeah, well either way
23:27:46sipa:there is no reason why your normative serialization needs to follow the same silly overly compressed encoding as i came up with
23:27:59sipa:but i still don't see your problem, regardless of that
23:28:21maaku:this is unrelated to UTXO hash tree commitments
23:28:45maaku:no, this is prep work for freimarkets, and other hard-fork changes to the transaction format
23:29:05sipa:i still don't see why the order matters
23:29:15sipa:unless you plan to change the meaning of existing fields
23:29:20sipa:instead of adding ones
23:30:17maaku:sipa: but if nHeight is VARINT encoded at the end, how do you know what the height is without first reading the transaction data?
23:30:29maaku:but how do you know how to read the transaction data if you don't know what the height is?
23:30:44sipa:ok, so you do plan on changing the semantics of existing fields
23:30:49sipa:ok, sure
23:31:15sipa:if the encoding of txout/amount data becomes dependent in height/version, sure
23:32:27sipa:sorry if i sounded defensive here - there is no reason why the order can't be changed
23:32:33sipa:i just didn't see the problem
23:32:46maaku:yeah no, i understand
23:33:14maaku:that's the premise - what minimal changes can I make to allow the encoding of txout/amount data to depend on (height, version)
23:33:15amiller_:amiller_ is now known as amiller
23:33:31maaku:which I need for freimarkets, but I presume others will find useful too
23:33:52sipa:i do regret not leaving a few predefined script header codes for future p2sh like scriot extensions
23:35:48maaku:well it's not normative yet