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