00:00:25justanotheruser:having 600 people create vote transactions for the miners to use is a really inefficient way for miners to vote!
00:03:02fanquake:fanquake has left #bitcoin-wizards
00:10:28Luke-Jr:justanotheruser: I suppose it places oversight on miners' votes to some limited degree
00:15:21AlexStraunoff:AlexStraunoff is now known as NikolaiToryzin
00:32:31instagibbs:I did my part(TM) and refused to vote until they switched it back
01:07:44maaku:gmaxwell: no way to clean that up?
01:08:55copumpkin:what's the status on sidechains?
01:08:58copumpkin:haven't heard much about them recently
01:10:15justanotheruser:maaku: if you want to softfork and have potentially a forbidden change over a utxo size decrease
01:11:09justanotheruser:copumpkin: IIRC there will be demo (federated trust?) sidechains soonish
01:11:14maaku:copumpkin: we will be releasing some code related to the federated peg soon
01:11:30copumpkin:ah cool
01:11:35copumpkin:any writings on what's planned?
01:12:43maaku:copumpkin: too busy actually writing it to write about it :(
01:12:51copumpkin:I know the feeling :)
01:12:52copumpkin:carry on!
01:12:58maaku:but speaking of too much to do, we can use some help : http://blockstream.com/jobs
01:13:29justanotheruser:maaku: out of curiousity, is everyone remote?
01:13:46sipa:we live on the interwebz
01:13:57copumpkin:hah, I enjoy mine too much to do that, but it certainly sounds fun
01:14:20justanotheruser:thats probably for the best
01:14:46belcher:maaku how are you paying the salaries of those positions? VC money?
01:15:04maaku:happy to answer these on #blockstream
01:53:54starsoccer:starsoccer is now known as Guest97465
01:55:08Guest97465:Guest97465 is now known as starsoccer
03:06:39instagibbs:maaku: changing up my work soon, unfortunately I'm in wrong sub-field of CS :)
06:21:31evanxbt:evanxbt has left #bitcoin-wizards
07:13:23fanquake_:fanquake_ is now known as fanquake
09:05:16barjavel.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:16barjavel.freenode.net:Users on #bitcoin-wizards: andy-logbot CoinMuncher SDCDev erasmospunk cbeams Guyver2 coiner p15_ coinheavy melvster1 wallet42 c0rw1n arubi flower luny dc17523be3 fanquake hktud0 helo NewLiberty null_radix adam3us1 paveljanik moa TheSeven ryanxcharles Emcy zwischenzug bsm117532 justanotheruser Dr-G3 bosma PaulCapestany embicoin tromp sipa instagibbs d1ggy btcdrak hashtag oujh cluckj antgreen NikolaiToryzin prodatalab GAit nubbins` huseby afk11 s1w iddo xabbix
09:05:16barjavel.freenode.net:Users on #bitcoin-wizards: HaltingState kyuupichan bepo nuke1989 LarsLarsen bobke Visheate bbrittain jaromil jcorgan wumpus BrainOverfl0w roasbeef phedny so hguux__ otoburb MRL-Relay azariah HM2 btc___ andytoshi throughnothing @ChanServ brand0 Alanius davout Hunger- NeatBasis mr_burdell bliljerk101 DoctorBTC nanotube d9b4bef9 comboy SubCreative a5m0 harrow fenn paperbot Anduck guruvan epscy Apocalyptic CryptOprah leakypat TD-Linux K1773R indolering warptangent amiller
09:05:17barjavel.freenode.net:Users on #bitcoin-wizards: veox Eliel ryan-c Graet ahmed_ jessepollak kinlo dignork cornus_ammonis lechuga_ Iriez Adrian_G wizkid057 copumpkin gmaxwell warren gnusha heath midnightmagic grubles wiz jbenet mappum cryptowest binaryatrocity go1111111 waxwing jaekwon pigeons eric kanzure petertodd JonTitor catlasshrugged Keefe Taek BananaLotus Oizopower maaku sneak platinuum PFate cfields Muis forrestv michagogo Krellan catcow mariorz nsh kumavis Zouppen artifexd yrashk
09:05:17barjavel.freenode.net:Users on #bitcoin-wizards: Xzibit17 coryfields grandmaster sdaftuar ajweiss phantomcircuit smooth shesek tromp_ dgenr8 OneFixt devrandom tripleslash Cory bedeho GreenIsMyPepper espes__ Logicwax dasource delll_ Starduster airbreather MoALTz hashtag_ adlai spinza face BlueMatt stonecoldpat gwillen isis sl01 dardasaba Fistful_of_Coins jgarzik nickler morcos weex Luke-Jr berndj [d__d] ebfull dansmith_btc yoleaux cursive gavinandresen Meeh fluffypony gribble optimator
09:05:17barjavel.freenode.net:Users on #bitcoin-wizards: asoltys_ livegnik crescendo
10:43:29embicoin_:embicoin_ is now known as embicoin
11:19:41wallet42:wallet42 is now known as Guest71040
11:19:41wallet421:wallet421 is now known as wallet42
14:25:49maaku:maaku is now known as Guest58568
17:22:14PFate:PFate has left #bitcoin-wizards
18:31:26Guest58568:Guest58568 is now known as maaku
19:28:11bramc:The bitcoin foundation is sounding an awful lot like the FSF or the xcode foundation
19:33:26bramc:As in, organizations which their intended recipients might be better off without.
19:36:03Luke-Jr:bramc: eh, FSF does good work?
19:36:51bramc:Luke-Jr, I don't know if they've turned around in the last 10 years, but at one point they stopped funding software because nobody wanted their money any more because they were impossible to deal with. Also the GPLv3 thing is... misguided.
19:37:08Luke-Jr:bramc: I don't see why people hate the GPLv3. it seems good to me.
19:37:49Luke-Jr:clarifies some important matters people confused in the GPLv2 and addresses patent abuse problems
19:38:19bramc:Luke-Jr, The short of it is that in practice it's way too much of a poison pill. Although that subject is rather off topic for here. In practice the gplv2 is a horrible poison pill as well, and so is the lgpl if you actually read the fine print and try to be compliant
19:39:19Luke-Jr:* Luke-Jr has had no issues with the AGPLv3 for Eloipool.
19:40:00Luke-Jr:it's often a necessary "poison pill" as long as others don't play nice.
19:40:26bramc:The gplv3 in practice achieves nothing because it's such a poison pill that nobody uses it
19:40:36Luke-Jr:(lots of people do)
19:41:32Luke-Jr:GPLv3 recently came in handy when Google/Nest decided to claim the GPLv2 doesn't apply to their "smart" thermostats
19:41:37bramc:Let me clarify: I don't think I've ever heard of a single time when a business used gplv3 software. And most of them won't touch gplv2 except for certain very specific cases like linux and python (which is dual licensed anyway)
19:43:15bramc:But my original point was about the bitcoin foundation, and from what I'm reading now the comparison is unfair to the fsf, because they may be unpleasant and misguided, but they aren't overtly criminal and grotesguely incompetent.
19:44:31Luke-Jr:bramc: community is more important than businesses who hate free software. I probably wouldn't buy their products anyway. Nest used GPLv3 monit, so I was able to get source out of them using it, and I am pleased with that result.
19:44:34Luke-Jr:yes, we can get back to BCF :p
19:45:37bramc:Most big free software projects have most of their development done by people who are paid to do so as part of their jobs. Businesses are happy to participate in the community if you let them.
19:47:13bramc:gmaxwell, The bug in timsort only applies to extremely large arrays
19:47:26fanquake_:fanquake_ is now known as fanquake
19:48:27bramc:The people who did the work on it figured out a patch which doesn't produce a measurable degredation in performance and *has a proof of correctness*. The Java people looked at the bug report, rejected the patch and did their own fix which does measurably reduce performance and doesn't have a proof of correctness
19:48:29bramc:*headdesk*
20:26:39bramc:I'm reading through stuff on microchannels and have some really basic questions
20:27:07kanzure:speak
20:27:30bramc:It seems like the basic concept is that there's a 'channel', which is where I pledge a certain amount of coin which I might want to transfer to a certain counterparty at some time in the future, and then I sort of piecemeal send it to them securely over time
20:27:58kanzure:you give them a transaction that you will later replace
20:28:09bramc:So the first question is, is that correct? And the second question is, if this is done by cancelling out old transactions, how are the old ones rendered obsolete?
20:29:36kanzure:i don't know the exact details but if i assume there are no details then the simple answer is never send them a transaction that doesn't spend the original inputs.
20:30:11kanzure:if you want to cancel the transaction another way is to spend those inputs to yourself separately (thus invalidating the transaction you gave them) (the transaction you gave them was not going to be accepted by the network immediately because of some feature i forget the name of)
20:30:29kanzure:probably nLockTime
20:30:33Luke-Jr:bramc: the older ones have a later nLockTime
20:30:57kanzure:cool, "from first principles" wins again. who needs to know things?
20:33:18kanzure:bramc: imagine a restricted example where the user only has one input. spending the input in the first transaction might pay out only 1% of the amount, and 99% goes back to the spender as change. a second transaction with a smaller nLockTime would still have to spend the same inputs, so the original transaction would be invalid by the time it became possible to submit it and get it accepted on the network. of course, they are welcome ...
20:33:24kanzure:... to spend that first one rather than the later ones, but then they just earn less money. (again my example was restricted with a single input)
20:33:27bramc:Actually this might all be a silly question, I can give you a transaction handing over a larger amount of my original coin, which I'm not able to deposit because you need to sign it as well
20:34:54bramc:kanzure, so why get nlocktime involved at all? It seems like that's mostly necessary for a refund in the initial coin setup
20:36:10bramc:The main problem seems to be that this requires a huge amount of working capital, and that original nlocktime needs to be far in the future for there to be real performance, which also sucks if my counterparty wanders off because I have to wait to get my coin back
20:37:04bramc:Basically I'm depositing coin in a bank and the bank is doing transfers with other banks. It should be possible to set up a collaborative simultaneous transfer so that I can securely transfer coin with somebody else who's also using a bank
20:38:20bramc:Which sounds like a complicated and technical transaction but should be totally doable, I'm trying to figure out the high level things right now.
20:38:22kanzure:whoops yes i forgot about the signed refund transaction
20:39:49bramc:From some stuff at the talk the other day I think he doesn't actually have that simultaneous transfer integration stuff worked out. Maybe I should do that.
20:41:28bramc:But this working capital stuff seems like a serious limitation. Everybody needs at some point to take a pile of real money and exchange it for a pile of coin
20:42:06bramc:And that needs to have at least one transaction hit the block chain
20:42:47kanzure:"working capital limitations" is one reason one might want to have not all of their capital in a single utxo
20:44:27bramc:kanzure, Not sure what point you're making
20:45:04bramc:My point is that if I intend to spend $X over the next year, and only incur one set of transaction fees, I need to go plop down $X right now
20:46:07kanzure:why is it a year-long thing?
20:46:33kanzure:iirc people have said for a while now that channels are best used for more real-timey services
20:46:37bramc:I can do a shorter time period, but then that incurs more real transactions on the block chain
20:47:45bramc:There's also something about a new opcode to incur fewer real transactions, something about locking by time since deposited. I have no idea what that's about.
20:49:21bramc:It seems like it should work for real time stuff, at least in terms of being better than green address, assuming the whole four-way transaction with two counterparties and two banks is worked out.
20:50:04belcher_:belcher_ is now known as belcher
20:53:14kanzure:i've been having trouble lately regarding arguments about how many transactions should be on the blockchain or not
20:53:29kanzure:tell me how to decide what the correct amount of transactions for a healthy civilization is. one billion per second? one trillion per second?
20:53:59maaku:kanzure: whatever can be supported without compromising the decentralized nature of the block chain
20:54:29kanzure:maaku: sure. i just use that rant to go into "batched settlement is good".
20:54:30bramc:The annoying thing is that if I have a transfer going to and from you and we hit the amount pledged on both sides then we have to make another whole new transaction with new pledges to cancel out the old one. Maybe there's something in the microchannel stuff about using nlocktime to do exactly that.
20:54:40Luke-Jr:maaku: well, no need for that if we can do fine with less either :p
20:55:05bramc:kanzure, microchannels are batched settlement, correct? Just secure batched settlement, instead of 'we trust the bank' batched settlement.
20:55:54Luke-Jr:I'd say as few as possible without compromising security in significant ways is ideal.
20:56:07kanzure:well, maybe... i will have to think more about that. batching, in my head, just means taking lots of transactions and simplifying the inputs and outputs to make the overall set smaller.
20:57:06bramc:kanzure, I'm envisioning microchannels as just a way of having secure banks. Maybe this isn't what other people are thinking. I'm pretty sure the talk the other day didn't cover that, which means that a designing a 50-message protocol is likely in my near future.
20:57:25kanzure:just use ISO 20022 or something else that already exists
20:59:06bramc:For transaction rate, let's say that the population of earth is 10 billion people and each does 100 transactions per day, that's a trillion transactions per day, or about 10 million transactions per second
20:59:27Luke-Jr:bramc: did you by chance get to go to Joseph's presentation on Monday?
20:59:30bramc:That's probably high by two orders of magnitude, a 'reasonable' goal is 100 thousand transactions per second
20:59:53bramc:Luke-Jr, yes but I was a few minutes late and it seemed it was impossible to follow all the technical details from the presentation
20:59:59Luke-Jr:>_<
21:00:33bramc:It wasn't organized very well, a high level of what the protocol accomplishes with no technical machinery would have been much more helpful.
21:00:51bramc:I *might* be sent a draft of the paper later today.
21:01:07Luke-Jr:* Luke-Jr wonders when he plans to publish his paper
21:01:27bramc:He said the paper was going online the next day, but google isn't helping me
21:01:39bramc:He also said the paper isn't very clear yet.
21:02:11kanzure:i'm not sure that the blockchain needs to handle all transactions in civilization anyway
21:02:21kanzure:and consider all closed book transactions, such as random ledgers from random video games
21:04:11bramc:I'm *guessing* that a channel is something along the lines of we each pledge an $X coin to each other, and start handing over bits of it over time, every time somebody transfers money to me you give me some of your pledged one, every time I spend some I give you some of my pledged one, and when both are completely spent we obliterate them by making a new pair with a shorter nlocktime
21:06:00bramc:But the work to integrate the transfers with simultaneous transfer seems to be not done yet.
21:07:38bramc:So technical issues, which I believe are, ahem, interesting but entirely doable, the big questions come down to working capital.
21:08:22bramc:Like, I don't imagine a bank would be terribly eager to plop down $X of bitcoin just so I can start transacting, even if I do the same.
21:14:32kanzure:bramc: have you read https://bitcoinj.github.io/working-with-micropayments
21:14:55kanzure:and https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
21:16:55bramc:kanzure, was just reading that first one, will look at the second one
21:27:35Taek:bramc: They are called micropayment channels because they're more useful for small many small payments that sum to a still-small payment.
21:28:09Taek:When you create one, you're locking up some volume of coins which you can *only* send to the receiver for X time
21:29:15Taek:So generally you wouldn't want to do it with something as serious as banking, because if the bank decides to enforce 10% fees or whatever, you're basically stuck waiting until the refund expires.
21:29:58bramc:Going by my own laws of physics calculation, which in this case are really laws of arithmetic, if I want to set up an account with a bank the capital requirements should be that I have to plop down the maximum amount I might go into the hole in the future before my transactions start getting rejected up front, which involves a real transaction on the block chain. Thereafter if people transfer me coin or I send coin it se
21:29:58bramc:ems like it should be possible to not have any transactions on the block chain until my net balance goes below zero or above my initial deposit
21:30:26bramc:So I can get, say, my paycheck sent, which makes something new on the blockchain, and thereafter work with an untrusted bank
21:31:03Taek:Yes, but you're forced to work with your bank. Any time you send money to someone, you'll have to get a signature from your bank
21:31:28bramc:Taek, Yes that's the other issue is that an attacker can force you to wait out the refund time
21:31:46Taek:Such an attack isn't a big deal if it's like $80 and you're waiting 30 days
21:32:04Taek:It's a bigger problem if it's 6 months of income and you're waiting a whole year
21:32:05bramc:Even if it's a whole paycheck a month or two might not be so bad
21:32:34bramc:Compared to how poor people get their paychecks stolen from them in overdraft fees that sort of downside scenario is no big deal
21:32:35Taek:^ not so bad for software devs. A huge many people live paycheck to paycheck though
21:33:23Taek:The bank would instead just bully them, knowing it has all their money, and enforce a 10% spending fee
21:33:30bramc:Also, banks don't generally disappear and force you to wait a bit to get your money out all that often. They steal hundreds of dollars using overdraft fees and similar bullshit fees all the time
21:33:31Taek:they have no choice b/c they need to eat
21:33:58bramc:Such behavior would cause a severe hit to the bank's reputation
21:34:19Taek:You'd imagine that BS overdraft fees would do the same
21:34:49bramc:overdraft fees can be hidden in the fine print, with a cryptocurrency you're actually defended
21:35:18bramc:But this is all besides my point, I'm talking about the theoretical limits of deposit requirements, which you haven't actually disagreed with so far
21:36:07bramc:The work done so far seems to assume that the bank will make a backwards deposit when you make your forwards deposit, which to me falls into the category of Things Which Will Not Happen
21:36:40bramc:Also I'm trying to do better than micropayment support, into blockchain scaling, which is what the presentation the other day was about.
21:36:46Taek:A bank would do it if the deposit backwards had some sort of interest rate attatched to it
21:37:09bramc:I think the backwards deposit is a technical problem which should have a purely technical solution.
21:37:35Taek:I think the theoretical limit of micropayment channels is 1 transaction on the blockchain per party per cycle of coins.
21:38:16bramc:I think it's possible to reduce the blockchain transaction to 1 transaction (or some small constant factor on top of that) on the blockchain per return timeout period
21:38:42Taek:even if you spend more than the initial balance/
21:38:43Taek:*?
21:39:32bramc:No, you can't spend more than the initial deposit or have sent to you to get a balance greater than the initial deposit without incurring a new blockchain transaction
21:39:45bramc:Although there might be a loophole on that second one
21:41:46bramc:This still doesn't get anywhere near global scalability, but at least it gets a bunch more orders of magnitude
21:42:39Taek:https://bitcointalk.org/index.php?topic=918018.0
21:42:56Taek:There's also a mailing list thread but I'm not sure how to link to that
21:43:14Taek:I don't fully understand how/if it works
21:43:34bramc:If you assume that there's a billion people using the system and they do one transaction per month, that's about 400 transactions per second, still not feasible
21:43:41kanzure:sourceforge has a web interface to their mailing lists but i hvaen't figured out how to predict the urls
21:48:54Taek:400 tps only gets you 1 billion per month? I never made that connection before
21:50:09bramc:Yeah a billion is a lot
21:53:07Taek:https://en.wikipedia.org/wiki/File:Velocity_of_M1_Money_Stock_in_the_US.png
21:54:12bramc:Is that then number of times each dollar in circulation is spent per year?
21:54:17Taek:yes
21:54:43Taek:even if you could push it out to 1 transaction per year, people tend to spend money faster than that
21:55:35kanzure:i've been meaning to try to estimate the maximum "trouble" that counterfeitable bills will be in due to exposure to scarce assets like bitcoin
21:56:02kanzure:or er, not maximum, just some approximation
21:56:22Taek:as in, how much value will the US dollar lose if Bitcoin hits a $1 trillion market cap?
21:56:27kanzure:nope
21:56:59kanzure:counterfeit bills exist because there's no proofs
22:00:25bramc:Taek, the multiplier can be handled, in principle, by net settlement through intermediaries, which 'micropayment channels' can in principle do, at least I think they can. Calling them 'micropayment channels' is a misnomer at that point of course, they're really off-blockchain net settlement channels
22:01:22bramc:Taek, the US dollar is in no danger from bitcoin
22:01:48bramc:But banks could be in trouble if basic banking functions could be done at lower cost
22:03:02Taek:I was just trying to figure out what kanzure meant by 'counterfeitable bills in trouble'
22:03:29bramc:I think he was being sarcastic, but not sure what the point was
22:05:01kanzure:uh, no particular point, just something i've been meaning to do/estimate
22:05:29kanzure:some amount of successful counterfeiting seems to occur, so in the presence of a scarce asset i wonder if that becomes more or less important
22:05:52kanzure:that's all. no particular points.
22:07:35bramc:As long as you can use counterfeit money to get dollars, it will still be valuable
22:07:50bramc:The most successful counterfeiting it's claimed comes from north korea
22:08:07kanzure:right but dosn't that eventually warp supply
22:08:13kanzure:*doesn't
22:08:24bramc:By the way, those yellow markers for checking if bills are counterfeit totally work
22:09:06nubbins`:imagine
22:09:14nubbins`:the something constellation
22:09:14bramc:counterfeit bills tend to get taken out of circulation over time, and can only be done at scale big enough to matter if you have a lot of resources but pathetically little money. Hence north korea
22:09:37kanzure:do you happen to know what that scale happens to be roughly?
22:10:30kanzure:$100B/mo? $1T/mo? or is that not noticeable?
22:12:50nubbins`:ostensibly low enough that the two countries who actually do commerce with NK wouldn't notice/care
22:13:08bramc:kanzure, the GDP of north korea is about $1 billion/month (holy shit is that low) so if we assume that 1% of it is from counterfeiting that's about $10 million/month
22:13:25kanzure:ah, and $10M/mo is nothing compared to global supply
22:13:30kanzure:alright
22:14:45Taek:bramc: I don't understand how the multiplier can be managed by 'net settlement intermediaries' without invoking trust for the lower sums of money
22:15:45Taek:If Alice spends about $100/mo and can only float about $100, she's going to need a new transaction every month?
22:16:35Taek:I guess if her employer's got a channel open that's ready to pay her 1yr in a advance, the bank can talk to the employer
22:16:58bramc:Taek, Oh I see what you're saying. It's probably the case that individual consumers only put 1x on the ratio and the rest is between vendors
22:18:48Taek:This is where my economics fall apart, but wouldn't it be the case that people with less floating cash contribute to the multiplier at a higher rate than people with lots of savings?
22:19:24Taek:I think it's more or less a ratio of 'throughput vs savings'
22:19:41Taek:(don't hold me accountable to that I'm not actually sure)
22:21:00bramc:Taek, It isn't clear what the practical implications of the ratio are because theres so much 'near money' and it isn't clear what boundaries should be used
22:21:39bramc:I don't remember if the ratio going up is supposed to make the value of money go up or down
22:21:59arubi__:arubi__ is now known as arubi_
22:22:25arubi_:arubi_ is now known as arubi
22:25:40bramc:It does seem like a period of a month is about right, and most accounts are going to be one way or the other. Of course that highlights the other problem which is that hardly any commerce is kept within bitcoin today so trying to use net settlement is a little silly
22:25:58bramc:So the whole thing is somewhat aspirational
22:26:06Taek:silly today but it might not be that unreasonable in 5 years
22:26:42Taek:the best think that I can think of for paying Alice w/o adding a txn to the blockchain is creating a payment that's greater than what Alice owns
22:27:31bramc:It may be possible to increase alice's refund, or do something about reducing the refund time.
22:27:37bramc:I'll need to stew on it more.
22:27:45bramc:Also get a copy of that damn paper and read it.
22:28:07Taek:bi-directional payment channels would fix this issue
22:28:41bramc:But bi-directional channels require capital deposits on both sides.
22:29:30bramc:Or maybe a payment to alice could be used as the bank's deposit, or something.
22:30:01Taek:presumably, the size of the channel only limits the maximum possible net flow
22:31:19Taek:Which I guess is still a problem for people looking to save for retirement or something
22:32:45bramc:It only limits the flow for the one time period until the refund option, but the capital requirements for a bank to potentially transfer to a depositor are a real problem.
22:39:55Taek:The other problem is centralization. By making these channels you're necessarily reducing the number of parties you can send coins to.
22:40:11Taek:Which hurts decentralization
22:54:52gmaxwell:Taek: only if the hub cheats you.
22:55:10gmaxwell:(otherwise you just ask it to release some of the funds to whatever destination you want)
22:57:02Taek:not so bad if the hub is small, but more of a problem if you've got 1 hub controlling 30% of the bitcoin. If hubs become commonplace, I think they'll suffer similar centralization problems to mining
22:57:23Taek:also not a problem if you only use hubs for micropayments
22:58:00gmaxwell:I'm not sure why you believe that, because the design is trustless and payments can cross hubs transitively, you should expect there to be a large number of them.
22:58:53Taek:Hubs take computational resources, they're signing and verifying one signature per transaction, and doing a small volume of network traffic
22:59:24Taek:Inconsequential if you're using hubs to buy coffee, but more of a problem if you're making a payment every time you visit a new page on a website
22:59:54gmaxwell:I think you're not thinking that through. ... it's not like having hundreds of thousands of computers do the same thing is an improvement there over one.
23:00:20gmaxwell:$random_desktop_cpu can do >50k signature verifications per second these days.
23:00:38Taek:hmm
23:01:30Taek:oh. The other problem is that hubs need connections to vendors, or some network of connections to vendors
23:03:41Taek:It's not really reasonable to expect a vendor to set up channels with 2000 different hubs. Instead they're likely to set up connections with the biggest N and call it a day
23:05:11Taek:I guess you could make something like a DHT of hubs.
23:10:33Taek:So if you have a DHT of hubs, and on average reaching a vendor takes 7 hops, each hub taking X%
23:10:46Taek:you've got room for mega-hub to offer speed savings
23:11:20Taek:plus, mega-hub might have a nicer, simpler way for websites to add support for mega-hub, while DHT support might involve more elbow grease
23:12:42Taek:I guess I'm grabbing at straws
23:15:51bramc:gmaxwell, I think it's possible to do unlinked transactions across hubs so you don't have to trust them
23:30:27bramc:I'm pretty sure that you can't get around the problem of a hub having to pledge to send. About the best you can get is that they can require that as much or more be pledged to them at the same time. And of course they can charge a fee.
23:32:58moa:gmaxwell: https://github.com/utxo/wheels/wiki payment channels projects links
23:37:49instagibbs:any extra info on Strawpay? claims to be hub model, not much there
23:38:22moa:no, they said source code is "coming soon"
23:38:39moa:iirc
23:41:28instagibbs:this and actual Coinshuffle implementations are the 2 things sorely needed imo.
23:43:07moa:seems there should be market demand for a well-implemented payments channel ...
23:44:39moa:Greenaddress has some elements but not a full implementation
23:45:11instagibbs:GA.it is essentially what Impulse is, heh
23:59:44bramc:moa, it isn't clear that there's much meaningful bitcoin commerce going on, hence the lack of demand for better bitcoin payment services