| --- Log opened Wed Dec 30 00:00:51 2015 | ||
| bramc | Interesting point in the weak blocks presentation: maybe you should accept weaker weak blocks when only a fraction of all mining power is using them. Maybe a good convention would be for peers to accept all weak blocks within some fraction of the strongest weak block they've seen in recent history | 00:06 |
|---|---|---|
| bramc | Maybe it would be good to be a bit more sophisticated than that in case some joker decides to make lots of weak blocks but throw out his 'good' weak blocks | 00:07 |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 00:07 | |
| bramc | Also to make it less noisy | 00:09 |
| tulip | bramc: not really, that hardware and configuration performed a block withholding attack against p2pool. | 00:20 |
| bramc | Here's a formula: For each block, take the weakest weak block accepted, multiply by the number of weak blocks accepted for that block, and divide by 20. That's a reasonable threshold. | 00:20 |
| bramc | To prevent DoS set a maximum number of weak blocks you'll accept per block, say 100 | 00:23 |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving] | 00:23 | |
| bramc | although the number of weak blocks per strong block is extremely noisy due to strong block arrival being so noisy. Harumph. | 00:24 |
| bramc | Another post on weak blocks suggests their strength as 5%. Apparently the going rate is that there should be 20 weak blocks for every strong block. | 00:28 |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ouppmgxlnnuqexsc] has quit [Quit: Connection closed for inactivity] | 00:31 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 00:32 | |
| -!- tulip [~tulip@unaffiliated/tulip] has quit [Quit: Textual IRC Client: www.textualapp.com] | 00:32 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 276 seconds] | 00:38 | |
| bramc | Another post on weak blocks suggests they should have a size limit. I don't like that idea at all. | 00:39 |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 00:39 | |
| bramc | Also I need to think through the important distinction between implicit links between weak blocks and weak references to sets of transactions, sets of transactions meant as deltas, and previous weak blocks | 00:43 |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ppevadrwnrucphgn] has joined #bitcoin-wizards | 00:56 | |
| -!- silvaedium [~faenumis@ip24-253-204-109.ok.ok.cox.net] has quit [Ping timeout: 265 seconds] | 00:59 | |
| bramc | Peter Todd suggests that weak references to upcoming transactions could be used to determine fees for getting things in quickly, which isn't an awful idea. | 01:01 |
| bramc | although I think it's only applicable in the narrow case where you really really want your transaction to go into the next block | 01:02 |
| bramc | A thought on selfish mining: it's particularly applicable when a miner happens to know that they've got more hash power coming online soon, so they can prime the pump for themselves | 01:04 |
| -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Quit: ZNC - http://znc.sourceforge.net] | 01:04 | |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 264 seconds] | 01:05 | |
| -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-wizards | 01:07 | |
| -!- wizkid057 [wk@unaffiliated/wizkid057] has quit [Ping timeout: 250 seconds] | 01:16 | |
| -!- wizkid057 [wk@unaffiliated/wizkid057] has joined #bitcoin-wizards | 01:26 | |
| -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds] | 01:26 | |
| bramc | Okay, I'm done plowing through all the references about weak blocks. Good night everybody. | 01:28 |
| -!- pozitron [~nu@46.166.188.227] has quit [Ping timeout: 240 seconds] | 01:29 | |
| -!- c0rw|zZz [~c0rw1n@91.176.76.47] has joined #bitcoin-wizards | 01:32 | |
| -!- c0rw|zZz_ [~c0rw1n@91.176.76.47] has quit [Ping timeout: 240 seconds] | 01:34 | |
| -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] | 01:43 | |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 01:44 | |
| -!- yosso [~yosso@46.19.85.180] has joined #bitcoin-wizards | 01:47 | |
| -!- ozanyurt [~textual@static.73.76.9.176.clients.your-server.de] has joined #bitcoin-wizards | 01:48 | |
| -!- Guyver2 [~Guyver2@a80-100-156-239.adsl.xs4all.nl] has joined #bitcoin-wizards | 01:56 | |
| -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 02:02 | |
| -!- nuke1989 [~nuke@178-157-152.dynamic.cyta.gr] has quit [Remote host closed the connection] | 02:12 | |
| -!- CubicEarth [~cubiceart@50.141.108.155] has joined #bitcoin-wizards | 02:14 | |
| -!- CubicEar_ [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 02:15 | |
| -!- CubicEarth [~cubiceart@50.141.108.155] has quit [Ping timeout: 245 seconds] | 02:18 | |
| -!- CubicEar_ [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 02:20 | |
| -!- CubicEarth [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 02:21 | |
| -!- CubicEarth [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 02:23 | |
| -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-wizards | 02:28 | |
| -!- CubicEarth [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 02:29 | |
| -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 246 seconds] | 02:31 | |
| -!- LeMiner2 is now known as LeMiner | 02:31 | |
| -!- CubicEarth [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 02:31 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-wizards | 02:32 | |
| -!- CubicEarth [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 02:34 | |
| -!- CubicEarth [~cubiceart@c-73-225-182-54.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 02:35 | |
| -!- kmels [~kmels@120.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 245 seconds] | 02:37 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds] | 02:48 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 02:48 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 02:52 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 02:53 | |
| -!- adam3us1 [~Adium@host-92-18-110-49.as13285.net] has quit [Quit: Leaving.] | 02:56 | |
| -!- adam3us [~Adium@host-92-18-110-49.as13285.net] has joined #bitcoin-wizards | 02:56 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 02:57 | |
| -!- p15_ [~p15@100.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 02:59 | |
| -!- Guyver2 [~Guyver2@a80-100-156-239.adsl.xs4all.nl] has quit [Ping timeout: 245 seconds] | 02:59 | |
| -!- p15 [~p15@87.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 272 seconds] | 03:00 | |
| -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 260 seconds] | 03:00 | |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 03:00 | |
| -!- eudoxia [~eudoxia@r167-56-23-66.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 03:23 | |
| -!- Piper-Off is now known as Monthrect | 03:31 | |
| -!- stevenroose_ [~steven@2a02:2c40:400:b000::1:9fa0] has joined #bitcoin-wizards | 03:40 | |
| -!- yosso [~yosso@46.19.85.180] has quit [Ping timeout: 250 seconds] | 03:44 | |
| -!- pozitrono [~nu@108.61.166.139] has joined #bitcoin-wizards | 03:47 | |
| -!- AaronvanW_ [~ewout@meinhotspot28.websecuritas.com] has joined #bitcoin-wizards | 03:52 | |
| -!- AaronvanW_ [~ewout@meinhotspot28.websecuritas.com] has quit [Remote host closed the connection] | 03:53 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] | 03:53 | |
| CubicEarth | That's why I think we need some general | 04:06 |
| CubicEarth | consensus rules which is not written in code, but as a social contract. | 04:06 |
| CubicEarth | jl2012: You are absolutly correct on this point | 04:06 |
| CubicEarth | That's was jl2012's quote | 04:07 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 04:14 | |
| -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 256 seconds] | 04:46 | |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 04:46 | |
| jl2012 | CubicEarth, for example, a black list system is a softfork technically, but is a hardfork as social contract | 04:54 |
| -!- adam3us [~Adium@host-92-18-110-49.as13285.net] has quit [Quit: Leaving.] | 04:54 | |
| -!- adam3us [~Adium@host-92-18-110-49.as13285.net] has joined #bitcoin-wizards | 04:55 | |
| -!- adam3us [~Adium@host-92-18-110-49.as13285.net] has quit [Client Quit] | 04:56 | |
| CubicEarth | jl2012: Yes. And presumably there are ideals & goals that the contract could lay out, even if they would be imperfect in any real-world implementation | 04:56 |
| CubicEarth | I raised this idea myself a few weeks ago on this channel, and there was serious opposition to the idea. I still think it is needed though. | 04:58 |
| -!- eudoxia [~eudoxia@r167-56-23-66.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 05:00 | |
| -!- TBI_ [~TBI@154.92-220-180.customer.lyse.net] has quit [Read error: Connection reset by peer] | 05:01 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 05:06 | |
| -!- AaronvanW [~ewout@2001:67c:20a1:1192:9cc0:e393:13d3:d05a] has joined #bitcoin-wizards | 05:18 | |
| -!- AaronvanW [~ewout@2001:67c:20a1:1192:9cc0:e393:13d3:d05a] has quit [Changing host] | 05:18 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 05:18 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 05:18 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards | 05:28 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 265 seconds] | 05:48 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-wizards | 05:49 | |
| -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards | 05:55 | |
| -!- tulip [~tulip@unaffiliated/tulip] has quit [Client Quit] | 05:56 | |
| -!- p15_ [~p15@100.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 276 seconds] | 05:59 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] | 06:02 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 06:03 | |
| kanzure | 00:39 < bramc> Another post on weak blocks suggests they should have a size limit. I don't like that idea at all. | 06:06 |
| kanzure | size limit is necessary because weak blocks can only provide a constant factor improvement compared to strong blocks .... | 06:06 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 06:10 | |
| -!- zookolaptop [~user@68.233.157.2] has joined #bitcoin-wizards | 06:23 | |
| -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 240 seconds] | 06:35 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 265 seconds] | 06:38 | |
| -!- qadaemon [~textual@c-73-45-141-214.hsd1.il.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 06:38 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 06:40 | |
| -!- gielbier [~giel____@a149043.upc-a.chello.nl] has joined #bitcoin-wizards | 06:58 | |
| -!- gielbier [~giel____@a149043.upc-a.chello.nl] has quit [Changing host] | 06:58 | |
| -!- gielbier [~giel____@unaffiliated/gielbier] has joined #bitcoin-wizards | 06:58 | |
| kanzure | re: bip102 as a soft-fork, i have posted some links about this class of soft-fork proposals over here https://bitcointalk.org/index.php?topic=1296628.msg13400092#msg13400092 | 07:04 |
| -!- zmachine [~zmachine@pool-74-100-90-30.lsanca.fios.verizon.net] has quit [Ping timeout: 265 seconds] | 07:10 | |
| -!- zmachine [~zmachine@pool-74-100-90-30.lsanca.fios.verizon.net] has joined #bitcoin-wizards | 07:11 | |
| -!- zookolaptop [~user@68.233.157.2] has quit [Ping timeout: 246 seconds] | 07:12 | |
| -!- zmachine [~zmachine@pool-74-100-90-30.lsanca.fios.verizon.net] has quit [Quit: ZNC - http://znc.in] | 07:20 | |
| -!- qadaemon [~textual@12.33.253.130] has joined #bitcoin-wizards | 07:20 | |
| amiller | is it possible to soft fork to increase the 21m coin cap? what would that even mean? | 07:22 |
| amiller | the obvious answer is "of course not"... but generalized soft-forks seem pretty broad so i'm not actually sure where the boundary is | 07:26 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 07:27 | |
| kanzure | do you consider double-spends to increase the cap? :-) | 07:31 |
| amiller | maybe! | 07:33 |
| maaku | amiller: absolutely yes | 07:33 |
| maaku | the 'generalized soft-fork' (aka evil fork) lets you arbitrarily change the consensus rules | 07:34 |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 07:37 | |
| kanzure | we should publicly document the soft-hard fork idea | 07:37 |
| kanzure | which was iirc the super-evil variant of the evil soft-fork idea | 07:38 |
| amiller | i'm not clear at all on the boundaries of the ideas referred to by these names | 07:38 |
| amiller | is an "evil fork" specifically when miners convince everyone to start using anyonecanspend because they commit to a nice new policy, but then they actually just take all the coins? | 07:39 |
| kanzure | 22:30 < gmaxwell> which is this idea we were calling evil forks at the time, and were intentionally not proposing (though they've since been independantly invented twice so I don't see any point in being quiet about them now) | 07:41 |
| kanzure | 22:30 < gmaxwell> which is that you can basically build a soft fork which makes a hardfork extension via an extension block but denies all other transactions. | 07:42 |
| kanzure | 22:31 < gmaxwell> which sort of highlights why at least at the limits softforks are bad too. | 07:42 |
| kanzure | from http://gnusha.org/bitcoin-wizards/2015-06-12.log | 07:42 |
| amiller | hm | 07:42 |
| amiller | ;seen gmaxwell | 07:42 |
| amiller | ok so i guess the "evil" part is that it supresses all other transactions | 07:42 |
| amiller | i dunno, it seems like double-counting in a way | 07:43 |
| kanzure | i think it's ;;seen | 07:43 |
| amiller | if soft-fork is defined by what old, un-upgraded nodes expect, | 07:43 |
| amiller | then suppressing transactions from old nodes should count as 'hard' | 07:43 |
| amiller | ;;seen | 07:43 |
| gribble | (seen [<channel>] <nick>) -- Returns the last time <nick> was seen and what <nick> was last seen saying. <channel> is only necessary if the message isn't sent on the channel itself. <nick> may contain * as a wildcard. | 07:43 |
| amiller | ;;seen gmaxwell | 07:43 |
| gribble | gmaxwell was last seen in #bitcoin-wizards 2 weeks, 2 days, 7 hours, 58 minutes, and 33 seconds ago: <gmaxwell> yea, and 10 layers is a lot, if you're assuming 16 layers of "common data" | 07:43 |
| amiller | likewise you can argue it's impossible to soft-fork to more than 21M because there's no way to convince old un-upgraded nodes to see more than 21M coins | 07:44 |
| kanzure | evil fork requires an extension block commitment, the evil part is that the soft-fork provides a consensus rule that the only transactions in the new block version blocks are extension block commitments and transfers into the extension block | 07:45 |
| amiller | maybe a better definition of soft-fork is about what kinds of service are guaranteed to legacy nodes | 07:46 |
| amiller | for example, receiving finalized payments is a service (and that seems to be what most people have in mind when saying soft-fork) | 07:46 |
| kanzure | re: hard-fork vs soft-fork overview there is https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki | 07:47 |
| -!- nuke1989 [~nuke@178-157-152.dynamic.cyta.gr] has joined #bitcoin-wizards | 07:48 | |
| amiller | increasing max block size would cause old nodes to be on a diverged chain where they're easily double-spent so that's why it's a soft-fork | 07:48 |
| amiller | but as another example, some kinds of apparently-softfork policies break some kinds of legacy service, such as having pre-signed transactions | 07:49 |
| kanzure | hmm actually i am not sure about the details of soft-hard forks | 07:49 |
| amiller | like where you make a "cold-wallet recovery" transaction with a reasonable fee and throw away the key | 07:49 |
| amiller | a change that requires higher fees, or stops eventually prioritizing old txouts, sort of spoils that reasonably expected service | 07:50 |
| -!- ElmerFunk [~Mutter@213.57.66.208] has joined #bitcoin-wizards | 07:52 | |
| -!- MrHodl [~fuc@91.210.105.101] has quit [] | 07:53 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 07:56 | |
| kanzure | also x-posted those hyperlinks about extension block stuff to https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg7mdr | 07:58 |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection] | 08:06 | |
| -!- ElmerFunk [~Mutter@213.57.66.208] has quit [Remote host closed the connection] | 08:11 | |
| kanzure | instagibbs: i agree that we have been slacking on assembling a hard-fork wishlist | 08:32 |
| instagibbs | Open question to all: What are the things we should get around to including to Bitcoin if/when we hardfork? This can include cleanups of Segwit, for example, no-brainers, as well as possibly controversial or unfinished ideas. | 08:33 |
| instagibbs | Bonus points for what the challenges to doing it are, if any. | 08:34 |
| -!- pozitrono [~nu@108.61.166.139] has quit [Ping timeout: 265 seconds] | 08:34 | |
| kanzure | https://en.bitcoin.it/wiki/Hardfork_Wishlist | 08:35 |
| kanzure | https://en.bitcoin.it/wiki/Softfork_wishlist | 08:35 |
| * Taek suffocates under the high-signal scrollback | 08:38 | |
| Taek | <vladzamfir> paul, do you agree that we have a bigger design space, in security-deposit-based PoS than you do in PoW? | 08:38 |
| -!- eightbitcoder [b96c8003@gateway/web/cgi-irc/kiwiirc.com/ip.185.108.128.3] has joined #bitcoin-wizards | 08:38 | |
| Taek | I would argue that a bigger design space is not a good thing, at least, not when it's a less-well-understood design space | 08:39 |
| Taek | means there's more surface area for you to miss something that attackers can take advantage of later | 08:39 |
| Taek | as we're seeing with Bitcoin, even the simple idea behind Bitcoin has a lot of hidden nooks and cranines | 08:39 |
| -!- MrHodl [~fuc@91.210.105.101] has joined #bitcoin-wizards | 08:40 | |
| Taek | .tell bramc I was (independently, believe it or not) working on a closed form solution to selfish mining all day yesterday. I am quite close, have code and everything to produce results | 08:40 |
| yoleaux | Taek: I'll pass your message to bramc. | 08:40 |
| Taek | petertodd: my calculations are actually even more pessimistic than 29% - you missed some optimizations where miners who find 2 blocks before the network finds any can pusure longer private-chains that result in even more orphans for the network, at no risk | 08:41 |
| Taek | .tell bramc I've also got a proposal to make selfish mining significantly harder. Hoping to have something done in a few days. Would be interested in collaborating on a paper if you've got time | 08:42 |
| yoleaux | Taek: I'll pass your message to bramc. | 08:42 |
| tromp | instagibbs: undo relegation of what should be header fields (like extranonce) into coinbase | 08:46 |
| -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 08:49 | |
| -!- coinoperated [~coinopera@70.15.164.106.res-cmts.t132.ptd.net] has joined #bitcoin-wizards | 08:53 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Read error: Connection reset by peer] | 08:54 | |
| kanzure | petertodd: sounds like you are going to be sending an email about a variant of forced soft-forks. is that going to happen soon? i'm trying to decide when to send an email with a handful of links collecting related topics. | 08:54 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 08:54 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 09:04 | |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 09:08 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 265 seconds] | 09:08 | |
| -!- ElmerFunk [~Mutter@dsl212-235-31-225.bb.netvision.net.il] has joined #bitcoin-wizards | 09:09 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 250 seconds] | 09:11 | |
| coinoperated | kanzure, you should start a list of all these links somewhere. perhaps categorized by topic hierarchy. you could give it a catchy name to make it hip with all the kids, something like "woo hoo" | 09:12 |
| kanzure | coinoperated: i use https://github.com/davidlazar/jotmuch | 09:12 |
| kanzure | coinoperated: http://diyhpl.us/~bryan/irc/bitcoin/recent-bitcoin-bookmarks-2015-08-30-125827.yaml | 09:12 |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds] | 09:13 | |
| coinoperated | kanzure, very useful if a bit lacking in purple fonts and superfluous emphatic punctuation | 09:14 |
| -!- ElmerFunk [~Mutter@dsl212-235-31-225.bb.netvision.net.il] has quit [Ping timeout: 240 seconds] | 09:17 | |
| -!- eudoxia [~eudoxia@r167-57-99-48.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 09:21 | |
| -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-wizards | 09:21 | |
| -!- eudoxia [~eudoxia@r167-57-99-48.dialup.adsl.anteldata.net.uy] has quit [Client Quit] | 09:21 | |
| bsm117532 | coinoperated: See also https://8333.info/ and https://github.com/DavidVorick/knosys | 09:25 |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 09:27 | |
| -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has joined #bitcoin-wizards | 09:28 | |
| JackH | WOW, MIT just wiped the floor with their whitepaper | 09:28 |
| JackH | amazing work | 09:28 |
| bsm117532 | JackH: link? | 09:28 |
| kanzure | turn down the hype, geeze | 09:28 |
| kanzure | that multiparty computation was previously posted in here, btw | 09:28 |
| JackH | hehe | 09:29 |
| JackH | would be utterly shocked if it had not | 09:29 |
| bsm117532 | enigma? | 09:29 |
| JackH | here bsm117532 http://enigma.mit.edu/enigma_full.pdf | 09:29 |
| JackH | yes | 09:29 |
| bsm117532 | I know ;-) https://www.youtube.com/watch?v=Z4K_Rn8QWGo | 09:31 |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Read error: Connection reset by peer] | 09:32 | |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 09:33 | |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-wizards | 09:33 | |
| bsm117532 | BTW if anyone is interested, we're looking for people to host future Whitepaper Wednesday journal-club events. I'd really like to have one about ECC encryption, curves, and signatures. I was just reading about Ed225519. Message me privately if you'd like to lead a discussion in NYC, we will host. | 09:34 |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 09:36 | |
| -!- ElmerFunk [~Mutter@dsl212-235-31-225.bb.netvision.net.il] has joined #bitcoin-wizards | 09:36 | |
| -!- ElmerFunk [~Mutter@dsl212-235-31-225.bb.netvision.net.il] has quit [Remote host closed the connection] | 09:37 | |
| -!- frankenmint [~frankenmi@71-222-125-215.ptld.qwest.net] has joined #bitcoin-wizards | 09:38 | |
| -!- kmels [~kmels@120.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 09:39 | |
| -!- brianhoffman [~brianhoff@185.94.28.254] has joined #bitcoin-wizards | 09:41 | |
| amiller | Taek, yoleaux, bramc, selfish mining is not even the optimal attack | 09:42 |
| amiller | you should make sure that whatever defense you make for selfish mining doesn't open up other attacks | 09:42 |
| amiller | look at http://arxiv.org/abs/1507.06183 and https://eprint.iacr.org/2015/796 | 09:42 |
| kanzure | bram has seen your first link, dunno about the second | 09:44 |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 09:50 | |
| coinoperated | bsm117532, thx. 8333.info useful on phone | 09:52 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 09:56 | |
| -!- frankenm_ [~frankenmi@67-5-239-222.ptld.qwest.net] has joined #bitcoin-wizards | 10:13 | |
| JackH | is enigma on github yet | 10:15 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 10:16 | |
| -!- frankenmint [~frankenmi@71-222-125-215.ptld.qwest.net] has quit [Ping timeout: 260 seconds] | 10:16 | |
| -!- jcorgan is now known as jcorgan|away | 10:16 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 10:17 | |
| -!- frankenmint [~frankenmi@67-5-247-11.ptld.qwest.net] has joined #bitcoin-wizards | 10:21 | |
| -!- frankenm_ [~frankenmi@67-5-239-222.ptld.qwest.net] has quit [Ping timeout: 255 seconds] | 10:23 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 10:26 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 10:28 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 10:29 | |
| -!- RedEmerald [~RedEmeral@216.240.130.109] has quit [Changing host] | 10:31 | |
| -!- RedEmerald [~RedEmeral@unaffiliated/redemerald] has joined #bitcoin-wizards | 10:31 | |
| bsm117532 | JackH: Not as far as I know, they haven't released code. | 10:34 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 10:36 | |
| instagibbs | amiller, your title is catchier, so i remembered it :) | 10:37 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 10:42 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit] | 10:45 | |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 10:52 | |
| -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 276 seconds] | 11:04 | |
| -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards | 11:05 | |
| -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has quit [Remote host closed the connection] | 11:05 | |
| Taek | amiller: I chose to ignore combinations of attacks. There are a significant handful of things you could combine to produce some pretty nasty results. | 11:06 |
| Taek | amiller: the solution is to tag 'late' blocks and require that they get more confirmations before switching to mining on them. I don't think there's any clear way to abuse it, because it requires having a block that is late in the first place | 11:07 |
| Taek | Under my proposal, a block would be considered 'late' if it appears >120 seconds after another block with the same parent | 11:07 |
| Taek | I'm not done with the solution, but it appears to bump the required hashrate for selfish mining from ~28% to ~42%, which imho is very significant | 11:08 |
| bsm117532 | Sounds like it opens an attack which is Sybil + delayed relaying. | 11:08 |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 255 seconds] | 11:09 | |
| -!- wallet42 [~wallet42@i121-117-83-230.s41.a013.ap.plala.or.jp] has joined #bitcoin-wizards | 11:09 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds] | 11:09 | |
| Taek | bsm117532: it's expensive to reveal a late block. If you are announcing a block late, it means that it's already got a substantially reduced chance of winning a race, because by necessity there's already another block that's had at least 120 seconds to propagate | 11:10 |
| Taek | *by definition | 11:10 |
| bsm117532 | I'm saying the attacker's nodes delay the relay. The miner announces promptly. | 11:10 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 11:11 | |
| Taek | I believe that's similar to the eclispse attack, and is not exacerbated by miners tagging 'late' blocks. An attacker who is performing succesful delayed relaying is going to have more powerful attacks available than those enabled by late blocks | 11:12 |
| Taek | I will try to have a more formal explanation ready today or tomorrow, but I do believe that all types of attacks which might leverage late blocks already have more powerful options available to them | 11:12 |
| bsm117532 | Yes you'd have to achieve an eclipse attack essentially, so that your delayed relay is presented first to a victim's node. | 11:13 |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 11:20 | |
| Taek | right, and by the time you've achieved an eclipse attack the range of options available to you are much more diabolical than anything you can leverage out of the late block specifically - I do need to read the rest of the stubborn mining paper though | 11:27 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] | 11:28 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 11:30 | |
| -!- psztorc [ac38169c@gateway/web/freenode/ip.172.56.22.156] has joined #bitcoin-wizards | 11:32 | |
| psztorc | Hello everyone, what remains to be done for the 'canonical assembly of blocks', so as to make best use of the IBLT propagation idea? | 11:35 |
| psztorc | I know that Kristov Atlas did part of this -the inputs and output ordering- for a privacy reason. | 11:35 |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 11:35 | |
| -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Ping timeout: 252 seconds] | 11:36 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 11:37 | |
| psztorc | I thought that that was within each transaction, though. Not across all transactions in a block. | 11:38 |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 11:38 | |
| kanzure | psztorc: i'm confused what you are asking about. which IBLT things have you seen lately? then maybe i can fill in some gaps if any. | 11:40 |
| -!- bitdevsnyc [bitdevsnyc@gateway/vpn/mullvad/x-jazerbuxzhposncl] has joined #bitcoin-wizards | 11:40 | |
| gavinandresen | psztorc: you mean canonical ordering of transactions? As far as I know, nobody is working on that. Easiest (but not fastest) implementation would be a sorting pass at the end of CreateNewBlock() | 11:43 |
| psztorc | gavinandresen: yes that's what I meant | 11:43 |
| psztorc | That is the last piece, after which IBLT will work better, it seems? | 11:43 |
| bsm117532 | Maybe better to keep the mempool sorted? | 11:44 |
| kanzure | bramc was doing some canonical ordering regarding utxo merkle set stuff | 11:44 |
| kanzure | mempool sorting was recently recommended to be in a fee per byte ordering, i think this was mentioned on the mailing list(?) | 11:44 |
| psztorc | I was thinking precisely that. | 11:44 |
| kanzure | http://gnusha.org/bitcoin-wizards/2015-12-22.log | 11:45 |
| kanzure | search for fee-for-byte in that log file | 11:45 |
| psztorc | It would allow SPV clients to learn about the fees accepted by miners, specifically the marginally-acceptable fee (min fee/kb). | 11:45 |
| psztorc | Well, that's why I asked, because it seems that the sort would be arbitrary. But this would actually allow it to be useful. | 11:45 |
| instagibbs | im not seeing how an SPV client would know feerate unless it had access to previous transactions. possibly overthinking | 11:47 |
| psztorc | Because you can just see how many times you've gone 'left' (or whatever) in the merkle tree. If you go all the way left you get the coinbase, which reveals total fees. You have total tx quantity from the header. | 11:48 |
| psztorc | While you're already all left, you might as well pick up the 'most barely acceptable transaction'. | 11:49 |
| psztorc | You now know the average fee, and the least-acceptable fee, for a given block. | 11:49 |
| gavinandresen | I asked Mike if sorting by fee would be useful to SPV clients, he was skeptical. Too complicated ... your high-fee transaction might happen to get sorted to the right of the merkle tree because it depends on transactions earlier in the block | 11:49 |
| psztorc | Then you can query other things. | 11:49 |
| dgenr8 | mempool is now sorted multiple ways, and more indexes could easily be added | 11:49 |
| instagibbs | psztorc, true the spv client could just ask for that min transaction | 11:51 |
| -!- jcorgan|away is now known as jcorgan | 11:51 | |
| psztorc | gavinandresen: It seems strange that the order would matter for something that happens at the same time, does that really matter? | 11:51 |
| instagibbs | psztorc, that's how it's coded now | 11:51 |
| psztorc | Yes, the difference is that the SPV client can *know* that it got the min transaction. | 11:51 |
| instagibbs | you linearly scan transactions for validity | 11:52 |
| psztorc | I see, thanks. | 11:52 |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 11:53 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 11:53 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Client Quit] | 11:53 | |
| psztorc | Still, I think it is worth it, because it would be hard to game this system when SPV clients can just start sampling randomly in the left half of the tree to learn about the distribution of fees there. | 11:55 |
| instagibbs | random sampling certainly makes more sense | 11:55 |
| psztorc | Pretty safe way to automate fee-minimization, I think. | 11:55 |
| instagibbs | you can take that number as a seed then do whatever else you want. Lowball to see if miners would include anyways and to discourage lying, etc. | 11:56 |
| psztorc | I mean, just by going left to the coinbase, you have the average, and the min, which are the two most ideal fee-parameters. | 11:57 |
| kanzure | http://diyhpl.us/wiki/transcripts/scalingbitcoin/transaction-fee-estimation/ | 11:57 |
| kanzure | http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011685.html | 11:57 |
| kanzure | https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb | 11:57 |
| psztorc | I saw bram's thing, I thought it was good. But did he discuss 'how users become aware of fees'? I thought not. | 11:58 |
| instagibbs | psztorc, like gavinandresen said, miners may game this or include really low stuff to pay for higher stuff | 11:59 |
| instagibbs | hence random sampling | 11:59 |
| gavinandresen | ... better/simpler to commit to fees as part of the segwitness data. | 12:00 |
| psztorc | Well I would want them to random sample something that was sorted, so they'd always be 'lower than average' but 'was accepted by a block'. | 12:00 |
| psztorc | Both of those true. | 12:00 |
| psztorc | This would safely glide fees down. | 12:00 |
| psztorc | Otherwise it is just 'average fee' (which you can already get with division). | 12:01 |
| psztorc | - some random number. | 12:01 |
| psztorc | Fee(block) = average_fee - alpha | 12:01 |
| psztorc | which I don't like. | 12:01 |
| psztorc | (By 'random number' I meant a disparaging 'arbitrary static parameter'). | 12:02 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 12:03 | |
| psztorc | I suppose, with pure random sampling, you can do something similar, by simply sampling and then taking the 25% percentile. This takes much more samples but I guess it doesn't really matter. | 12:06 |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-wizards | 12:08 | |
| instagibbs | I'd want to plot a feerate curve anyways, heh | 12:08 |
| psztorc | I won't deny that this is partially out of a arbitrary and emotional desire to see The Supply Curve in the blocks themselves. | 12:09 |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 12:09 | |
| psztorc | [14:59] <instagibbs> psztorc, like gavinandresen said, miners may game this or include really low stuff to pay for higher stuff | 12:12 |
| -!- wallet42 [~wallet42@i121-117-83-230.s41.a013.ap.plala.or.jp] has quit [Ping timeout: 256 seconds] | 12:12 | |
| psztorc | Are you talking about the way it is done now? | 12:12 |
| psztorc | Because the way it is done now, the miner can stuff the block with a high n of high fee transactions to make it look like fees are high. | 12:14 |
| -!- pozitron [~nu@172.98.67.34] has joined #bitcoin-wizards | 12:14 | |
| psztorc | This would trick people who don't sample enough, whereas sampling from the lower half of fee-per-kb sort would always work, even with only 3 or 4 samples. | 12:14 |
| psztorc | In fact, if miners include >50% of transactions as high fee to themselves, this produces different effects in each sort: the traditional way, each sample is likely to be high fee, but in the supply curve lower half way, each sample is likely to be not-from-a-miner. | 12:16 |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-xzdecvegrdkxucso] has joined #bitcoin-wizards | 12:17 | |
| instagibbs | We are on the same page. | 12:18 |
| -!- bitdevsn_ [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards | 12:20 | |
| -!- bitdevsnyc [bitdevsnyc@gateway/vpn/mullvad/x-jazerbuxzhposncl] has quit [Ping timeout: 255 seconds] | 12:24 | |
| -!- dEBRUYNE__ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 250 seconds] | 12:26 | |
| psztorc | Ok, how's this idea: they are all sorted by fee-per-kb, but if anyone double-transacts within a block, these go directly to the right of their parent. | 12:32 |
| psztorc | Optionally, force any such children to have the exact same fee/kb as their parents, but I don't think that's required. | 12:32 |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [] | 12:33 | |
| psztorc | The result is all of the benefits of both, the supply curve is just distorted by these, but if you sample from the lower half, it can only be gamed to make it look as though transactions are much lower. | 12:33 |
| psztorc | Which is not what miners would want. | 12:33 |
| psztorc | Oh wait, I don't think that's right... | 12:34 |
| psztorc | Just put in on high-fee transaction and then a long sequence of low-fees, to crowd the right side. | 12:35 |
| psztorc | Oops. | 12:35 |
| psztorc | I'll think about it some more I guess. | 12:35 |
| dgenr8 | psztorc: an index that includes only child fee, but all parent sizes, in the calc is suitably punishing to dependencies | 12:35 |
| psztorc | Ah yes, it interacts with child-pays-for-parent, very logical. | 12:36 |
| psztorc | But the spv client probably can't tell which transactions are part of (?) single-block families (or whatever). | 12:37 |
| psztorc | So I would get my supply curve but not really be able to use it for anything. | 12:39 |
| psztorc | Unless there were extra stuff to flag tx-families. | 12:39 |
| -!- eightbitcoder [b96c8003@gateway/web/cgi-irc/kiwiirc.com/ip.185.108.128.3] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 12:39 | |
| dgenr8 | i'm actually working on that. not sure when it might get into a release of some codebsae or other | 12:40 |
| psztorc | Cool. | 12:43 |
| psztorc | Well that should be good enough, right, each user can get a "lower-than-average, but acceptable" value, then you just slowly increase this "bid" until a miner includes it. | 12:46 |
| dgenr8 | let's go to #bitcoin-dev | 12:49 |
| dgenr8 | psztorc: i'm not totally sure what you're doing. looking for historical fee data (per block?) or currently-being assembled estimates | 12:50 |
| -!- se3000 [~SE@38.125.163.60] has joined #bitcoin-wizards | 12:54 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 12:55 | |
| -!- Myagui [Myagui@shell.xshellz.com] has quit [Ping timeout: 260 seconds] | 12:59 | |
| -!- Myagui [Myagui@shell.xshellz.com] has joined #bitcoin-wizards | 12:59 | |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has quit [Ping timeout: 240 seconds] | 13:00 | |
| -!- MrHodl [~fuc@91.210.105.101] has quit [Ping timeout: 240 seconds] | 13:00 | |
| -!- bitdevsnyc [~bitdevsny@173.254.196.27] has joined #bitcoin-wizards | 13:01 | |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 13:02 | |
| -!- bitdevsn_ [~bitdevsny@cpe-158-222-198-108.nyc.res.rr.com] has quit [Ping timeout: 255 seconds] | 13:04 | |
| -!- JayDugger [~jwdugger@108.19.186.58] has quit [Ping timeout: 276 seconds] | 13:04 | |
| -!- frankenmint [~frankenmi@67-5-247-11.ptld.qwest.net] has quit [Remote host closed the connection] | 13:17 | |
| -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [Read error: Connection reset by peer] | 13:23 | |
| -!- rustyn [~rustyn@unaffiliated/rustyn] has joined #bitcoin-wizards | 13:24 | |
| -!- psztorc [ac38169c@gateway/web/freenode/ip.172.56.22.156] has quit [Ping timeout: 252 seconds] | 13:36 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 13:40 | |
| -!- eudoxia [~eudoxia@r186-54-159-21.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 13:41 | |
| -!- frankenmint [~frankenmi@67-5-247-11.ptld.qwest.net] has joined #bitcoin-wizards | 13:42 | |
| -!- phy1729 [~phy1729@unaffiliated/phy1729] has quit [Changing host] | 13:43 | |
| -!- phy1729 [~phy1729@freenode/staff/phy1729] has joined #bitcoin-wizards | 13:43 | |
| -!- bitdevsnyc [~bitdevsny@173.254.196.27] has quit [] | 13:45 | |
| -!- pozitron [~nu@172.98.67.34] has quit [Ping timeout: 260 seconds] | 13:45 | |
| Taek | I think gmaxwell has discussed similar things in the past, but it would be cool to have an OP_REQUIRE which mandated that a certain transaction or set of transactions appeared in the blockchain in order for your txn to be valid. If preconsensus becomes strong enough, you could commit to clusters of transactions with a single hash, and then if each of those txns contained their own OP_REQUIRE codes, you'd end up with an entire chain of valid | 13:47 |
| Taek | transacions which work together to fight censorship | 13:47 |
| Taek | I was thinking about this because I've become more aware of the fact that miners are untrusted entities | 13:48 |
| Taek | nobody chooses them, and nobody controls their behavior, except by incentives which they may have regulatory reason to ignore | 13:48 |
| Taek | I though an OP_REQUIRE might make a dent in their power by having everything depend on everything else in a way that makes it very difficult for miners to ignore indivual transactions - in doing so you end up needing to ignore entire clusters | 13:49 |
| -!- qadaemon [~textual@12.33.253.130] has quit [Ping timeout: 240 seconds] | 13:51 | |
| instagibbs | so basically the relationship is quite like using utxos, but not consuming them? Trying to reason about pitfalls. | 13:51 |
| Taek | yeah. You end up with parent transactions that are really only spiritual | 13:52 |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 13:53 | |
| instagibbs | like a spirit animal, nice | 13:58 |
| -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 260 seconds] | 13:59 | |
| -!- psztorc [4575fa8d@gateway/web/freenode/ip.69.117.250.141] has joined #bitcoin-wizards | 13:59 | |
| -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards | 14:00 | |
| bramc | I saw Taek sent messages for me via gribble in the log but gribble didn't send them | 14:02 |
| yoleaux | 16:40Z <Taek> bramc: I was (independently, believe it or not) working on a closed form solution to selfish mining all day yesterday. I am quite close, have code and everything to produce results | 14:02 |
| yoleaux | 16:42Z <Taek> bramc: I've also got a proposal to make selfish mining significantly harder. Hoping to have something done in a few days. Would be interested in collaborating on a paper if you've got time | 14:02 |
| Taek | yoleaux doesn't print the messages until you speak, I'm not sure if there's a more preferable way to do it | 14:04 |
| -!- Guest7736 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-wizards | 14:04 | |
| bsm117532 | What's this solution to selfish mining? | 14:05 |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 14:06 | |
| bramc | Taek, What I did yesterday was mostly reinvent what's in the Mining is not Enough paper, but I'm curious what your idea is for a countermeasure | 14:06 |
| bramc | (the countermeasure suggested in that paper is busted, which you probably already knew) | 14:06 |
| Taek | bramc: my proposal is to mark blocks as 'late' if they appear more than 120 seconds after a block with the same parent. Chains built on top of late blocks need to be 2 blocks ahead instead of the usual 1 block ahead to be accepted as the longest chain | 14:08 |
| Taek | the reasoning is that there's no honest situation in which a block is going to appear 120 seconds behind a sibling block. Any honest miner would have stopped mining on the parent long before that | 14:09 |
| bramc | Taek, Peers are free to do that based on their own local info although gossip info about lateness is of course not to be trusted | 14:10 |
| -!- adam3us [~Adium@141.8.72.43] has joined #bitcoin-wizards | 14:11 | |
| bramc | I'm not sure that helps though, because a selfish miner can always publish their own siblings as soon as the other one is published | 14:12 |
| phantomcircuit | Taek, that gives a large advantage to miners able to distribute blocks rapidly outside of the p2p network | 14:12 |
| phantomcircuit | maybe that's worth it, maybe it's not | 14:13 |
| bramc | Most of the papers assume some amount of attack along those lines, that an attacker is already set up to hit some fraction of all peers with their own block in response to a sibling being published | 14:14 |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has quit [Ping timeout: 240 seconds] | 14:15 | |
| -!- Alanius [~alan@flyingarm.bar] has quit [Ping timeout: 255 seconds] | 14:16 | |
| bramc | Hence my suggestion that when two siblings arrive at close to the same time the one which has a better weak references chain should win | 14:16 |
| Taek | ah yeah, miner could publish a block late enough that nobody mines on it but early enough that it's before the 120 second window | 14:17 |
| Taek | phantomcircuit: I'm not sure what advantage you are talking about? As long as everyone is seeing things within 120 seconds it shouldn't advantage anyone | 14:18 |
| -!- Alanius [~alan@flyingarm.bar] has joined #bitcoin-wizards | 14:19 | |
| bramc | I'm increasingly becoming convinced that having explicit weak backlinks is a good idea. There are three potential things: A weak link to a previous block, a weak link to the fully actualized transaction set for this block, and a weak link to the set of transactions which didn't make the cut | 14:20 |
| bsm117532 | I'll just mention again that the "right" answer to this question is to allow sibling blocks to be non-conflicting by allowing the next block to have multiple parents. | 14:21 |
| bramc | bsm117532 That solution makes selfish mining attacks stronger | 14:21 |
| bsm117532 | That is false. | 14:21 |
| bsm117532 | bramc: That's only under the "Inclusive blockchain" proposal, which additionally adds GHOST. It's GHOST that makes selfish mining stronger. | 14:22 |
| bramc | You can withhold your own block, and then when someone else publishes a block publish your own block in response, and still get credit for it | 14:22 |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 265 seconds] | 14:23 | |
| phantomcircuit | Taek, without getting into too much detail, an adversary can delay the propagation of blocks well beyond 120 seconds | 14:23 |
| bsm117532 | See my explicit incentivization formula from my talk. By computing the "cohort" of each block and using it in the reward formula, you can remove that attack. | 14:23 |
| bramc | In the case of a weak backlink, there are two possible meanings for it: It can either refer to the actual transaction set of the previous block, or the fully actualized set, or let you specify. Probably best to let the user specify. | 14:23 |
| -!- Alanius [~alan@flyingarm.bar] has quit [Ping timeout: 255 seconds] | 14:24 | |
| bsm117532 | bramc: There are a lot of choices beyond simply allowing blocks to have multiple parents. | 14:24 |
| bramc | bsm117532 I haven't slogged through all the details of your talk but my intuition is that you can't really solve the problem you can only push it around | 14:24 |
| Taek | phantomcircuit: if that's true, it's already a significant problem. Delaying the propagation of blocks to certain miners guarantees that those miners are going to have insurmountable revenue disadvantages due to high orphan rates | 14:24 |
| -!- Alanius [~alan@flyingarm.bar] has joined #bitcoin-wizards | 14:24 | |
| bsm117532 | bramc: the problem is fundamental and due to the size of the Earth and speed of light. What you CAN do is make sibling blocks not punish one miner or the other. | 14:25 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 14:25 | |
| bsm117532 | It's the ability of one miner to deny another profit that makes selfish mining work. That must be removed. | 14:25 |
| bramc | bsm117532 I'm much more worried about selfish mining than the natural orphan rate | 14:25 |
| bsm117532 | I'd agree bramc. | 14:26 |
| bramc | But when you give rewards to old blocks you also lessen the incentive to mine off the latest block | 14:26 |
| Taek | the core of the selfish mining attack involves giving the network a higher orphan rate than yourself. If you can make it so that there's minimal cost to producing an orphan, you stop the selfish mining attack | 14:26 |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has joined #bitcoin-wizards | 14:26 | |
| phantomcircuit | Taek, it's difficult to delay propagation of blocks to specific recipients, but easy to delay to most of the network | 14:26 |
| Taek | though I'm not convinced that you don't open up other, bigger problems | 14:26 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 14:27 | |
| bsm117532 | Taek: yes. I'm trying to make the cost of producing a sibling zero. | 14:27 |
| phantomcircuit | obviously im not going to describe how to do this, which is going to make it harder for you to think up countermeasures :P | 14:27 |
| Taek | bsm117532: that's also bad though, you need incentives to keep the network moving forward. Someone who is mining on a late block should have some sort of penalty. | 14:27 |
| bsm117532 | Taek: That is present in my incentive formula. | 14:28 |
| Taek | phantomcircuit: does it involve network code, or does it involve speficially constructed blocks? I don't need to know more than that for what I'm working on right now | 14:28 |
| bsm117532 | I'm very wary of "solving" this problem with arbitrary timing heuristics and band-aids, rather than pursuing a more fundamental solution, as this is a fundamental problem due to physics and a linked list being an over-simplified data structure. | 14:29 |
| bramc | bsm117532 Trying to give people credit for orphan blocks and trying to penalize people for mining old blocks seem to be directly contradictory goals | 14:30 |
| phantomcircuit | Taek, the former | 14:31 |
| Taek | bsm117532: changing the fundamentals is opening a whole new can of worms. The fundamentals as they exist are pretty well understood, if not pretty. I, and likely most of the bitcoin-core developers, would be slow to switch to any paradigm that changes the 6-year-proven blockchain. Kind of how cryptographers don't accept a new signature algorithm until the paradigms are very well explored | 14:31 |
| bsm117532 | bramc: With a graph structure you have more power. The former is a "sibling", the latter is measured using the "cohort". For very small graphs they're the same, but for larger graphs they're not. | 14:31 |
| bsm117532 | Taek: I'm well aware of opening a can of worms and it will take time to prove. But let's just keep in mind that the true solution is allowing parallel blocks, and not invent heuristics in the meantime which make a better solution difficult or impossible. | 14:32 |
| bsm117532 | (I'm not saying don't invent heuristics, just don't invent heuristics which make a better solution impossible) ;-) | 14:33 |
| bramc | bsm117532 There's also the question of which side wins in terms of its transactions going through, especially when fees are all transaction fees and not mining rewards, so a shorter blockchain may have better rewards | 14:33 |
| psztorc | What exactly are you trying to accomplish with this crusade against selfish mining? | 14:33 |
| bramc | psztorc, Selfish mining is a very real threat to the network as a whole, it could cause massive pooling and reorgs if it started happening at scale | 14:34 |
| psztorc | A linear relationship between hashrate and revenue? | 14:34 |
| Taek | psztorc: a variety of adversarial mining behaviors make it possible to impact competitor profitability with less than 30% of the hashrate. If you are doing multiple attacks at the same time, you don't need much hashrate at all | 14:34 |
| psztorc | Imagine that all of mining ends up in two pools, each with 50% of the hashrate. | 14:35 |
| psztorc | Should they selfish mine, yes or no? | 14:35 |
| psztorc | Assume they are risk averse. | 14:35 |
| bsm117532 | The larger goal is the decentralization of mining. | 14:36 |
| Taek | as long as only one participates in selfish mining, that one will be able to increase their revenue substantially | 14:36 |
| psztorc | So, you would say "yes"? | 14:36 |
| psztorc | Both should selfish mine? | 14:36 |
| Taek | I'm not sure what would happen if both started selfish mining | 14:36 |
| Taek | but if a new miner appeared with 5% hashrate, it wouldn't be able to engage in selfish mining, and would be driven off | 14:37 |
| psztorc | Imagine you are in one pool, and you are selfish mining. | 14:37 |
| bsm117532 | psztorc: The incentives of the bitcoin system are not currently compatible with correct operation of the system. It's a rather fundamental problem to solve. | 14:37 |
| psztorc | We'll see. | 14:37 |
| psztorc | You are in a 50% pool which is selfish mining. | 14:37 |
| psztorc | You have found two blocks against the latest public chain so far. | 14:37 |
| psztorc | What should you do? | 14:37 |
| Taek | It's extremely important to me that a 1% miner can have, in adversarial conditions, as much profitability as a rational, selfish, stubborn, etc. miner with 33% hashrate and a whole boatload of resources to dedicate towards network based optimizations and attacks | 14:38 |
| psztorc | I intend to demonstrate that he can, Taek, if you would answer my questions. | 14:38 |
| Taek | ok | 14:38 |
| bsm117532 | psztorc: Are you going to argue that everyone should selfish mine, and that solves the problem? | 14:38 |
| Taek | what do you mean by 'against the latest public chain'? | 14:39 |
| psztorc | I am going to argue that anyone *has the option* to selfish mine, which, eventually, solves the problem. | 14:39 |
| bsm117532 | psztorc: Only at the expense of network speed. | 14:39 |
| Taek | psztorc: the problem there is that you can't profitably engage in selfish mining until you hit 29% hashrate. Smaller miners don't have selfish mining as an option available to them, and the more hashrate you have the more effective your selfish mining is | 14:40 |
| psztorc | Forgive me, but does the phrase "off path reasoning" mean anything to you? | 14:40 |
| bsm117532 | psztorc: If everyone selfish mines, the orphan rate goes way up, and the network is way slower. | 14:40 |
| psztorc | Ah, I thought not. | 14:40 |
| psztorc | Anyway, back to Taek. | 14:40 |
| bramc | psztorc, If a selfish miner gets ahead by two block they generally continue to hold onto and build their local chain and if the public network gets within one they publish the entirety of their private chain thus eclipsing the public network | 14:40 |
| psztorc | By 'latest public chain' I mean that there is a publicly known block to everyone, call it the genesis block for all I care. Everyone has it at t=0. | 14:41 |
| bramc | bsm117532 The interactions between two selfish miners and the rest of the network are... interesting. I don't think that's been evaluated properly. | 14:41 |
| psztorc | Does that make sense? It is just the starting block. | 14:42 |
| bsm117532 | bramc: I'd rather fix the problem than analyze this broken incentive system... | 14:42 |
| Taek | psztorc: If I am a miner with 50% hashrate, and the latest public chain is 2 blocks behind my private chain, I don't publish until the latest public chain is within 1 block of my private chain | 14:42 |
| psztorc | Ok, now imagine you've found a third block. Still no word from the other mining pool. | 14:43 |
| psztorc | And remember I said to assume the miners are risk averse because they are. | 14:43 |
| Taek | If I know that I've got even slightly more hashrate, it won't bother me | 14:43 |
| Taek | the longer I don't hear from them, the further my own lead | 14:43 |
| psztorc | You have exactly the same hashrate. | 14:44 |
| psztorc | As far as you know, anyway. | 14:44 |
| -!- Alanius [~alan@flyingarm.bar] has quit [Ping timeout: 255 seconds] | 14:44 | |
| psztorc | Maybe you think you secretly have more, but, then, maybe the other pool is tricking you. | 14:44 |
| Taek | in that case I'm not sure what the optimal strategy would be, but selfish mining by both parties would cause a divergent network | 14:44 |
| Taek | at some point I'd publish, just to get the rest of the nodes to where I am | 14:45 |
| Taek | maybe every 6 blocks or so | 14:45 |
| bramc | bsm117532 It seems your system, assuming it works, is very all or nothing: A simplified scheme which only allows siblings to be joined makes the problem worse | 14:45 |
| psztorc | There we go.... | 14:45 |
| Taek | psztorc: ok, but what is the point? | 14:45 |
| Taek | it's a highly contrived example which doesn't generalize to how mining works in the full ecosystem | 14:45 |
| psztorc | Last point: assume that you have the ability, somehow, to learn how many blocks the other pool has. | 14:46 |
| -!- binary01 [~binary01@ool-457c7178.dyn.optonline.net] has joined #bitcoin-wizards | 14:46 | |
| bsm117532 | bramc: I'd agree with that, a new incentive formula is required as well. But that basically goes without saying if you're going to allow two causally-disconnected miners to both be compensated. | 14:46 |
| bramc | It's a good idea when you're ahead by 3 to publish your own first block | 14:47 |
| bsm117532 | bramc: This comes down to calculating compensation after the state of the chain can be seen by all miners (e.g. 100 blocks later), rather than allowing miners to write coinbases for themselves. | 14:47 |
| bsm117532 | It's allowing miners to write their own coinbases, and the ensuing incompatibility of them, that causes miners to be able to deny each other profit, and enables selfish mining. | 14:47 |
| Taek | bramc: yeah. my proposed solution is broken, hadn't considered miners would only publish part of their private chain. Using weak blocks seems like a good direction, but is going to require an entire weak block infrastructure | 14:48 |
| bsm117532 | Perhaps a much simpler fix is to simply calculate coinbase rewards 100 blocks later, when everyone can see what happened with orphans. I discussed this with sipa a while back and he was receptive to the idea. | 14:48 |
| bramc | bsm117532 I understand a bit better what your thinking is now, but I'd need to understand your whole idea a lot better and spend a fair amount of time thinking about it and hear feedback from others who had done the same before having confidence in it | 14:49 |
| -!- Alanius [~alan@flyingarm.bar] has joined #bitcoin-wizards | 14:50 | |
| bramc | bsm117532 In the meantime we're continuing to do straightforward hacky fixes with the tools at hand | 14:50 |
| bsm117532 | bramc: Paper coming. I still hope to make ledgerjournal.org's Dec 31 call for papers. | 14:50 |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has quit [Read error: Connection reset by peer] | 14:50 | |
| Taek | psztorc: I'm not sure if you had more to add after your last point, but if I knew how many blocks the other pool had, I'd publish any time they caught up enough to threaten my lead. I'd also publish any time I was behind. | 14:50 |
| psztorc | Yes, exactly. | 14:51 |
| bramc | Taek, Weak blocks infrastructure is being built for its own reasons, might as well add in selfish mining defense as a bonus while we're at it | 14:51 |
| psztorc | The result is that mining is exactly the same as it is now, only riskier and with ~half the difficulty. | 14:51 |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has joined #bitcoin-wizards | 14:51 | |
| psztorc | Smaller miners are just as valueable as big miners, because anyone with a coalition of >50% is in charge. | 14:52 |
| bramc | Taek, There's never any downside to publishing the blocks more than two back from your own tip | 14:52 |
| psztorc | The concept of selfish mining makes no difference whatsoever, because the hashing power is homogenous. | 14:52 |
| Taek | psztorc: yeah but also completely hostile to anybody not participating in either of the two pools. The two pools might be hostile towards eachother, but at least they don't need to fear any small competition. Being competitive with them would require getting to the same hashrate as them. | 14:52 |
| psztorc | If anything, a market for hashrate would help. | 14:52 |
| kanzure | bsm117532: wouldn't it make more sense to have your paper reviewed prior to their deadline? | 14:53 |
| psztorc | Yes, they would all have to participate, but not at any disadvantage. | 14:53 |
| bsm117532 | kanzure: A call for papers is a submission deadline. Then they send it to reviewers... | 14:53 |
| psztorc | No no no these pools will be very fearful of competition...the rival pool can crush them with 55%. | 14:54 |
| Taek | bramc: I disagree. If I'm 100 blocks ahead, but have 10% hashrate, it's in my best interest not to publish *any* of them. I can get 10 more blocks in the time that it's going to take the network to catch up - if I published my previous 98 the network would catch up in only 2 blocks | 14:54 |
| Taek | highly contrived, but proves a point | 14:54 |
| Taek | psztorc: yes but not with 5% | 14:55 |
| phantomcircuit | Taek, but you dont know if other miners with >10% are also 100 blocks ahead | 14:55 |
| bsm117532 | Previous conversation about calculating coinbases 100 blocks later is here: http://gnusha.org/bitcoin-wizards/2015-11-30.log at 07:38 | 14:55 |
| bramc | Taek, Oh right, that's true. You should publish at least up to the point where you're one behind the public chain, or maybe tied with it. Ironically in that case you specifically want your own chain to fail in a test between siblings | 14:55 |
| psztorc | The 49% pool will pay almost anything to get a new 6%. | 14:55 |
| Taek | phantomcircuit: yeah, I have been assuming that the rest of the network is *not* engaging in selfish mining, something I could probably measure | 14:55 |
| psztorc | They get zero otherwise, they can off the 6% the entire revenue stream - epsilon. | 14:55 |
| psztorc | offer* | 14:56 |
| phantomcircuit | Taek, it becomes extremely difficult to model if you stop assuming that | 14:56 |
| psztorc | Selfish mining is very interesting, but the fundamentals are very clear: the hashing power is homogenous, so the game is symmetric. 51% always wins. | 14:56 |
| kanzure | bsm117532: yes, good point, you said call for papers. ok. | 14:56 |
| phantomcircuit | Taek, realistically if a major pool is selfish mining you should expect everybody to respond to that | 14:56 |
| psztorc | The fact that "Strategy X is better" only matters if "some people can't do Strategy X". | 14:57 |
| Taek | phantomcircuit: would you at least agree that if some subset of miners are engaging in selfish mining, it becomes very difficult for low-hashrate miners to compete? I do believe that much is true | 14:57 |
| psztorc | That is not the case, so the fact that selfish mining is better does not matter. | 14:57 |
| Taek | hmm | 14:57 |
| psztorc | Asymmetric dual selfish mining is not in strategic equilibrium, so it is eliminated. | 14:58 |
| phantomcircuit | Taek, im not sure that's actually true if there are two roughly equal sized pools selfish mining | 14:58 |
| phantomcircuit | indeed they might just increase their orphan rate giving smaller pools an advantage | 14:58 |
| phantomcircuit | but i honestly do not know (and dont think anybody has modeled this) | 14:58 |
| psztorc | Dual selfish mining is riskier than plural selfish mining, so it is eliminated. | 14:58 |
| bsm117532 | FWIW I'd avocate: calculate coinbases 100 blocks later, and assign a 25 BTC coin creation to the miners of ALL valid blocks (including orphans) It doesn't solve the problem with tx fees and orphans (that requires a DAG), but solves the dominant economic problem for miners/selfish mining right now. | 14:59 |
| bramc | psztorc, That... makes no sense | 14:59 |
| Taek | ok. I can't say I understand very well what happens when everyone starts engaging in selfish mining, except that I know that when nobody is engaging in selfish mining, it's not profitable below 25% hashrate (unless you start using other attacks) | 14:59 |
| bsm117532 | It removes the incentive to withhold blocks. | 14:59 |
| psztorc | bramc: What specifically do you not agree with? | 15:00 |
| bramc | bsm117532 It also causes there to be very little incentive to move the blockchain forwards | 15:01 |
| bsm117532 | Eh, I withdraw that statement. It make mining double spends way more profitable. | 15:01 |
| bramc | psztorc, Selfish miners won't magically avoid having two of them just because it's a mess. | 15:01 |
| -!- jlrubin [~jlrubin@mass-toolpike.mit.edu] has quit [Quit: Lost terminal] | 15:02 | |
| psztorc | How do you explain the current mining environment? | 15:02 |
| psztorc | If selfish mining gives a superlinear advantage, there should be two (or one) pools. | 15:02 |
| Taek | psztorc: none of the existing pools have enough hashrate to be engaging in selfish mining | 15:03 |
| bsm117532 | bramc: People keep repeating this weird idea that miners would only mine on their own blocks (in a DAG or blockchain) but that makes no sense because ALL miners will mine on top of the largest cumulative work. So you have a natural incentive to publish your block quickly in most circumstances because it gets *other* miners to mine on your block. | 15:03 |
| Taek | also, most of the large pools are very benevolent. It seems today that our miners are largely altruistic, and would not engage in network-toxic behaviors. No guarantees that it will last, but it's nice to have for the time being | 15:03 |
| bramc | bsm117532 Thats the case now but if you make it so you can get credit anyway that incentive is dramatically lessened | 15:03 |
| psztorc | Taek: Firstly I don't think that's accurate. But it doesn't matter -- why don't they just form bigger pools (if it is more profitable)? | 15:03 |
| psztorc | The one paper said 25% was enough. | 15:04 |
| psztorc | What is the difference between 'benevolent' and 'selfish', if you assume that is is possible that my theory is correct? | 15:05 |
| Taek | psztorc: https://blockchain.info/pools - biggest pool is at 24%. People get very unhappy when pools get close to 50%, and those pools tend to start losing hashrate quickly | 15:05 |
| bsm117532 | bramc: that's because you're calculating the cumulative work wrong: it's not the "height" anymore, it's the total number of ancestor blocks. | 15:05 |
| bsm117532 | (assuming constant difficulty target | 15:05 |
| psztorc | Taek: ok but that doesn't answer my question -- if they are profitable, why isn't this being done? | 15:05 |
| bramc | Taek, They seem to have a gentleman's agreement not to mess things up. You can get away with that when there are small numbers of them, and when there are large numbers they can't collude. Having 100 miners each at 1% might be a lot more painful. | 15:06 |
| Taek | bramc: you think having 100 miners at 1% would be painful? To me it's closer to the ideal situation. | 15:07 |
| psztorc | What is the difference between "gentleman's agreement" and "profit maximizing", if we assume a negative exchange rate reaction to 'reports of an ability to slow network speed'? | 15:07 |
| psztorc | (aka 'selfish mining'). | 15:07 |
| Taek | well, the current gentlemans agreement does seem to be profit-maximizing behavior. At the very least it's causing any alarm bells that would be ringing to be quieter. But every individual has different utility functions, I don't think it's reasonable to assume that we won't see any selfish mining in the next 2-3 years, especially since there's no code to combat it yet | 15:09 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds] | 15:09 | |
| bramc | psztorc, The benefits of selfish mining only start at 1/3, and even there they're dubious: You need to go at least two weeks before the work difficulty goes down, and you lose 20% of your own value during that time, and get back 10% later, so you need to be fairly confident that your own fraction of hash power will stay a healthy percent above 1/3 for more than the next six weeks and be able to stomach substantial short term loss to justify it | 15:09 |
| psztorc | This is still ignoring the fundamental symmetry. | 15:10 |
| psztorc | What if I paid someone to pretend to help my rival selfish mine...but then back out at the last second. | 15:10 |
| psztorc | How much could I afford to pay him, if the rival could indeed be tricked. | 15:11 |
| psztorc | ? | 15:11 |
| bramc | There are interesting questions of how a selfish mining pool could enforce cooperation within themselves. I think it's entirely doable, but I'm not going to analyze how, much less publish notes on how to do it. | 15:12 |
| bramc | psztorc, What you're saying seems to amount to selfish mining can't work because mumble mumble efficient markets mumble mumble profit maximization | 15:12 |
| psztorc | If you didn't catch any words I'd be happy to repeat them. | 15:13 |
| bramc | You've repeated them enough already | 15:13 |
| psztorc | Any miner can execute any known strategy, any miner can team up with another miner. So 50% will always be the threshold. | 15:14 |
| AdrianG | thats not a convincing argument | 15:15 |
| bramc | You don't appear to understand what selfish mining is. We're discussing a very specific technical topic with actual properties. You can read the 'mining is not enough' paper if you are actually interested in details. | 15:15 |
| psztorc | I've read it. | 15:15 |
| psztorc | If someone with 31% selfish mines, and someone else with 50% selfish mines, and 19% are honest, is that in strategic equilibrium? | 15:16 |
| psztorc | The 31% will keep doing what they are doing? | 15:17 |
| psztorc | 31% is enough? | 15:18 |
| psztorc | I'm sure it is...have fun with your tinkering, see ya later. | 15:19 |
| -!- psztorc [4575fa8d@gateway/web/freenode/ip.69.117.250.141] has quit [Quit: Page closed] | 15:19 | |
| bramc | That was easier than I expected | 15:22 |
| Taek | Though it took a while to digest, I think his fundamental argument is that people will continue to adapt their behavior any time they find themselves on the losing side of an equation, teaming up or engaging in whatever tactics they need to in order to survive | 15:27 |
| Taek | which to me is a bit of a cop-out | 15:27 |
| Taek | I'd rather not have that overhead, and rather just exist in a system where everyone following a very simple, very defined set of rules yeilds them the optimal amount of utility | 15:28 |
| bsm117532 | That's certainly a true argument, but useless. | 15:29 |
| bsm117532 | We analyze the economic incentives under the best assumptions we can, and bitcoin requires that the net incentive moves the network forward...throwing up your hands is incompatible with using "profit maximization" as the mechanism of consensus. | 15:29 |
| bramc | About 'evil' soft forks: In general the definition of soft fork is that full nodes will continue to accept the new stuff. It also seems to be the case that a miner making no-transaction blocks should be able to mint new ones. But some soft forks result in there being transactions which appear valid to unupdated miners but cause their blocks to get orphaned, and other soft forks cause the number of transactions which old miners are able to accept to dro | 15:31 |
| bramc | p dramatically over time, possibly down to nothing, which also is potentially problematic. I don't know what the terms for those properties are, or if there are even standard ones. | 15:31 |
| AdrianG | optimal for whom? | 15:31 |
| bramc | There have been soft forks with both of those properties which were uncontroversial: getting rid of concat for the first one, adding p2sh for the second | 15:34 |
| bramc | So my questions are: What are the names for those properties, and what's the dividing line between having those properties and being 'evil'? | 15:36 |
| frankenmint | anyone here use this?: https://cs.umd.edu/~amiller/shadow-bitcoin.pdf | 15:36 |
| frankenmint | I've read that there was a built in simulation tool in core software (from luke-jr) is this the same tool or is it different? | 15:37 |
| Taek | bramc: are you familiar with the BAR model? | 15:38 |
| bramc | Taek, no | 15:38 |
| Taek | bramc: https://www.cs.utexas.edu/~lorenzo/papers/sosp05.pdf | 15:40 |
| Taek | the general idea is that you can divide your participants into a few categories. Some will be byzantine, meaning they'll fail in ways that hurt the system maximally. Some will be altruistic, meaning they will follow the protocol exactly no matter what, and the rest will be rational, meaning that they'll only follow the protocol if there's incentive, and they'll deviate from the protocol where there is incentive to do so | 15:41 |
| bramc | Taek, Thanks I'll read that paper later | 15:41 |
| bramc | Taek, While somewhat related that doesn't answer my questions | 15:42 |
| bsm117532 | frankenmint: That's cool, I didn't know about it. | 15:45 |
| Taek | bramc: iirc p2sh wasn't actually uncontrovertial. There was a lot of discussion about how it should be done, then gavin merged a proposal because he did not want to keep waiting for nothing to happen | 15:49 |
| Taek | and as /r/bitcoin has demonstrated, there's no such thing as 'uncontrovertial' in Bitcoin :P | 15:49 |
| jcorgan | some people are only happy with controversy and if there is not enough, by golly, they will make some | 15:51 |
| bramc | Well, potentially acceptable if not uncontroversial | 15:53 |
| -!- binary01 [~binary01@ool-457c7178.dyn.optonline.net] has quit [Quit: Leaving] | 15:55 | |
| phantomcircuit | Taek, which was a mistake since his version of p2sh is actually demonstrably worse than the other proposal | 15:57 |
| -!- frankenm_ [~frankenmi@67-5-247-11.ptld.qwest.net] has joined #bitcoin-wizards | 16:10 | |
| -!- frankenmint [~frankenmi@67-5-247-11.ptld.qwest.net] has quit [Read error: Connection reset by peer] | 16:10 | |
| -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] | 16:13 | |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 16:13 | |
| -!- GGuyZ_ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 16:14 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 16:14 | |
| -!- GGuyZ_ is now known as GGuyZ | 16:14 | |
| -!- jcorgan is now known as jcorgan|away | 16:19 | |
| -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards | 16:33 | |
| -!- eudoxia_ [~eudoxia@r186-55-180-76.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 16:38 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 16:41 | |
| -!- eudoxia [~eudoxia@r186-54-159-21.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 256 seconds] | 16:42 | |
| -!- Monthrect is now known as Piper-Off | 16:42 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 16:43 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards | 16:43 | |
| el33th4x0r | So, I blink and spend the day reading papers, and you guys all go ahead and have a huge selfish mining discussion without me. | 16:44 |
| -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] | 16:52 | |
| -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 16:58 | |
| -!- tulip [~tulip@unaffiliated/tulip] has quit [Quit: Textual IRC Client: www.textualapp.com] | 17:00 | |
| -!- wallet42 [~wallet42@i121-117-83-230.s41.a013.ap.plala.or.jp] has joined #bitcoin-wizards | 17:00 | |
| -!- jcorgan|away is now known as jcorgan | 17:02 | |
| kanzure | el33th4x0r: i like how bramc quit as soon as you said that :-) | 17:03 |
| el33th4x0r | didn't see that. he gave an excellent summary of selfish-mining related concerns earlier. | 17:05 |
| kanzure | any interesting papers in particular? | 17:06 |
| el33th4x0r | I very much like Aviv Zohar's follow-on paper on SM. Let me find the link... | 17:07 |
| el33th4x0r | http://arxiv.org/abs/1507.06183 | 17:07 |
| kanzure | .title | 17:08 |
| yoleaux | [1507.06183] Optimal Selfish Mining Strategies in Bitcoin | 17:08 |
| kanzure | ah. | 17:08 |
| -!- JackH_ [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-wizards | 17:11 | |
| -!- JackH_ [~Jack@host-80-43-143-141.as13285.net] has quit [Read error: Connection reset by peer] | 17:11 | |
| brg444 | kanzure do you have link to segwit BIP ? | 17:15 |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 17:16 | |
| brg444 | ah nvm found it | 17:16 |
| kanzure | brg444: https://github.com/bitcoin/bips/pull/265 | 17:16 |
| brg444 | yep thx | 17:16 |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 17:17 | |
| -!- Myagui [Myagui@shell.xshellz.com] has quit [Max SendQ exceeded] | 17:19 | |
| -!- Myagui [Myagui@shell.xshellz.com] has joined #bitcoin-wizards | 17:20 | |
| -!- wallet42 [~wallet42@i121-117-83-230.s41.a013.ap.plala.or.jp] has quit [Quit: Leaving.] | 17:29 | |
| -!- Guest7736 [~socrates1@li175-104.members.linode.com] has quit [Changing host] | 17:30 | |
| -!- Guest7736 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-wizards | 17:30 | |
| -!- Guest7736 is now known as amiller | 17:30 | |
| amiller | frankenm_, i don't think anyone is using shadow-bitcoin yet | 17:30 |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 17:32 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] | 17:34 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has quit [Ping timeout: 260 seconds] | 17:35 | |
| -!- MrHodl [~fuc@91.210.105.101] has joined #bitcoin-wizards | 17:37 | |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:52a:cba5:ca57:eacc] has joined #bitcoin-wizards | 17:38 | |
| -!- SgtStroopwafel [~Chuck@s5597aba6.adsl.online.nl] has joined #bitcoin-wizards | 17:41 | |
| -!- eamonnw [eamonnw@faeroes.sdf.org] has joined #bitcoin-wizards | 18:02 | |
| -!- oneeman [~oneeman__@ip48-68-15-186.ct.co.cr] has joined #bitcoin-wizards | 18:02 | |
| -!- frankenm_ is now known as frankenmint | 18:03 | |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed] | 18:04 | |
| -!- stevenroose_ [~steven@2a02:2c40:400:b000::1:9fa0] has quit [Ping timeout: 255 seconds] | 18:11 | |
| -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 18:12 | |
| -!- ak_ [~akstunt60@65.78.54.2] has quit [Ping timeout: 240 seconds] | 18:18 | |
| bsm1175321 | amiller: I know the Bitcoin-NG guys ran a 1000 node simulated bitcoin cluster, with the actual core code. Do you know how they did it, if not shadow-bitcoin? In any case, I'll probably use it. | 18:19 |
| -!- STRML_ [~STRML@unaffiliated/strml] has quit [Ping timeout: 276 seconds] | 18:19 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 18:19 | |
| amiller | el33th4x0r, ^^^^ | 18:20 |
| bsm1175321 | Oh he's on, thanks. | 18:20 |
| bsm1175321 | Right now I'm doing simulations in python with my cartoon mental model of Bitcoin, but the next step is to use the core code. | 18:21 |
| bsm1175321 | amiller: how does shadow-bitcoin efficently use the blockchain? I assume I don't need 1000 copies of the 60+GB chain...but then it seems the different instances will conflict with each other when e.g. updating leveldb... | 18:24 |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ppevadrwnrucphgn] has quit [Quit: Connection closed for inactivity] | 18:24 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 18:26 | |
| bsm1175321 | nm, your wiki page has what I need, I think. | 18:26 |
| el33th4x0r | we built an emulation testbed, with links emulating the bandwidths and latencies we measured. | 18:27 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 18:27 | |
| bsm1175321 | el33th4x0r: Is it all software? Any chance it's open sourced or something I can use? | 18:28 |
| el33th4x0r | all software. we plan to release the testbed code on or before April. It has not been open sourced yet. | 18:29 |
| el33th4x0r | of course, you'll need a large cluster and a quiescent network to use it. | 18:30 |
| bsm1175321 | Eek that's what I was afraid of. :-( | 18:30 |
| el33th4x0r | if the study you want to do could lead to a publication for a student, we might be able to find a way to run your study here, locally on our own cluster. | 18:31 |
| bsm1175321 | shadow-bitcoin seems too good to be true. Can you make a comparison? Have you seen it? | 18:31 |
| bsm1175321 | I'm no longer at an academic institution, but it will lead to a publication. | 18:31 |
| el33th4x0r | I know all about shadow-bitcoin. great work by amiller. | 18:31 |
| bsm1175321 | Co-authorship is certainly doable. | 18:31 |
| el33th4x0r | ok, awesome, why don't you email me a short description of the experiments, and I'll see if we can get one of our phd students interested. | 18:32 |
| bsm1175321 | Ok, happy to! Thanks! | 18:32 |
| el33th4x0r | awesome, looking forward to it! | 18:33 |
| kanzure | do your phd students accept bribes like money and payment? | 18:33 |
| bsm1175321 | Academics work for citations alone. ;-) | 18:33 |
| el33th4x0r | :-) haha, we are so corruptible! | 18:33 |
| kanzure | seems like a good opportunity to throw some people at various problems | 18:33 |
| kanzure | ah i see, authorships. | 18:33 |
| kanzure | well okay. | 18:33 |
| bsm1175321 | See, I know the system. ;-) | 18:34 |
| el33th4x0r | kanzure: more seriously, phd students can consult. but they are far more motivated when the problem is open, difficult and likely to yield a new result. | 18:34 |
| kanzure | well more specifically i mean, in other contexts, i have to pay to fund a small "grant" or something, and then the university admins get 52% and etc etc | 18:35 |
| el33th4x0r | ah, the overheads... bane of our existence. | 18:36 |
| el33th4x0r | for industrial gifts, it's only 10% | 18:36 |
| kanzure | cool to hear you have some leeway in absence of grants tho | 18:36 |
| el33th4x0r | for grants we get from government sources, the university takes 67% overhead. | 18:36 |
| kanzure | haha what 67% | 18:36 |
| el33th4x0r | yeah, insane. | 18:36 |
| coinoperated | thats nuts. an actual government sponsored institution (the Smithsonian) only takes about 25% (from an NSF grant in this case) | 18:37 |
| el33th4x0r | tell me about it. When we say something about it, the administration says that Harvard's overhead is in the 70-something percent range. | 18:38 |
| bsm1175321 | I left for private industry and am still trying to publish papers. Universities are dying. | 18:39 |
| kanzure | their inertia will play out for a long time | 18:39 |
| el33th4x0r | they are certainly changing character. | 18:39 |
| bsm1175321 | I'm more interested in progress than supporting dinosaurs built of administrators. | 18:39 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 18:39 | |
| el33th4x0r | there are tons of idealistic people going into the system, so that tends to keep things afloat. | 18:40 |
| coinoperated | Is that true for the whole school or just for the GSAS, and its different for the med school, etc? | 18:40 |
| coinoperated | err i mean, the Cornell version of the GSAS | 18:40 |
| el33th4x0r | this is true for engineering for sure. I believe it's also true for the sciences. I would not be surprised if the overheads were actually higher for the med school. | 18:41 |
| -!- p15 [~p15@16.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 18:51 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 18:53 | |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has quit [Remote host closed the connection] | 18:58 | |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has joined #bitcoin-wizards | 18:58 | |
| -!- frankenmint [~frankenmi@67-5-247-11.ptld.qwest.net] has quit [Remote host closed the connection] | 19:00 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 255 seconds] | 19:01 | |
| -!- eudoxia_ [~eudoxia@r186-55-180-76.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 19:10 | |
| -!- nuke1989 [~nuke@178-157-152.dynamic.cyta.gr] has quit [Remote host closed the connection] | 19:11 | |
| -!- zwischenzug [~zwischenz@pool-173-73-105-60.washdc.fios.verizon.net] has joined #bitcoin-wizards | 19:12 | |
| -!- Guest14531 [~root@76.74.170.216] has joined #bitcoin-wizards | 19:17 | |
| Guest14531 | sup | 19:17 |
| Guest14531 | any of u guys lift? | 19:17 |
| Guest14531 | was just telling my lady about bitcoins | 19:18 |
| Guest14531 | she said she thought they sounded pretty boss | 19:19 |
| Guest14531 | state cant control em and whatever | 19:19 |
| Guest14531 | thats cool man | 19:19 |
| kanzure | wrong channel, this is actually buttcoin hq | 19:22 |
| -!- pozitrono [~nu@85.17.25.22] has joined #bitcoin-wizards | 19:24 | |
| Guest14531 | not into butt stuff | 19:24 |
| Guest14531 | at least right now | 19:24 |
| Guest14531 | ;) | 19:25 |
| -!- wallet42 [~wallet42@i121-117-83-230.s41.a013.ap.plala.or.jp] has joined #bitcoin-wizards | 19:25 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-zwvdjxoqkklouucv] has joined #bitcoin-wizards | 19:27 | |
| Guest14531 | whats going on with bitcoin what can i do to help make it better | 19:29 |
| -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] | 19:34 | |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 19:34 | |
| Guest14531 | far out | 19:43 |
| -!- Guest14531 [~root@76.74.170.216] has quit [Quit: leaving] | 19:43 | |
| -!- nickeem [~nickeem@cpe-104-32-148-17.socal.res.rr.com] has joined #bitcoin-wizards | 19:57 | |
| -!- nickeeem [~nickeem@cpe-104-32-148-17.socal.res.rr.com] has quit [Ping timeout: 265 seconds] | 19:59 | |
| coinoperated | this being buttcoin hq we will need you to tithe some comedy gold first. | 19:59 |
| -!- kmels [~kmels@120.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 240 seconds] | 20:02 | |
| -!- zwischenzug [~zwischenz@pool-173-73-105-60.washdc.fios.verizon.net] has quit [Remote host closed the connection] | 20:03 | |
| -!- zwischenzug [~zwischenz@pool-173-73-105-60.washdc.fios.verizon.net] has joined #bitcoin-wizards | 20:13 | |
| -!- RedEmerald [~RedEmeral@unaffiliated/redemerald] has quit [Ping timeout: 256 seconds] | 20:16 | |
| -!- RedEmerald [~RedEmeral@216.240.130.109] has joined #bitcoin-wizards | 20:20 | |
| -!- RedEmerald [~RedEmeral@216.240.130.109] has quit [Changing host] | 20:20 | |
| -!- RedEmerald [~RedEmeral@unaffiliated/redemerald] has joined #bitcoin-wizards | 20:20 | |
| -!- p15_ [~p15@34.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 20:23 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 20:25 | |
| -!- p15 [~p15@16.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 240 seconds] | 20:25 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 245 seconds] | 20:29 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 250 seconds] | 20:33 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:35 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 20:43 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 20:49 | |
| -!- risho [~quassel@c-73-252-176-148.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 20:50 | |
| -!- risho [~quassel@c-73-252-176-148.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 20:51 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 20:54 | |
| -!- oneeman [~oneeman__@ip48-68-15-186.ct.co.cr] has quit [Quit: Leaving] | 20:59 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:08 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 21:11 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 21:12 | |
| -!- GGuyZ_ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:14 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 21:14 | |
| -!- GGuyZ_ is now known as GGuyZ | 21:14 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 21:23 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 21:27 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 21:27 | |
| -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 240 seconds] | 21:31 | |
| -!- kmels [~kmels@181.174.104.127] has joined #bitcoin-wizards | 21:43 | |
| -!- go1111111 [~go1111111@104.200.154.42] has joined #bitcoin-wizards | 21:45 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 21:46 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:46 | |
| -!- GGuyZ_ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:48 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 21:48 | |
| -!- GGuyZ_ is now known as GGuyZ | 21:48 | |
| -!- zwick [~zwick@fsf/member/zwick] has joined #bitcoin-wizards | 21:48 | |
| -!- zwick is now known as knox | 21:48 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Client Quit] | 21:48 | |
| -!- knox is now known as know | 21:49 | |
| -!- know is now known as knox | 21:49 | |
| -!- knox is now known as zwick | 21:49 | |
| -!- zwick [~zwick@fsf/member/zwick] has quit [Client Quit] | 21:49 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-xzdecvegrdkxucso] has quit [Quit: Connection closed for inactivity] | 21:52 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 21:53 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards | 22:19 | |
| -!- zwischenzug [~zwischenz@pool-173-73-105-60.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] | 22:38 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 22:40 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 22:41 | |
| -!- coinoperated [~coinopera@70.15.164.106.res-cmts.t132.ptd.net] has quit [Ping timeout: 256 seconds] | 22:41 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 22:42 | |
| -!- smk [6dc987dc@gateway/web/freenode/ip.109.201.135.220] has joined #bitcoin-wizards | 22:53 | |
| -!- pozitrono [~nu@85.17.25.22] has quit [Ping timeout: 260 seconds] | 22:59 | |
| -!- wallet42 [~wallet42@i121-117-83-230.s41.a013.ap.plala.or.jp] has quit [Quit: Leaving.] | 23:04 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-zwvdjxoqkklouucv] has quit [Quit: Connection closed for inactivity] | 23:06 | |
| -!- STRML [~STRML@unaffiliated/strml] has joined #bitcoin-wizards | 23:19 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 23:31 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 23:31 | |
| -!- Emcy [~MC@cpc3-swan1-0-0-cust996.7-3.cable.virginm.net] has joined #bitcoin-wizards | 23:32 | |
| -!- Emcy [~MC@cpc3-swan1-0-0-cust996.7-3.cable.virginm.net] has quit [Changing host] | 23:32 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 23:32 | |
| -!- STRML [~STRML@unaffiliated/strml] has quit [Quit: ZNC - http://znc.in] | 23:39 | |
| -!- STRML [~STRML@unaffiliated/strml] has joined #bitcoin-wizards | 23:42 | |
| -!- smk [6dc987dc@gateway/web/freenode/ip.109.201.135.220] has quit [Ping timeout: 252 seconds] | 23:42 | |
| -!- Dizzle_ [~Dizzle@2605:6000:1018:c0b1:acc7:83bf:a667:8f87] has joined #bitcoin-wizards | 23:57 | |
| bramc | I'm using locally defined functions like they're ghetto macros. I don't know if this is extremely pythonic or extremely not pythonic. | 23:58 |
| --- Log closed Thu Dec 31 00:00:51 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!