--- Log opened Mon May 15 00:00:54 2017
00:02 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Quit: ZNC 1.6.4 - http://znc.in]
00:04 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-wizards
00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
01:32 -!- fletom [~fletom@ec2-34-202-234-47.compute-1.amazonaws.com] has quit [Remote host closed the connection]
01:32 -!- fletom [~fletom@ec2-34-202-234-47.compute-1.amazonaws.com] has joined #bitcoin-wizards
01:37 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
01:48 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has joined #bitcoin-wizards
01:52 -!- Dyaheon- [~Dya@91.156.192.24] has quit [Ping timeout: 240 seconds]
01:54 -!- Dyaheon [~Dya@91.156.192.24] has joined #bitcoin-wizards
02:09 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-wizards
02:19 -!- aib [~marvin@176.240.100.165] has quit [Ping timeout: 240 seconds]
02:38 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection]
02:39 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-wizards
03:12 -!- molz_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
03:13 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-wizards
03:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lmmpakwwloeisxqn] has quit [Quit: Connection closed for inactivity]
03:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
03:27 -!- JackH [~laptop@79-73-189-229.dynamic.dsl.as9105.com] has quit [Ping timeout: 260 seconds]
03:29 -!- Antitrust [~antitrust@62.217.43.147] has joined #bitcoin-wizards
03:30 < stevenroose> I'm amazed actually about the amount of blocks mined by unknown miners/pools. Sadly, 99% of those blocks seem to signal nothing.
03:32 < Raccoon> CPU/GPU mining capabilities should have never been removed from clients, even if the odds are astronomically slim.
03:33 < stevenroose> Raccoon, well, I think it kinda makes sense to have separate mining software than client software
03:33 < stevenroose> The majority of the users wont be mining anyway
03:34 < Raccoon> You can't impress upon users the idea of decentralization if it's not even made available -- banned -- due to impracticality.
03:34 < Raccoon> That tells users that the experiment is failed.
03:34 < stevenroose> I do agree that there should be more user-friendly mining software
03:34 < stevenroose> like you owuld have guiminer in the past
03:36 < Raccoon> Or, you know, impliment a common core mining software that hardware miners adhere to, API.
03:36 < Raccoon> Then people can buy compatable USB plug-n-go hardware miners that the bitcoin software autodetects
03:36 < Raccoon> but
03:37 < Raccoon> in the absense of any decentralized and standardized mining software, all we are left is with capitalism driven pool miners
03:37 < Raccoon> people who make money by making mining possible
03:37 < Raccoon> closed source
03:39 < Raccoon> If you want to get involved with bitcoin mining, you have to go through either Chase or Bank of America
03:40 < Raccoon> or find some old source code and roll your own
03:42 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has quit [Ping timeout: 260 seconds]
03:52 -!- Antitrust [~antitrust@62.217.43.147] has quit [Remote host closed the connection]
03:55 < Eliel_> Raccoon: that sort of API exists, actually. However, my impression is that not many miners use it.
03:56 < stevenroose> Well, it used to work like that
03:56 < stevenroose> BFGMiner or the other one that it was a fork of, they used to detect almost all hardware miners
03:56 < stevenroose> I don't know now, I'm speaking years ago
03:57 < Raccoon> If it were built into the in-your-face client wallet(s), people might give it more credence.
03:57 < stevenroose> I do agree that mining software and hardware should be way more accessible, but I don't agree it should be shipped by default with all clients
03:57 < stevenroose> I's like shipping a pickaxe with a golden ring :D
03:58 < Raccoon> I don't see why not.  The ethos of Bitcoin is that all users are also gate keepers.
03:58 < Raccoon> Or at least are encouraged to become one.
03:58 < Raccoon> And yes, your analogy fits.
03:58 < Raccoon> As it should.
03:59 < Raccoon> Not only are you opening up a checking account, but you own the whole fucking bank.
03:59 < Raccoon> Here's your banker's hat and vault and ledger and everything else you need
04:01 < Raccoon> "Some hardware upgrades may be required.  Click here for some sites selling mining hardware."
04:01 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 246 seconds]
04:01 < Raccoon> Imagine the non-pool participation if it were that easy
04:02 < Raccoon> Alas, Chase Inc. may actually buy up one of the mining pools
04:03 < Raccoon> And that's that
04:10 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
04:13 -!- harrymm [~wayne@104.237.91.250] has quit [Read error: Connection reset by peer]
04:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
04:15 -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has joined #bitcoin-wizards
04:25 < adlai> mining is not banking, though. running a node is banking. mining is being a rate limiter on the interbank messaging.
04:26 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has joined #bitcoin-wizards
04:26 < adlai> you can be a bank that doesn't operate its own interbank messaging relay, but you then need to rely on at least one such relay
04:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
04:51 -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has quit [Ping timeout: 268 seconds]
05:10 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards
05:11 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
05:14 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
05:16 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
05:29 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:79c9:619b:e829:1fa6] has quit [Quit: .]
05:34 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5dfe:6aa6:f987:2fdf] has joined #bitcoin-wizards
05:36 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 272 seconds]
05:37 -!- JackH [~laptop@79-73-189-229.dynamic.dsl.as9105.com] has joined #bitcoin-wizards
05:37 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has quit [Ping timeout: 255 seconds]
05:42 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
05:43 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
05:43 < bsm1175321> I want open source mining hardware...
05:47 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Ping timeout: 260 seconds]
05:51 -!- MaxSan [~one@109.202.103.170] has joined #bitcoin-wizards
05:51 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
06:02 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
06:02 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
06:03 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
06:03 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
06:04 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
06:09 < stevenroose> bsm1175321, I think a crowdfunder for one would work great :p
06:12 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
06:12 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
06:16 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
06:19 -!- MaxSan [~one@109.202.103.170] has quit [Ping timeout: 246 seconds]
06:20 -!- kmels [~kmels@105.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards
06:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
06:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
06:49 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
07:02 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:03 < bsm117532> stevenroose: would have to find some real VHDL and fab experts, to figure out how to make such a thing worthwhile.
07:04 < bsm117532> Every time I bring this up, the consensus seems to be that fabs are so finicky and custom that all the development time is in tweaking your design for a specific fab, and the value of the open-source VHDL would be near-zero.
07:05 < stevenroose> I guess if one of the already existing mining firms would do a crowdfunder for an open source model, they would make profits. the only problem is that I think currently mining is still a bit too profitable for them to do that over just mining themselves
07:06 < stevenroose> I think when the bounty decreases, mining will automatically become less profitable and more decentralized since mining hardware manufacturers will make more profits selling their hardware than to mine themselves
07:06 -!- c0rw1n [~c0rw1n@132.90-242-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds]
07:07 < stevenroose> but then again, once mining manufacturers are more incentivized to sell, I doubt if there is a lot of real value in open source hardware
07:09 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
07:10 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
07:13 -!- superkuh [~superkuh@unaffiliated/superkuh] has joined #bitcoin-wizards
07:19 < Eliel_> stevenroose: I don't think mining hardware maker profits are really dependent on the bounty. They can set the price to whatever level they think they'd get if they mined themselves.
07:19 < Eliel_> of course, if competitors sell cheaper, then they'll naturally end up mining themselves.
07:24 < Taek> Not too hard to track down I think. I was recently quoted $11M in fixed costs to produce a 14nm miner. The recent Bitmain I think is only 16nm. So if you can crowdfund $100M or so, you can probably print a pretty good ASIC
07:25 < Taek> Though, I'm not actually sure if that firm would be comfortable open sourcing the resulting designs
07:28 < Taek> considering that the annual block reward is in the ballpark of $1B, I think there's a great business case to go for it
07:28 < Taek> you'd need to see how much hashrate you could get for $100M though
07:32 -!- c0rw1n [~c0rw1n@132.90-242-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards
07:37 -!- GreenF [~inteligen@201.20.137.1] has joined #bitcoin-wizards
07:38 -!- Guest98 [~textual@88.98.81.116] has joined #bitcoin-wizards
07:39 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:39 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
07:41 -!- Conficker [~inteligen@201.20.137.1] has quit [Ping timeout: 240 seconds]
07:46 -!- MaxSan [~one@213.152.162.10] has joined #bitcoin-wizards
07:46 -!- thrmo [~thrmo@unaffiliated/thrmo] has joined #bitcoin-wizards
07:51 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:57 -!- Giszmo [~leo@201.215.13.240] has joined #bitcoin-wizards
07:57 < bsm117532> A crowdfunded entity with a contractual commitment to NOT mine, only develop and sell mining hardware...and open source all designs...
07:58 -!- tromp_ [~tromp@rtc35-090.rentec.com] has joined #bitcoin-wizards
07:58 < bsm117532> How could crowd-funders ensure non-discrimination in creation of mining hardware?
07:58 < bsm117532> There's an awful strong incentive to collude with miners and mining pools...
08:00 < kanzure> someone was arguing to me the other day that we should find a matrix math heavy pow function, and then abuse the machine learning asic industry or something (i think the assumption was that matrix math asic limits have been met by nvidia by now or something?)
08:00 < othe> well, thats an issue for the legal system then
08:02 < bsm117532> othe: One would want a carefully written charter/contract for an open source mining company, so that the legal system was capable of enforcing terms in a way which help said entity decentralize mining...and prevent it from doing the opposite.
08:02 < bsm117532> kanzure: new nvidia chips contain dedicated "tensor" engines, which could be abused for mining.
08:03 < bsm117532> https://developer.nvidia.com/tensorrt
08:03 < kanzure> yea but i think purpose-specific asic manufacturing would probably outperform that.. just a hunch.
08:04 -!- talmai [~T@74.118.24.210] has joined #bitcoin-wizards
08:05 < bsm117532> Well sure.  I'm sure one could optimize a compute-heavy mining algorithm to make any given GPU essentially ideal.  If I imagine memory consumption, computations per memory access, bandwidth, etc are independently tunable knobs within the mining function.
08:06 < bsm117532> At that point a purpose-specific ASIC would have a very hard time competing with the general purpose GPU...
08:07 < Taek> then you've gone and optimized your algorithm around a single chip. Hardware is still getting better, and you've basically locked in a single hardware implementation as the winner
08:08 < Taek> if that implementation is owned by nvidia, then you've made nvidia the new bitmain
08:08 < bsm117532> Yeah I'm not saying this is a good idea...
08:08 < kanzure> re: memory-hard functions, i thought there was a concern that DRAM manufacturers are even less decentralized than <90nm asic manufacturers?
08:08 < Taek> indeed
08:09 -!- kmels [~kmels@105.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 240 seconds]
08:09 < bsm117532> Well, in as much as fabs have kind-of become a shared resource...the bitcoin mining industry just uses them like anyone else.
08:10 < Taek> seems that currently the bottleneck is a really high fixed cost for making ASIC masks. My hunch then is that you could make a new PoW algorithm that optimizes around reducing the cost of making masks
08:10 < kanzure> there are maskless asic manufacturing techniques but i dunno if they are compatible with the 16nm stuff.   for example, micromirror arrays or liquid crystal displays as masks.
08:10 < Taek> I don't know what all goes into masks, but I'd guess that a lot of it deals with catering specifically to the algo you want to implement
08:11 < kanzure> my backgroud w/ maskless manufacturing stuff is mostly re: microfluidics, i was speccing out a microfluidic fabrication tool and i hated the idea of masks so i wanted to use a standard household micromirror array projector etc.
08:12 < luke-jr> Raccoon: BFGMiner still supports CPU/GPU
08:27 -!- talmai [~T@74.118.24.210] has quit [Ping timeout: 240 seconds]
08:38 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]
08:38 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
08:38 -!- dbarrett [~dbarrett@unaffiliated/dbarrett] has joined #bitcoin-wizards
08:43 -!- talmai [~T@172.58.216.83] has joined #bitcoin-wizards
08:44 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
08:45 -!- kmels [~kmels@190.14.133.6] has joined #bitcoin-wizards
08:52 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
08:53 -!- talmai [~T@172.58.216.83] has quit [Ping timeout: 240 seconds]
08:53 -!- Giszmo [~leo@201.215.13.240] has quit [Quit: Leaving.]
08:53 -!- MaxSan [~one@213.152.162.10] has quit [Ping timeout: 240 seconds]
08:58 < phantomcircuit> kanzure, newer processes absolutely require a mask
08:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
08:58 -!- harrymm [~wayne@104.237.91.251] has joined #bitcoin-wizards
08:58 < phantomcircuit> bsm117532, the issue is who owns the mask
09:00 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-wizards
09:00 < bsm117532> The mask is a physical mask?
09:04 < bsm117532> Perhaps the actual charter of an open-source hardware organization would be to create copies of the mask for distribution.  Is that feasible?
09:18 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
09:18 -!- iddo_ is now known as iddo
09:18 -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Changing host]
09:18 -!- iddo [~idddo@unaffiliated/iddo] has joined #bitcoin-wizards
09:24 -!- CubicEarth [~cubiceart@host81-134-33-95.in-addr.btopenworld.com] has joined #bitcoin-wizards
09:29 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]
09:33 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
09:40 -!- CubicEarth [~cubiceart@host81-134-33-95.in-addr.btopenworld.com] has quit [Ping timeout: 246 seconds]
09:44 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
09:45 -!- talmai [~T@172.58.216.83] has joined #bitcoin-wizards
09:58 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
10:10 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
10:10 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
10:11 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
10:20 -!- MaxSan [~one@213.152.162.74] has joined #bitcoin-wizards
10:21 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
10:23 -!- talmai [~T@172.58.216.83] has quit [Ping timeout: 240 seconds]
10:35 < phantomcircuit> bsm117532, https://en.wikipedia.org/wiki/Photomask
10:35 < phantomcircuit> same idea
10:35 < phantomcircuit> different material
10:36 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has joined #bitcoin-wizards
10:54 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
10:55 -!- JackH [~laptop@79-73-189-229.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
10:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
10:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
11:02 -!- MaxSan [~one@213.152.162.74] has quit [Ping timeout: 240 seconds]
11:03 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
11:16 -!- MaxSan [~one@213.152.162.74] has joined #bitcoin-wizards
11:27 < Taek> masks don't translate well between fabs, every time you switch to a new fab you're going to need a new set of masks, more or less
11:28 < Taek> also, at least the guys I'm talking to didn't seem interested in open-sourcing the hardware designs. They said they have some proprietary optimizations they do on the chips
11:30 < bsm117532> All the more reason to find a way to do it...
11:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tywysrwbtwdekvcg] has joined #bitcoin-wizards
11:44 -!- MaxSan [~one@213.152.162.74] has quit [Ping timeout: 240 seconds]
11:49 -!- GreenF [~inteligen@201.20.137.1] has quit [Ping timeout: 246 seconds]
11:56 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
11:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
11:59 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
12:01 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
12:14 -!- uiuc-slack [~uiuc-slac@li175-104.members.linode.com] has quit [Read error: Connection reset by peer]
12:14 -!- uiuc-slack [~uiuc-slac@li175-104.members.linode.com] has joined #bitcoin-wizards
12:20 -!- dermoth [~thomas@dsl-199-102-159-103.mtl.aei.ca] has joined #bitcoin-wizards
12:21 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards
12:23 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:30 < dermoth> Hey there... moving a discussion from the dev channel; I was thinking about the issue of block size vs. propagation time...
12:30 < dermoth> What if the block header included a bloom filter on tx inputs (or rather hash + params), so miners could at least include any transactions that the bloom filter tells for sure cannot be double spends from the accompanying block header.
12:30 < dermoth> in a few additional kb's the miners could include many transactions that are save until they can actually download the rest of the block data and validate it.
12:31 -!- kristofferR [~kristoffe@75.37-191-170.fiber.lynet.no] has joined #bitcoin-wizards
12:31 < dermoth> gmaxwell, let'S continue the topic here.... you mentioned a proposal... was it a BIP, mailing list thread, etc...?
12:31 < gmaxwell> dermoth: About a year ago someone proposed this on bitcoin-dev mailing list (or bct? I forget) creating a bloom filter of the txins spent by a block so that miners could do even more mining without validating and not miss out on collecting (most of the) fees.
12:34 -!- nullfxn [~nullFxn@107-147-126-52.res.bhn.net] has quit [Quit: leaving]
12:34 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
12:36 < gmaxwell> But it runs into the issue that validationless mining is really super toxic to lite client security (thus scalability)-- so increasing the amounts of it is not a public good,  and if miners just want to optimize their income they just centeralize further-- which is simpler and safer than these approaches.
12:37 < gmaxwell> Plus fibre (and a lesser extent BIP152) and what not already transfer the actual block with minimal information.
12:37 < gmaxwell> I'm looking for the thread.
12:40 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
12:41 < dermoth> Shouldn'T miner centralisation be considered toxic too? and I'd like to understand the arguments about SPV client as what I'm proposing is merely to solve the 0tx-block issue... I'm not proposing to replace any of the existing validation in place
12:41 < dermoth> thanks for looking
12:41 < gmaxwell> AJ towns was the author btw.
12:41 < gmaxwell> of what I'm referring to, still looking for it but I know the author now.
12:41 < gmaxwell> :P
12:42 < gmaxwell> dermoth: from a security perspective prolonged validationless mining and pool style centeralization are very close to the same thing.
12:43 < gmaxwell> In both cases, users get a chain that has only been validated by one party, even when it has multiple blocks.
12:44 < gmaxwell> FWIW from a private email I sent to stephen pair:
12:44 < gmaxwell> --
12:44 < gmaxwell> AJ towns previously proposed miners commit to a tiny bloom filter for
12:44 < gmaxwell> the input ID they already included, this allows near instant checking
12:44 < gmaxwell> of includable transactions, with small enough space that it could
12:44 < gmaxwell> still fit in a single IP packet. Even without any commitment, miners
12:44 < gmaxwell> could simply send this filter: today all (or virtually all) SPV mining
12:44 < gmaxwell> is done between known and at least semi-trusted parties; so a
12:44 < gmaxwell> bilateral agreement to exchange such masks would likely fit their
12:44 < gmaxwell> business needs even if it isn't useful for network security.
12:44 < gmaxwell> --
12:44 < gmaxwell> so now to find the message from AJ.
12:45 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 255 seconds]
12:45 < gmaxwell> I found the post, but now I need fo figure out how to link to it.
12:46 < dermoth> thanks... gmane?
12:46 < dermoth> just give me the mailing list /subject
12:47 < gmaxwell> doesn't appear to be in list archives. And the most interesting part of the discussion was actually in private message between him and I, lemme find out if he has any issue with sharing it with you.
12:47 < gmaxwell> (where I point out that the filters would actually be bigger than FBRP block messages)
12:47 < dermoth> how big?
12:47 < dermoth> approx
12:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
12:48 < gmaxwell> he computed 7168 bytes for current (at the time) blocksizes.
12:49 < dermoth> that'S way too much
12:49 < gmaxwell> he gave figures for it, I believe.
12:49 < gmaxwell> keep in mind that there are several times more inputs than transactions in a block.
12:50 < dermoth> I'm not an expert, but using what seems to be a very trustable bloom filter calculator 30 tx with only 1% false positive takes only 3.51kb
12:50 < dermoth> oh right
12:50 < gmaxwell> 30 tx?  a typical block has about 5000 inputs.
12:50 < dermoth> let's go with 30k, 10%, 17.55k
12:51 < dermoth> oops I meant 3k tx
12:51 < dermoth> for the rearlier sentense!
12:51 < gmaxwell> dermoth: right thats larger than a FBRP block, (two bytes per transaction).
12:51 < dermoth> 3k, 1% 3.51kb. 30k, 10%, 17.55kb
12:52 < gmaxwell> or right at the size.
12:52 < bsm117532> FWIW since bloom filters provide effectively no privacy protection (as hoped when BIP37 was written), it's much simpler to use Cuckoo filters, and they're much easier to reason about.  Just consider a filter that contains the first N bits of the txid (or keyhash, or whatever).
12:52 -!- smk [4ad8c7ae@gateway/web/freenode/ip.74.216.199.174] has joined #bitcoin-wizards
12:52 < sipa> bsm117532: we're not talking about BIP37
12:53 < dermoth> I'm wondering how both scale... argualibaly you can allow much larger number of false positives
12:53 < sipa> privacy for block transmission is not an issue
12:53 < gmaxwell> 3k inputs means maybe 1500 transactions, which would take 3000 bytes in the FBRP.
12:53 < bsm117532> sipa: yes so why use bloom filters?  You can dump the extra parameter (number of hash functions) and just transmit the first N bits of each object instead.  Faster and simpler.
12:54 < dermoth> bsm117532, but if any tx isn't in your mempool you need to retrieve it
12:55 < gmaxwell> bsm117532: that is not what a cuckoo filter is, FWIW. (I mean it's one step, but in a cuckoo filter additional hash data constraints what slots a item can be in)
12:55 < sipa> bsm117532: that's effectively what BIP152 does (send the first 48 bits of a salted hash of the txids)
12:55 < sipa> but in doing so, it transfers the whole blocks
12:55 < gmaxwell> which doesn't support dermoth's dubious goal of making it possible to mine without validation more. :)
12:55 < sipa> not just its spent inputs
12:56 < dermoth> lol
12:56 < gmaxwell> dermoth: FWIW, in both FBRP and fibre there is no "you need to retrieve it".
12:57 < bsm117532> It's been a while since I read the Cuckoo paper....  But this idea of "just transmit the first N bits" works as long as the underlying object is uniformly distributed (e.g. a txid).
12:57 < gmaxwell> in FBRP the sending side always knows a minimum set of tx that you already have (which get mapped to two byte IDs) and then sends any additional ones explicitly.  And fibre uses an erasure code to send correction data that lets you recover the missing transactions without the sender knowing what you're missing.
12:57 < dermoth> I'll need to sit down and read the BIP... my thought is if you have the first bits of the tx hash how can you tell a tx you're including in the next block isn't a double spend?
12:57 < gmaxwell> bsm117532: yes but the performance is only competative/better bloom with the positional constraint. The position contains additional information about the match.
12:58 < gmaxwell> dermoth: BIP152? you don't as I said, it doesn't satisify your goal. But bsm117532 points your goal would be better satisified by a cuckoo filter (which is true, though he mangles the description of a cuckoo filter a bit).
12:59 < gmaxwell> And what I was pointing out that FBRP and Fibre (which do the vast majority of the block-miles transport) don't have the "but you have to get more data" problem.
13:02 < kanzure> .title https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
13:02 < yoleaux> [bitcoin-dev] Rolling UTXO set hashes
13:04 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
13:04 < bsm117532> ... "but does not support any compact proofs of existence or non-existence"  :-( :-( :-(
13:06 < sipa> bsm117532: read on
13:06 < sipa> it's also not incompatible with it
13:07 < gmaxwell> Big problem with all the prior utxo like commitments is that there is no clear leader yet (making radically different tradeoffs), and they are very incompatible with each other.
13:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 258 seconds]
13:09 < gmaxwell> and are all, except perhaps bramc's txo bitfield, pretty IO costly too.  So this is compatible with all of them, has no IO cost, and at least lets you do the things that don't need compact (non)membership proofs.
13:11 < bsm117532> sipa: very interesting.
13:11 -!- katu_ [~katlogic@router-krasovska-nat.pilsfree.net] has quit [Ping timeout: 245 seconds]
13:11 < bsm117532> sipa: how could you build on this to enable (non-)membership proofs?
13:11 < gmaxwell> You can't.
13:11 < gmaxwell> but you can run a thing that can do them along side it.
13:11 < gmaxwell> Without any gratitious cost.
13:12 < gmaxwell> Which you cannot do with any of the compact proof compatible things, they all have significant IO costs.
13:12 < bsm117532> gmaxwell: But wouldn't that "thing" incur all the negatives you mention above?
13:12 < sipa> bsm117532: no
13:13 < sipa> the problem is that for example a UTXO commitment structure may require future full nodes to always maintain a UTXO set
13:13 < sipa> or may remove that need for some use cases, but not all
13:13 < sipa> or may eliminate it entirely, but only by choosing a large bandwidth increase for transactions
13:14 < sipa> the problem is that it's not clear which of those choices we'll want to make
13:14 < sipa> and they are incompatible with eachother
13:14 < sipa> this rolling UTXO set hash is compatible with all of them
13:14 < gmaxwell> (sipa is walking down lists of the actual implications of existing proposals)
13:15 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]
13:16 < sipa> because interestingly, it does not actually require to keep a UTXO set... all you need to do is see blocks (to know what to add), and what outputs are being spent (which you already need to do in order to validate)
13:17 -!- katu [~katlogic@router-krasovska-nat.pilsfree.net] has joined #bitcoin-wizards
13:17 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
13:20 < bsm117532> Doesn't the associativity of the update operation make it very easy to compute an alternative history having the same hash value?
13:21 < sipa> if you do it naively, yes
13:21 < sipa> read the mail, it addresses that
13:21 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
13:21 < bsm117532> Is that what you mean with gaussian elimination?
13:21 < sipa> that's one of the ways to attack the construction if you use XOR as combinator
13:22 < sipa> say you use 256-bit hashes and xor them
13:22 < sipa> generate a few hundred random outputs, compute their hashes
13:22 < sipa> now you're trying to find a subset of them which xor to a given valeu
13:23 < gmaxwell> bsm117532: if you just mean an 'alternative history that results in the same utxo set' well duh sure, but that is not a bug. The utxo set is the same, which is the goal.  It's a hash of the set, not of its update order.
13:23 < sipa> ah
13:23 < sipa> well you commit to the hash of the tip block as well
13:23 < bsm117532> No I meant alternative history with the same *hash* but different utxo set.
13:24 < sipa> bsm117532: that's not possible if you use one of the provably safe constructions
13:24 < sipa> Wagner's paper shows that that problem is at least as hard as computing the discrete logarithm
13:25 < bsm117532> Very interesting...I discarded some related ideas a while ago for all the reasons you suggest re: insecure XOR combinator...
13:25 < sipa> yup, me too
13:25 < sipa> i had come up with the XOR construction myself, later discovered it was insecure, and then discarded the whole idea of order-independent hashes
13:26 < gmaxwell> it's a fairly simple proof.  If you try to add members of a DL hard group to match a fixed group where the members are generated by a random oracle,  and you have a blackbox solver that can take a stream of random members and find a set that adds up to the target,  then you replace your random oracle with a box that takes random numbers times G and outputs them.  Then you use your blackbost k-sum
13:26 < gmaxwell>  solver to find the discrete log.
13:26 < bsm117532> I was looking for ways to combine proofs of work.
13:26 < bsm117532> Which, if you could do, could allow you to improve mining decentralization.
13:26 < gmaxwell> s/blackbost/blackbox/
13:27 < bsm117532> (e.g. sub-block or tx level mining -- and a mechanism to aggregate it into a single hash)
13:28 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
13:29 -!- dnaleor_ [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 240 seconds]
13:37 < bsm117532> sipa: https://arxiv.org/pdf/1601.06502.pdf (Elliptic Curve Multiset Hash) seems to be the real kicker for this idea.  Can you elaborate as to why you described it as "controversial"?
13:37 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
13:40 < sipa> it uses binary curves, whose security has been less certain recently
13:41 -!- Dyaheon [~Dya@91.156.192.24] has quit [Ping timeout: 240 seconds]
13:41 < sipa> (curves with a coordinate field GF(2^n), as opposed to mod a large prime)
13:41 -!- MaxSan [~one@213.152.162.74] has joined #bitcoin-wizards
13:42 -!- dnaleor_ [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
13:43 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-wizards
13:56 < bsm117532> sipa: and all that is needed to replace that controversy is another way to map hash functions to ECC points, correct?
13:58 < sipa> bsm117532: yup, and it seems that in all mod p curves, that's an operation that at least requires a square root operation
13:58 < sipa> which is "hard" for mod p
13:59 < bsm117532> So you're mapping a sha512 hash to two secp256k1 points (deterministically, I assume), and adding them?
14:00 < sipa> no, one
14:01 < sipa> interpret the output of your hash as an X coordinate
14:01 < sipa> find the corresponding Y
14:01 < sipa> if it has one, you're done
14:02 < sipa> if it doesn't compute a new sha512 (by appending some counter to its input, or by hashing the last 32 bytes again, or ...)
14:02 < sipa> and start over
14:02 < sipa> 50% chance you need 1 iteration
14:02 < sipa> 25% chance you need 2
14:02 < sipa> 12.5% chance you need 3
14:02 < sipa> etc
14:03 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
14:06 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
14:07 < bsm117532> Aaaaah I see
14:09 -!- smk [4ad8c7ae@gateway/web/freenode/ip.74.216.199.174] has quit [Ping timeout: 260 seconds]
14:09 < bsm117532> And with a 512 bit hash you've got a 2^-256 probability that the algorithm fails.  Except...birthday...probably means the algorithm is guaranteed to succeed?
14:22 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
14:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
14:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
14:24 -!- JackH [~laptop@79-73-189-229.dynamic.dsl.as9105.com] has joined #bitcoin-wizards
14:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
14:27 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
14:27 -!- epsi10n [~textual@81.171.58.88] has joined #bitcoin-wizards
14:29 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
14:34 < gmaxwell> it's guarenteed to be successful, that isn't the concern.
14:35 < gmaxwell> computing the sqrt is slow and non-batchable.
14:35 < gmaxwell> curves over 2^n don't have that issue, you can use the half-trace to decompress points.
14:35 < gmaxwell> but they have a much weaker security story overall.
14:36 < gmaxwell> Authors of that paper argue that it's no big deal, but don't factor in improvements.
14:36 < gmaxwell> that comparison also ignores the complexity.
14:37 < gmaxwell> fast code for multiplication Fp is trivial,  supporting another elliptic curve with state of the art performance not so much.
14:39 < MaxSan> gmaxwell: if your such a dam master of bitcoin why isnt segwit activated yet eh?!/
14:39 -!- epsi10n [~textual@81.171.58.88] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
14:39 < MaxSan> EH?!
14:40 -!- mode/#bitcoin-wizards [+o sipa] by ChanServ
14:40 < MaxSan> ;)
14:40 < gmaxwell> MaxSan: uh. it's all part of my evil plan?
14:40 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
14:41 < MaxSan> I knew it all along! Quoted for twitter! ;)
14:41 -!- mode/#bitcoin-wizards [-o sipa] by ChanServ
14:41 < MaxSan> Not sure if anyone has heard of Radix but they be releasing their patents soon, very curious as to what they have inside them
14:41 < MaxSan> making very bold claims..
14:42 -!- kmels [~kmels@190.14.133.6] has quit [Ping timeout: 268 seconds]
14:43 < gmaxwell> MaxSan: smelled like snakeoil a year ago, don't see why it would change because they've changed the name of it.
14:43 < sipa> never heard of
14:44 < gmaxwell> 'eMunie'  one of these "omg I just heard of 'sharding' stack overflow and it will solve all the words problems!" things.
14:45 < JackH> Ignoring coinbase transactions (described later), if the value of a transaction's outputs exceed its inputs, the transaction will be rejected--but if the inputs exceed the value of the outputs, any difference in value may be claimed as a transaction fee by the Bitcoin miner who creates the block containing that transaction. For example, in the illustration above, each transaction spends 10,000 satoshis fewer than
14:45 < JackH>  it receives from its combined inputs, effectively paying a 10,000 satoshi transaction fee.
14:45 < JackH> is this not wrong?
14:45 < JackH> should it not be that any value difference can be either miners fee or also change?
14:46 < gmaxwell> JackH: no, change is an explicit output.
14:46 < gmaxwell> The network itself has no concept of change, your wallet does.
14:46 < JackH> so my wallet code does the actual change, not the rules?
14:46 < sipa> as far as the network is concern, change is just another output
14:46 < JackH> oh wow, I didnt know this
14:47 < sipa> it does not know that it goes back to yourself
14:47 < MaxSan> gmaxwell: yeah maybe. I have some faith. its the claims they are making which are a bit more bold than that..
14:47 < sipa> if it did, privacy of transactions would be almost impossible to achieve
14:47 < JackH> I always assumed change was part of the tx after miners fee and output
14:47 < MaxSan> although if it sounds too good to be true, it generally is.
14:47 < MaxSan> if you listen to their claims it falls into that category
14:48 < MaxSan> but we wont know until its out in the open
14:48 < gmaxwell> MaxSan: if you don't care about decenteralization then scale relative to cryptocurrency usage today is a non-issue. I think my desktop can process something like 500,000 signatures per second.
14:49 < gmaxwell> so anything that talks about scale without also talking about security assumptions and tradeofs is pretty much automatic snake oil unless it's just simple software optimization.
14:49 < MaxSan> absolutely. I understand the problem. Its when they put all these claims together it raises a lot of eyebrows
15:03 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
15:07 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 240 seconds]
15:12 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards
15:16 -!- flandero [~xxwa@host254-130-dynamic.211-62-r.retail.telecomitalia.it] has joined #bitcoin-wizards
15:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
15:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
15:37 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:43 -!- vicenteH [~user@37.15.234.135] has quit [Ping timeout: 240 seconds]
15:49 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
15:51 -!- UnrealLife [~UnrealLif@93.169.56.169] has joined #bitcoin-wizards
15:53 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]
15:57 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
15:57 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has quit [Ping timeout: 246 seconds]
16:01 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
16:01 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 240 seconds]
16:03 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]
16:06 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
16:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
16:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
16:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-wizards
16:15 -!- UnrealLife [~UnrealLif@93.169.56.169] has quit [Ping timeout: 246 seconds]
16:24 -!- kmels [~kmels@105.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards
16:24 -!- Fibonacci [~JoBo@c-73-155-128-180.hsd1.tx.comcast.net] has joined #bitcoin-wizards
16:24 < Fibonacci> Yo
16:31 < gmaxwell> dermoth: I forwarded the thread to the list, it should show up presently.
16:37 < kanzure> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014340.html
16:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
16:51 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
16:56 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 240 seconds]
16:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
17:11 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds]
17:16 -!- thrmo is now known as notthrmo
17:19 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-klcjomxlmrlsftlg] has quit [Quit: Connection closed for inactivity]
17:45 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
17:46 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]
17:46 -!- itsme_ [~textual@85.203.22.18] has joined #bitcoin-wizards
17:48 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-wizards
17:49 < bsm1175321> @sipa your ECMH is in no way homomorphic, correct?  It's simply mapping a hash to a group with associativity?  (e.g. H(a) + H(b) is unrelated to H(a x b) for any suitable definition of + and x)
17:50 < sipa> yes
17:50 < sipa> it requires a random oracle in between for security
17:50 < bsm1175321> I now realize that the last time I thought about it was because I read your ref [5] (Bellare & Micciancio incremental hash functions)
17:50 < sipa> which would break any homomorphic properties
17:50 < bsm1175321> yes
17:50 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 272 seconds]
17:52 < bsm1175321> When I read [5] I was unhappy with all their variants and came up with my own: take all the data and put it into a Merkle tree.  A simple "incremental" hash function is a Merkle path to the location to add the *next* entry.  It's log(n) in size and can be updated in the way they state.
17:53 < bsm1175321> Of course that is ordered where yours is unordered.
18:02 < gmaxwell> and then it doesn't work without making the data normative and ordered and you cannot remove from it without having all the data or getting an update proof.
18:03 < gmaxwell> which is precisely what we're trying to avoid there: having a commitment scheme that forces nodes to keep the whole utxo set, since there are proposals that eliminate that requirement in exchange for other tradeoffs.
18:06 -!- packet [~packetsmu@96-66-250-198-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
18:11 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-wizards
18:14 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
18:20 -!- packet [~packetsmu@96-66-250-198-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
18:20 < bsm1175321> gmaxwell: yep, I like it.  Now to figure out proofs of presence and absence... ;-)
18:26 -!- itsme_ [~textual@85.203.22.18] has quit [Quit: Textual IRC Client: www.textualapp.com]
18:32 < bsm1175321> Using this ECMH scheme, a single block is also described by a single ECMH hash...and if committed to, can be added directly to the running tally.
18:32 < bsm1175321> Does this improve the situation with validationless mining at all?
18:33 < gmaxwell> No, not really. validationless mining is cooperative.
18:34 < bsm1175321> Darn, but that's what I thought too... :-/
18:35 < gmaxwell> One could block VFM based on non-cooperating parties by doing something like commitment = H(H(coinbaseoutputs)|H(accumulator)).  But then cooerating VFM miners could just share H(accumulator) values.
18:35 -!- MaxSan [~one@213.152.162.74] has quit [Ping timeout: 260 seconds]
18:35 < gmaxwell> The reason I point out that it's cooperative is that if someone spy mines on your stratum port and you dont like it, you can start giving them invalid work and make them waste their time. :)
18:36 < gmaxwell> but to whatever extent uncooperative VFM exists you could dampen it that way.
18:38 < bsm1175321> I wonder if the commitment could be required to involve the privkey of the coinbase in a verifiable manner...such that divulging the preimage of the commitment would share your coinbase privkey...
18:39 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
18:44 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 240 seconds]
18:44 -!- kmels [~kmels@105.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 260 seconds]
18:50 < bsm1175321> I think not...whatever method is used to verify the commitment without the privkey (e.g. used by miners other than the creator of this block) can be shared at an intermediate computational stage.
18:50 -!- notthrmo is now known as thrmo
18:50 -!- Fibonacci [~JoBo@c-73-155-128-180.hsd1.tx.comcast.net] has quit [Ping timeout: 240 seconds]
19:05 < bsm1175321> sipa: proof of presence is possible by presenting the sum of all hashes, *except* the one you're interested in, if computing the additive inverse is hard.
19:06 < bsm1175321> e.g. instead of subtracting spent inputs, compute inputs as e.g. H("input"+txid) and outputs and H("output"+txid) and sum them all.
19:06 < sipa> computing the inverse is trivial
19:06 < sipa> we need for spedning
19:06 < bsm1175321> Computing the preimage of the additive inverse is trivial?
19:07 < sipa> it's a modular inverse in the MuHash case
19:07 < sipa> it's a sign flip in the ECMH case
19:07 < sipa> otherwise removing entries from the hash would be hard
19:08 < bsm1175321> I'm exactly saying don't remove entries, accumulate everything.
19:08 < sipa> then how can someone who receives a UTXO set verify its integrity?
19:08 -!- thrmo [~thrmo@unaffiliated/thrmo] has quit [Ping timeout: 240 seconds]
19:09 < sipa> ah, i think i see what you mean
19:09 < bsm1175321> The commitment is to sum(outputs)+sum(inputs) rather than sum(outputs)-sum(inputs)
19:09 < sipa> assume that you somehow have a group in which computing the inverse is hard
19:09 < sipa> and now just compute a hash for all creations, and one for all spends
19:09 < bsm1175321> yes.
19:10 < sipa> sounds like you need an RSA group
19:10 < bsm1175321> It's an O(1) proof too, which is pretty interesting considering Merkle proofs are O(log(N))
19:10 < sipa> unfortunately, RSA groups have a trusted setup
19:11 < sipa> (the person coming up with the modulus needs to know its factors)
19:11 < bsm1175321> sipa: why RSA?  What's wrong with just prefixing the preimage with "input" or "output"?
19:11 < sipa> that doesn't make computing an inverse hard
19:12 < bsm1175321> Oh I see.  You give me a txid, I can compute H("output"+txid), take its inverse, and add it to the known commitment, to generate any proof you want.
19:12 < sipa> yup.
19:12 < bsm1175321> darn.
19:12 < sipa> but in an RSA group you cannot invert
19:12 < sipa> unless you know the factorization of the group modulus
19:14 < sipa> ... apart from the trusted setup, that sounds very appealing actually
19:15 < bsm1175321> Unfortunately I can't figure out a way to do proof of absence.  The "unordered" bit precludes it.  You'd have to impose an ordering to get proofs of absence.
19:15 < sipa> you can produce of proof of spentness
19:15 < sipa> or a proof of creation
19:15 < sipa> or a proof of unspentness
19:16 < bsm1175321> As separate commitments, yes...
19:16 < sipa> if you have a commitment to both the multiplication of all the creations and one to the multiplication of all the spends
19:17 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Read error: Connection reset by peer]
19:18 < bsm1175321> That's a hell of a lot simpler than imposing some kind of ordering.
19:18 < sipa> proofs would be 768 bytes, though
19:20 < bsm1175321> Kind of kills the advantage of proofs being O(1)...
19:21 < sipa> producing a proof also requires iterating over all unspent outputs, i think
19:22 < sipa> (a proof of unspentness)
19:23 < bsm1175321> Yes but that can be optimized by keeping intermediate sums in a binary tree.
19:23 < sipa> with 384 bytes per node in the tree...
19:23 < sipa> many times larger than the blockchain itself, i think
19:24 < bsm1175321> Perhaps there's another way to make additive inverses hard...
19:24 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards
19:26 < bsm1175321> Or, use multiplication instead of addition...
19:26 < sipa> that's what MuHash does
19:27 < sipa> and a multiplicative inverse is easy
19:27 < sipa> ... except in an RSA group :)
19:27 < bsm1175321> Not in elliptic curves ;-)
19:27 < sipa> there is no multiplication of EC points
19:28 < sipa> and if you mean multiplication by integers, that's still trivial to invert
19:30 < bsm1175321> Now I'm super confused.  Both pubkey derivation from a privkey and ECDH are ec point multiplications I thought...
19:30 < sipa> multiplication of an EC point with an integer, yes
19:31 < sipa> if a * B = C (with a an integer, and B and C points), it's hard to compute a from B and C
19:31 < sipa> but trivial to compute B from a and C
19:32 < bsm1175321> Ah I see...
19:32 < sipa> because B = (1 / a) * C
19:33 < bsm1175321> yep
19:34 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
19:36 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Ping timeout: 246 seconds]
19:37 < bsm1175321> Perhaps if there were some kind of pairing, such that you compute the commitment on both sides of the pairing in different ways, such that on the "other" side of the pairing, the additive inverse requires knowledge of a preimage that you don't have...
19:38 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 246 seconds]
19:49 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 240 seconds]
19:52 < bsm1175321> I don't think that works...nodes can compute everything on the "other" side of the pairing anyway...
19:53 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
19:54 < gmaxwell> I see you reinvented RSA accumulators above.
19:54 < gmaxwell> Note that they require trusted setup. You can get rid of the trusted setup by using a UFO ("unfactorable object") but they makes the numbers ~10x larger.
19:56 < bsm1175321> My second idea seems to be reinventing a bilinear map accumulator: https://eprint.iacr.org/2008/539.pdf
19:57 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Remote host closed the connection]
19:58 -!- fibonacci_ [uid136497@gateway/web/irccloud.com/x-azsmmhwyqmaiqgvj] has joined #bitcoin-wizards
20:05 < bsm1175321> https://fc13.ifca.ai/proc/5-3.pdf
20:09 < bsm1175321> In this literature, "revocation" can be directly mapped onto a "spent output", and they can indeed prove both presence and absence using accumulators.
20:13 < fibonacci_> When do Fibonacci fragments get implemented?
20:15 -!- danrobinson [~danrobins@2604:2000:e080:d400:c9ca:c4db:f415:34c] has joined #bitcoin-wizards
20:17 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards
20:19 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]
20:21 < danrobinson> fibonacci_: oh it's the main focus of most modern blockchain research
20:21 < danrobinson> they've got us working in shifts
20:25 < sipa> wth are fibonacci fragments?
20:28 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
20:33 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 260 seconds]
20:35 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-wizards
20:36 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
20:38 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 240 seconds]
20:45 -!- Fibonacci [~JoBo@c-73-155-128-180.hsd1.tx.comcast.net] has joined #bitcoin-wizards
20:53 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
20:54 -!- Fibonacci [~JoBo@c-73-155-128-180.hsd1.tx.comcast.net] has quit [Quit: Leaving]
20:54 -!- kmels [~kmels@105.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards
21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection]
21:00 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards
21:03 -!- kmels [~kmels@105.62.151.186.static.intelnet.net.gt] has quit [Quit: Saliendo]
21:10 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Remote host closed the connection]
21:11 < fibonacci_> danrobinson: are you serious?
21:11 < danrobinson> i am not
21:12 < fibonacci_> It's the extra 5 decimals lol
21:12 < fibonacci_> That was funny then
21:12 < fibonacci_> You had me... it would be fruitful research to implement the Golden Ratio though for sure
21:13 < fibonacci_> And it would take the attention of all the brilliant minds to accomplish it
21:14 < fibonacci_> DNA is the most efficient data management tool known to man and crypto should be emulating it any way possible
21:15 -!- Fibonacci [~JoBo@c-73-155-128-180.hsd1.tx.comcast.net] has joined #bitcoin-wizards
21:19 < fibonacci_> A very simple implementation is adding an extra 5 decimals for 13 total so that when bitcoins price goes through the roof the satoshi has a fragmentation of an additional 10000 units. 13 decimals seems to me to be the best way to break up the satishi. Just something for consideration
21:27 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
21:29 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
21:30 < Fibonacci> Self similarity in multiple blockchains would allow for easier mending of multiple blockchains
21:32 -!- danrobinson [~danrobins@2604:2000:e080:d400:c9ca:c4db:f415:34c] has quit [Quit: danrobinson]
21:35 -!- danrobinson [~danrobins@2604:2000:e080:d400:c9ca:c4db:f415:34c] has joined #bitcoin-wizards
21:35 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 240 seconds]
21:37 -!- harrymm [~wayne@104.237.91.251] has quit [Read error: Connection reset by peer]
21:38 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
21:39 -!- harrymm [~wayne@104.237.91.97] has joined #bitcoin-wizards
21:43 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 255 seconds]
21:44 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
21:46 < sipa> Fibonacci: get lost
21:46 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds]
21:48 < Fibonacci> rude
21:48 < sipa> then stop producing nonsense
21:48 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-wizards
21:50 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 268 seconds]
21:51 < Fibonacci> How is the addition of 5 extra decimals and talking about a means of more effectively merging blockchain networks by organizing the data nonsense?
21:53 < sipa> i don't believe you have any clue what you're talking about
21:53 < sipa> prove me wrong by showing some code
21:53 < Fibonacci> The topic talks about long term application I'm talking about if bitcoin becomes more valueable.
21:53 < Fibonacci> I'm not a coder
21:54 < sipa> then stop producing sentences with random technical terms in it
21:54 -!- mode/#bitcoin-wizards [+o sipa] by ChanServ
21:54 -!- harrymm [~wayne@104.237.91.97] has quit [Ping timeout: 268 seconds]
21:54 < Fibonacci> I used multiple blockchains twice in one sentence my apologies
21:56 < Fibonacci> I'm just using the best words I have to describe what I'm talking about but assuming I don't have a point before inquiring what I mean is the arrogance and dismissiveness that is so prevalent in the bitcoins Coding community and also why it has been stagnant for long periods
21:58 < Fibonacci> It comes down to a few asshole creating cryptic language so they appear smart and projecting their ignorance on everyone who visits.
21:59 < Fibonacci> ttyl
22:00 < Fibonacci> If you guys were so smart things would operate on a much higher level. It's a joke. Get your shit together know it alls
22:00 -!- Fibonacci [~JoBo@c-73-155-128-180.hsd1.tx.comcast.net] has left #bitcoin-wizards ["Leaving"]
22:04 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
22:05 < gmaxwell> "creating cryptic language so they appear smart", says the guy calling five extra decimals "fibonacci fragments".
22:05 -!- mode/#bitcoin-wizards [+o gmaxwell] by ChanServ
22:06 -!- mode/#bitcoin-wizards [+b Fibonacci!*@*] by gmaxwell
22:06 -!- mode/#bitcoin-wizards [+b *!*@c-73-155-128-180.hsd1.tx.comcast.net] by gmaxwell
22:06 -!- mode/#bitcoin-wizards [-o gmaxwell] by gmaxwell
22:11 -!- tromp [~tromp@148.75.196.67] has joined #bitcoin-wizards
22:12 -!- harrymm [~wayne@104.237.91.12] has joined #bitcoin-wizards
22:15 -!- tromp [~tromp@148.75.196.67] has quit [Ping timeout: 240 seconds]
22:37 -!- pavel_ [~paveljani@79.98.72.176] has quit [Quit: Leaving]
22:45 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Remote host closed the connection]
22:47 -!- UnrealLife [~UnrealLif@2001:16a2:465:800:1d0c:316e:3cf3:ac2f] has joined #bitcoin-wizards
23:09 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
23:09 -!- PaulCape_ [~PaulCapes@136.24.141.225] has joined #bitcoin-wizards
23:10 -!- UnrealLife1 [~UnrealLif@37.107.18.174] has joined #bitcoin-wizards
23:10 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5dfe:6aa6:f987:2fdf] has quit [Ping timeout: 255 seconds]
23:10 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards
23:11 -!- arowser [~quassel@106.120.101.38] has quit [Read error: Connection reset by peer]
23:11 -!- UnrealLife [~UnrealLif@2001:16a2:465:800:1d0c:316e:3cf3:ac2f] has quit [Ping timeout: 240 seconds]
23:12 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
23:16 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
23:36 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
23:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
23:47 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds]
23:49 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
23:50 -!- JackH [~laptop@79-73-189-229.dynamic.dsl.as9105.com] has quit [Ping timeout: 268 seconds]
23:52 -!- danrobinson [~danrobins@2604:2000:e080:d400:c9ca:c4db:f415:34c] has quit [Quit: danrobinson]
23:54 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards
23:57 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
--- Log closed Tue May 16 00:00:55 2017