00:00:44nsh:or could add fee gossip to the network protocol but that would probably be gamed too
00:13:30bramc:leakypat, That depends on where you start and how quickly you raise
00:14:43bramc:If you start at 1/10 the fee you'll need, and raise by an average of 10% every round, then it will take, about 3 hours
00:26:38CodeShark:it would be nice to specify the range and increment up front...and then have the miner prove they got you the best price they could given the market...but miners could always cheat by inserting high fee transactions in their blocks
00:27:07bramc:CodeShark, Yes, exactly
00:28:01CodeShark:however...by doing this they crowd out their own blocks
00:28:09CodeShark:so there must be some equilibrium
00:28:49CodeShark:given a sufficiently small range and a sufficiently large volume, miners would rather be honest than cheat
00:29:50bramc:It's monopoly pricing if they set their own prices, if they game the system by making fake rates in earlier blocks to raise the amounts in later blocks then the amounts transaction rates could go up to based on fraud are unlmited
00:30:44CodeShark:they could only really set their own prices by forming a cartel, though - miners can already choose to block transactions at will
00:31:34bramc:Individual mining pools are big enough to pull it off
00:32:13CodeShark:so I think the conclusion is that any fee estimation must also use unconfirmed propagated transactions (mempool)
00:32:14bramc:If a single block with crazy prices were to cause prices to remain sky high for hours, then lots of pools are big enough to incentivize them to accept
00:32:56bramc:That would help a bit, but it's much safer to only trust your own local experience
00:33:26CodeShark:by own local experience you mean just your own attempts to send?
00:34:12CodeShark:I suppose you could "probe" the state of the network by sending a bunch of transactions with different fees and seeing when they confirm
00:34:29CodeShark:but that seems rather expensive...and still isn't particularly fast
00:34:40bramc:There's no point in probing until you have a payment you actually want to send
00:35:10CodeShark:but you might not want the real transaction to take hours
00:35:22CodeShark:so you probe a few hours before you'll make the real transaction
00:35:35CodeShark:but you still miss things like daily cycles and other high frequency phenomena
00:35:43bramc:No, you remember your last transaction which worked and start at half that rate
00:36:38bramc:Actually I did my math wrong - that one should be four hours
00:36:59CodeShark:well, three or four hours...still WAY too long
00:37:18bramc:and It's bad to increase by a random amount every time, if you're going to increase by 10% then your first value should be increased by a random amount in the range between 0 and 10%, and the following ones should go up by 10% exactly
00:37:29bramc:too long for what?
00:37:39CodeShark:to send a transaction
00:37:46bramc:You're free to make it go faster by doubling your fee every time
00:38:14bramc:But that costs more, and is likely to hit bad parts of the daily cycle (taking a while might have inherent advantages)
00:38:31CodeShark:unless you check the mempool, there's no data for you until the next block...which not only is relatively infrequent...it has large variance
00:39:00CodeShark:so I think any practical approach will have to check the mempool
00:39:24leakypat:bramc: I'm trying to picture the scenario, I guess it is systems bidding to settle large transactions?
00:39:45bramc:bitcoin payments are not what you call fast. If you want fast transactions, you use micropayment channels
00:41:06bramc:leakypat, In the long run it's likely to be that most transactions are large
00:41:15CodeShark:bramc: I think most users would prefer to pay a little extra but have more certainty in this - and if the cost for this is far more we have a serious problem
00:41:26leakypat:I agree with you on this stuff, yes
00:41:28bramc:Or maybe there will be small transactions, but they'll get settled at midnight PST when fees are a tenth what they are at other times
00:41:58leakypat:So who's might be a lightning channel or centralized micropayment system bidding to settle their payments
00:42:28leakypat:They just want the cheapest fee they can get and require settlement within x hours
00:42:28bramc:CodeShark, It isn't far more. If you compare doubling versus going up by 10% every time, the former will pay an average of an extra of 50% on the transaction fee
00:42:41bramc:er, 45% I mean, but due to noise it may be worse
00:43:13bramc:leakypat, micropayment channels can completely short circuit all of this stuff once their initial deposits are put down
00:43:49leakypat:The channels have to close to the blockchain at some point right?
00:44:09bramc:leakypat, When their net is settled out, yes
00:44:11leakypat:Or have the possibility to do so
00:44:25leakypat:Yes, that's what I was imagining
00:44:34sl01:is there any issue using centralized service(s) that provide APIs to wallet to get fee estimate information?
00:45:06sl01:and those services can use whaterver witchcraft they want to provide you best guess information on fee and conf times
00:45:15bramc:So for example I put down $100 because I intend to spend money. That's one transaction up front, then I spend no transaction fees until I've either sent a total of net $100 (people can send me money as well) or I want to take my money back out
00:45:15c0rw|afk:c0rw|afk is now known as c0rw|zZz
00:45:41bramc:sl01, We're discussing the mechanics of that
00:45:43leakypat:It will be on the miners interests to have a transparent fee market
00:46:10sl01:bramc: it seems more like you guys were discussing how a wallet can do this completely automated with no human interaction, aka not a "service"
00:46:22leakypat:Although , Hmm, there is no guarantee who is going to mine which block ... Interesting
00:46:31bramc:sl01, Well 'no requests' is a simple to implement API :-)
00:46:39sl01:which makes the problem much harder
00:46:46leakypat:So users aren't direct customers in that sense
00:46:51sl01:thats why i was just wondering if it might become 100x easier if you just "rely on a service"
00:47:15CodeShark:everything is a lot easier if you just "rely on a service"
00:47:19CodeShark:the challenge is how not to
00:47:27bramc:sl01, Not really harder, if you follow the scheme I suggested then there isn't much worry about you getting fleeced by whoever you made a request to lieing about how high fees are right now
00:47:33sl01:right, and for some things in bitcoin you dont want to, but this seems like the sort of thing its ok to
00:48:07bramc:sl01, Also prices are a bit dynamic. Even if a service is in principle good for one peer, it can get stuck in a feedback loop if everybody uses it
00:48:50sl01:but it seems like a service has a much better chance of giving dynamic/contextual fee estimates than some code built into clients
00:49:32bramc:sl01, Eh... sort of. It can possibly come up with more accurate amounts faster.
00:49:54bramc:sl01, But you'll always be able to get payments sent with lower transaction fees if you're willing to wait longer
00:50:17bramc:Possibly vasty different. It wouldn't surprise me to get a daily cycle of fees with swings of 10x
00:50:19CodeShark:I think we need to consider these as somewhat separate use cases
00:50:54CodeShark:if you want to optimize the fee as much as possible, that's one use case - if you want relatively predictable rates, that's another
00:51:34CodeShark:there could even be a market for "fee market makers" :p
00:52:46sl01:i mean big wallet sites like coinbase will likely do this themselves already without anyone asking them to, and probably publish their current fee estimate / conf time tradeoff or whatever you want to call it
00:53:07bramc:You can't have particularly steady rates if everybody wants their transactions to go through fast. The day/night cycle will really hit you
00:53:22bramc:Maybe smart wallets could recombine their dust in the middle of the night.
00:55:05CodeShark:the solution to leakypat's observation that users aren't direct consumers of miners is probably some sort of system with fee market makers
00:56:46CodeShark:hmm - it's tricky :)
00:58:09CodeShark:not sure I like the idea of entities having mining contracts on behalf of clients
00:58:25bramc:I'm proposing straight escalator as a starting point. It should be the beginning.
01:00:38CodeShark:so concretely, how does this work? you send a transaction...then wait for the next block. if your transaction was included, wonderful. if not, increase by x% and try again and wait until the next block?
01:01:41bramc:Yes that's the idea. For the first payment you ever make you start at a very low value and wait. For later payments you start at, say, half the transaction fee you paid last time.
01:02:18bramc:You take your starting amount, increase it by a random amount in the range 0-10%, that's the first amount you use. Then each block you don't get committed to after that you raise by 10%
01:03:07bramc:This is a very conservative approach which is optimizing for low fees over time, although its amounts of time aren't crazy
01:03:25CodeShark:with a fee market like this, accepting zero confirmation transactions becomes even more dangerous because no malicious intent is required from the buyer...they might just set the fee too low and it never makes it in
01:03:30nsh:apropos of nothing, i wonder if using coin-colouring you could allow groups of people or orgs to create a scarce enough asset that they can make practical use of deflation by burn
01:03:44sl01:do wallets need a new anti dos for this? can someone flood the network with a single tx by repeatedly sending it over and over against incrementing the fee by 1 satoshi each time?
01:04:18bramc:sl01, petertodd's code has a minimum increment
01:04:27sl01:ah cool, didnt see that
01:04:42bramc:Although there is an interesting question of how escalator might interact with the minimum increment, which I think is rather large right now
01:04:50nsh:(because by selectively destroying some combination of assets over another, you can effect relatively-arbitrary implicit one-to-many transactions amongst the scarce asset basket holders)
01:04:58bramc:One could reasonably argue that the minimum increment should be a percentage
01:05:49bramc:CodeShark, zeroconf is such a profoundly busted concept that it isn't worth worrying about. I need to write up a post on how to fleece fools who accept zeroconf
01:05:57CodeShark:yes, please do that
01:06:15CodeShark:I really wish people would stop claiming that we need to make Bitcoin integration possible for even idiots
01:07:22ggreer:oh, zero confirmations. for a second I thought you talking about zero configuration networking
01:08:16bramc:CodeShark, That will probably be the next one I post after the one I've already got written, no cookie for guessing what it's about.
01:08:16CodeShark:Bitcoin is based on a particular security model - it is what it is - if you make any assumptions beyond those you better know what you're doing...and have a good risk model. If not, you probably shouldn't be writing financial applications
01:09:44CodeShark:in infosec, "I've never gotten hacked before so it's probably OK to continue doing" is how many downfalls begin :)
01:10:24bramc:Yes, I for one had an unnecessarily negative view of bitcoin initially because I'd read people talking about it and they were using zeroconf and I had the impression that that was how it worked.
01:12:16CodeShark:there are certain use cases for zero conf that could have acceptable levels of risk - but I don't think that very many people accepting zero conf transactions even know what a risk model is
01:13:53CodeShark:and encouraging people to accept them just to "boost adoption" is folly
01:14:21CodeShark:might as well encourage people to use shitty passwords to encourage more "online banking"
01:17:07CodeShark:I don't even understand why this would be controversial
01:17:19CodeShark:other than complete myopia
01:17:37bramc:It isn't very controversial in this crowd, except for two people, you'd have to ask them why they like it
01:21:29jgarzik:c.f. the mailing list to which I responded
01:21:32leakypat:Bitcoin has been sold as send money anywhere in the world instantly for free
01:21:44jgarzik:plenty of business cases where zero conf works just fine -- it's in the realm of business risk
01:21:58jgarzik:physically shipping goods - just fine to initiate order @ 0-conf
01:22:13jgarzik:it doesn't go out the door until confirmed. order processing occurs in parallel with confirmations
01:22:22jgarzik:ditto subscriptions - the good can be revoked
01:22:49CodeShark:agree, jgarzik. point is the business risk needs to be properly assessed...and we shouldn't be encouraging any acceptance of zero confirmation transactions without these things being thought out
01:23:04petertodd:jgarzik: it'd really help this discussion if for those cases you said you weren't relying on zeroconf
01:23:22petertodd:jgarzik: I'm finding people thinking that zeroconf means someone other than the sender can cancel the tx
01:24:39CodeShark:basically, if you choose to accept unconfirmed transactions you can no longer rely on bitcoin's security model at all
01:24:46CodeShark:so you need to create another security model
01:24:58jgarzik:zero conf = zero security, by default
01:25:28jgarzik:It does not however mean zero security holistically, when including business risk and business case
01:25:32bramc:jgarzik, That isn't really zero conf, it's delaying the conf until later
01:25:52bramc:real zeroconf is letting you take money out of the ATM
01:26:31jgarzik:bramc, nevertheless, programmatically Some Things Happen at zero confirmations at legit merchants without introducing risk
01:27:20CodeShark:letting you take money out the ATM could still make sense with zero conf as long as the ATM has a deposit large enough to cover its losses...or some form of collateral...or a way of pressing charges...etc...but NONE of these rely on ANY of bitcoin's security
01:28:03leakypat:I suppose the question is, should the fact these external systems exists dictate how the Bitcoin protocol is developed?
01:28:03bramc:Also authorizing the customer to walk out of the store with the goods
01:28:07jgarzik:i.e. some businesses get ID and/or take pictures of their customers, which provides recourse and mitigate risk
01:28:23jgarzik:amusingly to address chargeback fraud primarily
01:28:58jgarzik:leakypat, dictate - no - however it is true that you cannot just nuke zero-conf without a What To Transition To plan
01:29:17jgarzik:ie. no mainstream wallet yet supports even 2-way payment channels
01:30:00bramc:jgarzik, Arguably it only matters for vendors of ATMs and payment processors who rely on it
01:30:01jgarzik:Just complaining or nuking does nothing to help users today
01:31:13jgarzik:bramc, CodeShark: FWIW I encourage people to write about zero conf and point out its low security - just do so with a holistic approach, noting there are layers of business security as well as bitcoin security that mitigate this decision.
01:32:20bramc:jgarzik, If a payment processor decides to use zeroconf and completely rely on non-bitcoin security measures for their actual security, then that's fine for them, credit cards do seem to work
01:32:46bramc:jgarzik, The points that zeroconf has no real security and what should be done about it are two separate things
01:32:55jgarzik:bramc, e.g. You seem to have missed the relevant mailing list discussion
01:33:02jgarzik:that CodeShark participated in
01:33:22petertodd:well, this is rehashing the usual... but the big risk with the "no sense making things worse" approach is that we stand a very real risk of services failing to improve on this situation, and instead adopting easier ways out like getting hashing power contracts, which in turn can lead to those contracts saying "reorg double-spend blocks out of the blockchain"
01:33:55petertodd:the only entitites who have any hope right now of getting anywhere near safe zeroconf acceptance are a few big payment processors - if more than a handful did this the network would collapse anyway because it's a sybil attack on the p2p layer
01:35:23bramc:I'm not on the mailing list
01:35:37CodeShark:it just moved today
01:36:21CodeShark:still not 100% it's all fully working yet...but we'll see :)
01:37:27CodeShark:I'd be happy to write more on this topic, jgarzik. I think people sometimes get too extreme on both sides
01:38:03bramc:I just looked up the mailing list and was going to ask why it's on sourceforge
01:41:13CodeShark:security isn't really about a few crypto algorithms, schemes, and protocols - these are merely tools. it's about managing risk.
01:42:29CodeShark:if you rely on someone else's security model, it's best no to stray too far from the assumptions underlying their design - and if you do, you better know what you're doing :)
01:43:07petertodd:CodeShark: ...and whats the best way to manage risk in Bitcoin? if you're a regulated entitiy, having legal contracts with hashing power is a good idea with little direct downside
01:44:07jgarzik:petertodd's favorite theoretical bug-a-boo
01:44:24CodeShark:well, it is a potentially serious problem
01:44:28petertodd:jgarzik: hang around bankers more often :)
01:44:39petertodd:jgarzik: and regulators
01:45:43petertodd:while the big visibility public regulatory efforts are mostly focused on endpoints right now, coming down the pipeline is efforts to regulate the network itself
01:47:38CodeShark:we already have far more efficient technology for these kinds of applications...and the entities here don't even need to worry about hashing power and PoW and stuff like that - lol
01:47:43CodeShark:why are they killing Bitcoin to do this?
01:48:02petertodd:CodeShark: enforcing AML/KYC - remember that these are the people who are happy to stop hawala if they can find a way
01:48:27bramc:Yeah, umm, bitcoin-backed credit cards aren't too exciting if they're just ordinary credit cards with bitcoin headaches added on
01:48:51petertodd:CodeShark: it's not about alternatives, is that from their perspective Bitcoin shouldn't exist in its current form (where their==regulators)
01:48:52CodeShark:if you're a regulated entity with contracts and all that, why use a trustless p2p protocol at all?
01:49:50petertodd:CodeShark: equally, for many of the regulated entities int he bitcoin space, a regulated Bitcoin is arguably a positive thing, as it makes life easier for them dealing with said regulators - the fact that once sent bitcoins can be resent to anyone is a major sticking point for many banks in their dealings with bitcoin companies
01:55:02CodeShark:Bitcoin RIP...2009-20??
01:55:22petertodd:CodeShark: eventually the sun explodes and we all die - I'll make that prediction :P
01:55:23bramc:The next step after having a heavily regulated bitcoin is to dispense with mining and have a central database, then have law enforcement be able to make retroactive changes to it...
01:57:28petertodd:bramc: ah, but look at it from the perspective of the regulators: the point is to keep bitcoin in this weird pseudo-useful state, such that no competitors are going to (easily) arise, because it's still useful, kinda
01:57:41petertodd:bramc: one of those things where you don't be too restrictive
01:58:48bramc:petertodd, it also doesn't take much of a conspiracy mindset to think that many of the wtf-inducing developer behaviors are happening because they're aligned with those regulatory interests
01:59:24petertodd:bramc: not at all - heck, last week I helped write a paper arguing against the crazy "one global blockchain for everything w/ AML/KYC" dreams people in this space are having
01:59:37petertodd:bramc: the blocksize issue *does* come up in these discussions
02:00:34petertodd:bramc: one of the arguments we used in that paper (and presentation) was talking about the dangerous data leak potentials of such schemes - the recent OPM hack was a very useful talking point there
02:01:10petertodd:bramc: (this was the conf/workshop: http://blockchainworkshops.org/)
02:01:35bramc:KYC is a ludicrously expensive program for the actual amount of law enforcement it results in
02:02:59petertodd:bramc: indeed
02:22:45bramc:jgarzik, The subtext for discussing zeroconf on here isn't so much whether zeroconf should be allowed by some vendors in some contexts, it's whether zeroconf is a good reason for holding up accepting transaction malleability
02:24:20bramc:err, I mean replace by fee, I guess that's the term of art for actually malleating transactions in practice
02:24:34bramc:malleating by changing the outputs I mean
02:26:11bramc:Arguably now that one major pool is accepting rbf the jig is up and everyone else will just follow
02:31:55leakypat:It's interesting, every Bitcoin transaction is see/do out in the wild doesn't wait for confirmation, but this is essential for most people to start using it, and the "instant" part of it has been sold heavily, not just by companies but also by bitcoin evangelists
02:32:36leakypat:In one sense a lot of companies / people are pushing adoption to the wrong use case
02:33:03jgarzik:bramc, FSS RBF, not full RBF
02:33:51moa:leakypat: only misinformed people were 'selling' bitcoin as instant
02:33:56jgarzik:bramc, https://github.com/bitcoin/bitcoin/pull/6176
02:34:25leakypat:moa: I know, but that's most people
02:34:32moa:or duplicitous maybe
02:34:32jgarzik:petertodd, FYI I'm meeting with Coinalytics... should be interesting
02:34:59jgarzik:petertodd, FYI I'm meeting with Coinalytics... should be interesting
02:35:18jgarzik:* jgarzik kicks xchat
02:35:22petertodd:jgarzik: yeah, I know jonathan levin from coinalysis
02:35:30petertodd:jgarzik: or is there now a Coinalytics?!
02:36:46leakypat:How will layer 2 networks play out for these kind of companies I wonder
02:37:08leakypat:I'm still sketchy on the privacy of lightning etc.
02:37:12jgarzik:petertodd, http://coinalytics.co
02:37:18jgarzik:petertodd, they are doing something w/ AML too
02:37:21jgarzik:don't know what
02:37:37petertodd:jgarzik: god help us... purely on the basis of shit names :)
02:37:51yossef:yossef has left #bitcoin-wizards
02:38:47moa:... and ye shall know them by there fruit
02:39:30bramc:leakypat, the privacy implications of lightning are complicated. It avoids broadcasting some information to the entire world, but gives more more detailed information to a few select parties.
02:40:28moa:hide in the weeds versus hide in the crowds
02:41:18leakypat:bramc eg. If I hop to user c via user b? User b will see my transactions
02:41:34petertodd:bramc: note how lightning is not unlike Tor in this respect when you think about it
02:41:34bramc:wait, isn't FSS policy of requiring all outputs to get an equal or greater amount backwards? You need for the fee to go up, and that requires some output be lower, unless you add a new input...
02:42:02bramc:petertodd, Yes you could in principle provide onion payment services through lightning
02:42:36bramc:leakypat, Yeah that's the idea
02:42:45leakypat:bramc: you add new inputs and outputs as required
02:42:56leakypat:As long as the original ones are still there
02:42:59petertodd:bramc: exactly! :)
02:43:22bramc:That makes FSS a disaster for increasing fees to make payments go through, because it requires transactions keep being made larger as fees go up
02:43:24petertodd:bramc: equally, hub-and-spoke can do privacy tech like chaum tokens pretty easily and obviously
02:43:32petertodd:bramc: yeah, that's kinda ugly
02:43:41leakypat:bramc: yes
02:44:43bramc:For fee increases you want the exact opposite, that outputs can only go down and no new outputs can be added
02:45:37leakypat:Yeah really you would just drop the value of your change output, but which one is the change?
02:45:44bramc:Maybe you want a heuristic that the last output is the 'change' output, and that's the only one which can change at all
02:45:47petertodd:leakypat: whichever one you want it to be ;)
02:45:54jgarzik:bramc, which sucks for privacy
02:48:00bramc:jgarzik, Fee increasing is not so hot for privacy in general, it's obvious that the reduced output is the one which is the change output
02:48:14bramc:jgarzik, And forcing a new input to be added is arguably even worse
02:49:27petertodd:bramc: yeah, yet another reason why estimating the fee correctly in the first place is ideal
02:49:41bramc:It's funny that a reasonable security argument can be made for seemingly opposite heuristics. If nothing can go down then nobody gets stiffed. If nothing can go up then there's no kickback.
02:50:58bramc:petertodd, I think trying to always estimate the fee correctly in the first place is a foolish goal. If there's a system for estimating fees based on previous fees, then it can end up estimating fees based only on its own outputs, which is a problem.
02:51:12bramc:I mean, it can wind up in bizarre and incorrect feedback loops.
02:51:41petertodd:bramc: indeed, which fss-rbf can help with, as it makes it much more reasonable to set your feedback loop to tend towards fees going down
02:52:05petertodd:bramc: making a bad estimate once in awhile isn't such a big deal
02:52:56bramc:petertodd, Thus far I haven't seen even a good argument for what the method of estimation should be, and I don't understand your point about fss-rbf, it seems to go for maximum pain on fee changes.
02:53:56petertodd:bramc: the point with fss-rbf is that it's possible to actually deploy in the current political environment :) heck, greenaddress said on list the other day that they'll look into how to do both simultaneously when raising fees
02:54:21petertodd:bramc: (f2pool implementing full-rbf was kinda surprising to me actually)
02:54:56bramc:didn't jgarzik just say that f2pool only implemented fss-rbf?
02:55:20jgarzik:bramc, they went full first, then backed down to fuss
02:55:20petertodd:bramc: part of my thinking re: my long post on the topic was that if they had made a mistake about what they did, I wanted to get out there as fast as possible to take the blame for it
02:55:29jgarzik:* jgarzik kicks autocorrect
02:55:40jgarzik:bramc, they went full first, then backed down to fss
02:55:42petertodd:bramc: (they're chinese, so there can be language barriers and misunderstandings obviously)
02:55:50leakypat:So full rbf is what is required to do the fee adjustments in practice, otherwise you are adjusting transaction size and leaking privacy
02:55:52petertodd:bramc: right now I think they knew exactly what they were doing :)
02:56:16petertodd:leakypat: to be exact, the extra input is what is bad for privacy - you'll leak what your change output is
02:56:17jgarzik:leakypat, nothing about RBF is privacy enhancing... you leak privacy no matter what you do
02:56:36petertodd:leakypat: fss-rbf is worse than rbf, but they're both worse than guessing right in the first place
02:56:49jgarzik:RBF is an outlier action
02:56:55jgarzik:makes you stick out in the noise
02:57:17bramc:the big problem with fss-rbf is that you're wasting transaction space while increasing your fee
02:57:26petertodd:leakypat: though one good thing is that there are a whole bunch of other ways to use RBF - e.g. for paying additional people after the fact, and some of them are indistinguishable from each other. Equally, you can choose to spend a bit more in fees to complicate the anlysis.
02:57:53petertodd:bramc: did you see my careful analysis on the topic? I worked out exact numbers for full-rbf, fss-rbf, and cpfp methods of increasing fees
02:58:04bramc:petertodd, No I did not
02:58:30petertodd:bramc: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
02:58:45petertodd:bramc: and also http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07868.html
02:58:50bramc:All this discussion is a good example of how you actually need to hit the transaction limit for things to actually get solved
02:59:17petertodd:bramc: which we've done! changetip is one such example
03:01:43bramc:petertodd, I don't see how changetip fixes anything btc-related other than just avoiding it completely
03:02:07petertodd:bramc: prior to changetip there were on-chain tipping services, where much of the tip was eaten up by fees
03:02:16petertodd:bramc: it might not be a pretty solution, but it very much is a solution
03:02:50petertodd:bramc: for a service like changetip where the average person might have $20 max deposited, there's just not much demand for security
03:02:53leakypat:* leakypat wonders if mining will end up with cartel style fee pricing
03:03:04petertodd:leakypat: explain?
03:03:26leakypat:They just come to a general agreement of what the fees should be and all play ball
03:03:49petertodd:leakypat: if they enforced that, they'd need to 51% attack other miners...
03:04:13bramc:leakypat, depending on how things set their fees there might be some of that, the idea with fee setting algorithms is to try to make it so that as long as some miners are breaking ranks people are okay
03:04:31petertodd:leakypat: note how jgarzik's miner vote proposal is not unlike a gentlemanly and safe way of negotiating such a cartel
03:04:45leakypat:petertodd: I don't understand the 51% attack thing..?
03:04:51bramc:petertodd, That isn't quite so simple. Depending on the algorithms used to set the prices, it's entirely plausible that even a minority miner could find it useful to throw in a lot of self-payments
03:05:29petertodd:leakypat: if 75% of miners play ball, and the other 25% don't... then what? (esp. in an unlimited blocksize scenario)
03:05:54petertodd:bramc: you're probably not familiar with the sorrid history of gavin's fee estimator... :)
03:06:24jgarzik:petertodd, sorry, you continue to vastly oversimplify BIP 100 to the point of being inaccurate
03:06:27petertodd:bramc: this isn't something you can fully automate anyway - any automatic algorithm will have cases where the fee is unreasonable, and the human being sending the payment would probably just wait
03:06:38leakypat:petertodd: I see
03:06:55bramc:petertodd, I am not. From that comment it sounds like it's about as troubled as I'd expect.
03:07:52bramc:petertodd, I'd argue that you always want *some* fraction of all wallets to be doing at least some amount of escalator, or everything is busted
03:07:59petertodd:bramc: so version #1 of it estimated fees based on fees in blocks; version #2 estimated fees based on the mempool; the latter actually had an exploit where based on just a single high-fee tx it would estimate a ridiculously high fee and you could wind up with an empty wallet
03:08:18bramc:Really, even with fss, they'll be doing that, because anyone with any sense will let their old transaction wait a while to see if it goes through
03:09:02petertodd:bramc: indeed. More importantly, in periods of high demand there are all kinds of ways to determine what fee might be reasonable - e.g. look on twitter
03:09:24petertodd:bramc: no need to let perfect be the enemy of better here - providing users a last ditch option to get their tx mined is already categorically better than giving them nothing at all
03:10:22bramc:petertodd, I've foreseen those problems and didn't even have to code them up to realize it :-P
03:10:57petertodd:bramc: now from a "-wizards" point of view, fee estimation and rbf has an interesting issue that it's very hard to come up with a reasonable way to know if you're being sybil attacked... but IMO a reasonable answer is to be very non-wizardly and rely on central servers for version #0 of it :)
03:11:22bramc:petertodd, I wouldn't say that the escalator approach is 'perfect', but it's conservative, in that it always works and always behaves reasonably, albeit at the expense of transaction speed
03:12:15bramc:Unfortunately it doesn't work at all in fss-rbf world
03:12:35petertodd:bramc: well, a reasonable approach also is if I'm sending $5,000 I might just throw in another $1 because I don't really care :)
03:13:45bramc:Yes that's fine although presumably a large number of transactions are on the edge
03:13:51petertodd:bramc: meanwhile it took a long time before, say, Aschildbach's android wallet even let you see fees *at all* - and it's still just a "econ" "normal" "priority" thing IIRC :(
03:13:56bramc:And also I'm guessing the daily cycle will be quite prominent
03:14:43bramc:petertodd, *insert rant about how the ethos of bitcoin is that broken software will be weeded out and die here*
03:15:25petertodd:keep in mind that things like securing financial records may help dampen out some of those cycles by providing more non-time-sensitive usecases
03:16:07bramc:Presumably the not-time-sensitive applications will need different fee setting algorithms
03:16:08petertodd:equally, many of those use-cases can have very strong incentives to use the best chain out there, and are also sufficiently well fudned to happily pay $10+ fees
03:18:55bramc:The only way to find out is to have real fees with algorithms which set the fees properly and see what happens
03:19:14bramc:A bit advantage of escalator is that it clearly works properly. The stuff about using mempool seems dubious.
03:19:45petertodd:I'm genuinely surprised no-one has done some pretty graphs of this stuff like you see for bid-ask spreads in btc markets
03:32:32jgarzik:and insert block size debate at this point :)
03:32:39jgarzik:no real fees without block pressure
03:32:48jgarzik:economic policy -- for years -- has been to suppress fee pressure
03:43:48bramc:What does cpfp stand for?
03:45:42jgarzik:bramc, Child Pays For Parent. A secondary transaction boosts the priority of the primary transaction. 2nd tx adds fees to 1st.
03:45:42bramc:jgarzik, You keep saying that but I'm not sure what you're referring to, other than the raising of the soft limit
03:46:19bramc:Oh right. cpfp has overhead and may need to increase its own fee, which runs into the same issues
03:46:37jgarzik:bramc, "The only way to find out is to have real fees" -- noting that will not happen, or be more difficult, in current economic regime
03:47:32leakypat:CPFP is worse because you have to pay twice too
03:48:13bramc:cpfp can be made radically more space efficient if an opcode is added to assert that a particular transaction is not in the current set, then a third party transaction can make a long list of those referring to grandparents
03:48:38bramc:jgarzik, Huh? There's a transaction rate limit and it hasn't been hit yet. When it is hit there will be pressure
03:49:21bramc:Unless a hard fork is done to make full nodes continue to heavily subsidize everybody else as part of the united socialist democratic republic of bitcoin
03:49:31jgarzik:bramc, The block size limit, which implies the transaction rate limit, yes. The current community debate is about raising that limit.
03:49:43jgarzik:bramc, when that happens there will be little fee pressure
03:49:52jgarzik:bramc, which has been the case historically for years
03:50:09jgarzik:bramc, anytime fee pressure approaches, people lobby miners to raise their soft limit, eliminating fee pressure
03:50:13bramc:jgarzik, I for one am very strongly against raising that limit, for a number of reasons
03:52:02bramc:One of them being that low transaction fees are a bad thing unto themselves
03:53:20moa:anybody know what a BIP 47 payment code actually looks like?
03:53:23moa:i.e. data format?
03:53:24jgarzik:bramc, It is an economic policy choice, to subsidize adoption. There are merits and demerits. It prevents a healthy fee market from developing, for example. Changing the block size limit reboots the fee market.
03:53:51jgarzik:bramc, You don't want to be penny wise and pound foolish, optimizing for the short term at the cost of the long term.
03:54:25bramc:jgarzik, Raising the limit is the thing which optimizes for the short term at the expense of the long term
03:55:45bramc:Long term it's lower mining rewards and higher costs of running full nodes, and all the fee handling stuff will have to be done eventually anyway
03:56:24bramc:Plus damage to the credibility of the claim that bitcoin isn't centrally controlled
03:56:33jgarzik:bramc, that fails to take into account people who look at bitcoin, run numbers, and abandon plans to use it before they begin. Bitcoin works just fine at high tx rates.
03:56:40jgarzik:bramc, i.e. externalities
03:57:16bramc:jgarzik, A single order of magnitude increase changes very few of those calculations.
03:58:41bramc:Another short term thing: only having fss-rbf instead of full rbf. That's to protect zeroconf, and even with your semantic point about zeroconf can be used for something in some systems, using fss-rbf doesn't make it any more useful.
04:03:41jgarzik:I never claimed fss-rbf makes zero conf more useful. I only claim full-rbf is overly disruptive and anti-social in the current ecosystem, making fraud much easier.
04:04:02bramc:I meant to say that full-rbf doesn't make it less useful
04:04:04jgarzik:From that narrow perspective, fss-rbf is simply less damaging
04:06:20bramc:All that zeroconf really does is demonstrate that the supposed signer really does have control of the key. Which is something. But further advantages about miners not doing rbf are mostly illusory and temporary
04:07:20jgarzik:bramc, agree with the latter statement (temporary)
04:07:36jgarzik:bramc, It very much depends on the real world risk scenario whether it is sane or not
04:08:37jgarzik:In fact, I think a timeline for deploying full-RBF would help focus people
04:09:02jgarzik:Wallet software and other stuff needs much work still
04:09:07bramc:That is something I would be fine with
04:14:10petertodd:jgarzik: potentially could be done with a Bitcoin Core release that enabled full-RBF at a specific date in the future
04:16:10jgarzik:petertodd, I'm OK with that
04:16:43jgarzik:petertodd, Decidedly -not- OK with surprise rollouts the community is not prepared for
04:17:03bramc:Wow, we're having actual productive discussion
04:17:10petertodd:jgarzik: rough guess, how far into the future?
04:17:54jgarzik:petertodd, rough guess? 6 months too short, longer than 12 months probably too long
04:18:18petertodd:jgarzik: 9 months it is :)
04:18:29bramc:9 months sounds great
04:18:41jgarzik:Have to upgrade -all- wallet software, websites, decentralized wallets, etc.
04:18:48jgarzik:Have to endorse a useful solution like CLTV+paychan
04:19:09jgarzik:ie. wallet software authors need to know a direction other than "panic!"
04:19:46petertodd:How far away are we from releasing v0.11.0 do we think? Also, is this change too big to go into v0.11.0?
04:20:07bramc:uh, dumb question, what is cltv?
04:20:35petertodd:bramc: CHECKLOCKTIMEVERIFY - BIP65 - my baby :)
04:20:55bramc:Also, the thing which full rbf breaks is zeroconf, not transaction fee pressure
04:21:15bramc:petertodd, Is that including relative now? Is it in utxos or transactions or both?
04:21:30petertodd:bramc: just absolute, to keep the # of lines of code changed down
04:21:45petertodd:bramc: I 100% agree relative would be nice, but I wanted something *really* simple as a first-effort
04:22:04petertodd:bramc: I've literally given more interviews about CLTV than there are lines of code in CLTV...
04:22:09moa:CLTV is going into v0.11.0 ?
04:22:16jgarzik:bramc, CLTV is _huge_. Freeze funds on-chain until X time.
04:22:19jgarzik:lots of uses
04:22:31bramc:petertodd, cltv in utxos is the least important thing, because cltv is already in transactions
04:22:36petertodd:moa: well, it got a bunch of review by maaku for elements, which helps
04:23:02petertodd:moa: we don't actually have the exact deployment method figured out - hoping sipa will get some code soon re: his nVersion's soft-fork scheme
04:23:12bramc:Although I agree that it's the simplest thing
04:23:21jgarzik:CLTV prevents duress risk in holding funds. CLTV secures refunds. CLTV enables provably committing X amount of funds - you then provide that proof to a third party.
04:23:26jgarzik:Much better than proof-of-burn.
04:23:31jgarzik:CLTV enables pay-to-future miner.
04:23:42jgarzik:(freeze an anyone-can-spend TX)
04:23:58jgarzik:CLTV must be integrated ASAP. :)
04:24:01petertodd:jgarzik: CLTV is both a floor wax and a dessert topping!
04:24:17jgarzik:and sex lube too
04:24:17moa:jgarzik: california loosens the tongue
04:24:18bramc:jgarzik, A bunch of its use cases can technically speaking be hacked together with the existing timelock on transactions. Not that I'm against integrating it asap :-)
04:24:38bramc:jgarzik, You're in the bay area now? I'm headquartered here.
04:25:01jgarzik:bramc, agree -- the main issue is that locktime transactions are not relayed across the network, nor remembered in mempools. easy DoS + malleate.
04:25:10jgarzik:gotta get it into the chain.
04:25:14CodeShark:making timelock part of the script is far more powerful
04:25:29bramc:Although relative timelock, both in transactions and utxos, should get in asap as well.
04:26:04petertodd:jgarzik: +1
04:26:11petertodd:jgarzik: (the sex lube bit)
04:26:22CodeShark:gotta work on the branding
04:26:32jgarzik:bramc, I'm in the Bay area every other week, almost. NASA & space investors are here. I'm lofting a network of 24 nano-satellites carrying the blockchain into Low Earth Orbit.
04:26:50jgarzik:based in Atlanta
04:26:53bramc:jgarzik, I can't tell if that's satire
04:26:59jgarzik:bramc, nope 100% truth
04:27:54bramc:jgarzik, I... I can't... I don't know what to say
04:28:06jgarzik:bramc, rackspace in space
04:28:26bramc:Because latencies on earth are too low?
04:30:01jgarzik:bramc, hehe actually with some of the space networks being built it will eventually be faster than terrestrial fibre optic, using space optical comms.
04:30:46bramc:The latencies on earth are mostly incurred at the local ISP and by limitations in the speed of light.
04:31:16CodeShark:you don't really gain much in the latter, do you?
04:31:19jgarzik:bramc, But no, telecom is not our gig. There are in-space customers coming down the pipe, plus high security customers, plus space enthusiasts.
04:31:33jgarzik:bramc, yes - it's the hops - in space has fewer optical hops at speed of light
04:31:49jgarzik:easier to repair than sea cables too
04:32:21bramc:space is also fairly high up there. At least for geosync satellites once you've bounced the signal back to earth you've already lost
04:32:40CodeShark:I think he said LEO
04:32:55KFl6WxEUI1Zbp2:jgarzik: don't blockchain satellites also allow people to avoid certain miner attacks?
04:32:56jgarzik:under the van allen rad belts
04:33:24CodeShark:geostationary satellites are good for high throughput/high latency
04:33:40bramc:for LEO it depends on exactly how high
04:33:54jgarzik:geostationary are way up there, higher earth orbit, higher power, higher rad shielding, higher launch costs, higher latency
04:34:06moa:bramc: space money jurisidiction has low latency dev times
04:34:08CodeShark:but the simpler the math :)
04:34:33moa:he's the CEO of LEO
04:35:01CodeShark:I'm still not 100% sure I fully grok the vision, jgarzik
04:35:11KFl6WxEUI1Zbp2:jgarzik was that 'correct' directed at me or CodeShark
04:35:20CodeShark:I mean, I understand that satellites and space are cool and all
04:35:26jgarzik:CodeShark, yeah I can't say too much in public about the stealth mode bits ;p
04:36:00CodeShark:but to an outside observer it just looks like a very expensive way to do something relatively simple
04:36:30jgarzik:the public gets the basic open source satellite design, but not the biz details. http://dunveganspace.com/assets/bitsat-design-pdr.pdf
04:36:35bramc:CodeShark, But it's spaaaaaace!
04:36:53jgarzik:KFl6WxEUI1Zbp2, both! :)
04:37:14jgarzik:Let's just say you can do a lot with worldwide global broadcast network
04:37:22zooko:lol ; I love this channel. Especially the bit about "CTLV must be deployed!"
04:37:36zooko:I think I might have played a role in getting petertodd started on CTLV.
04:38:30KFl6WxEUI1Zbp2:jgarzik exactly, every other communication network runs sats it would be highly unlikely, from a technological perspective, that there wouldn't be _some_ advantage for bitcoin sat
04:39:20jgarzik:all other sats are "dumb" repeaters with no trustless crypto security vis the ground
04:39:53KFl6WxEUI1Zbp2:all other ^bitcoin sats?
04:39:59bramc:The best use of super low latency communications is price arbitrage between the london and nyc stock exchanges
04:40:38jgarzik:all other satellites besides my own BitSats
04:42:24moa:jgarzik: could i reserve some dedicated hardware on a BitSat ... sole access, etc?
04:43:12CodeShark:how much to rent a rack? :)
04:43:38jgarzik:moa: In theory yes - probably outside your budget though :) - See MSRP: http://dunveganspace.com/assets/bitsat-infosheet.pdf
04:44:01moa:that's presumptious but thanx
04:44:18CodeShark:$19 million for a 24 unit constellation - what a deal!
04:44:20jgarzik:some customers are looking to put custom circuits on board
04:44:42jgarzik:CodeShark, in space terms it is 1000x cheaper than 10 years ago for same capability :)
04:44:50CodeShark:yes, so are CPUs :p
04:45:00moa:neilsen's law in space too?
04:45:12KFl6WxEUI1Zbp2:moa lol
04:45:25jgarzik:yep. same cost curves are applying to space now. launch & spacecraft costs fell exponentially, and will continue another iteration.
04:46:12bramc:A lot of those price falls haven't been new technology so much as the legacy space launch system finally getting replaced
04:48:01zooko:goodnight folks. Don't break the internet before I wake up.
04:49:08jgarzik:bramc, that's one part
04:49:17moa:i'm intrigued by the 'Dunvegan' name origin ... sounds irish
04:49:35jgarzik:bramc, legacy replacement + reuseable + increased competition for smallsat launches + ride-share
04:50:11jgarzik:moa: Dunvegan Castle in Scotland
04:50:13bramc:jgarzik, Yes there's new tech, but what we're seeing now isn't so much new tech in the last 10 years as all the new tech since the 60s hitting at once
04:50:16CodeShark:when does economy of scale start to kick in?
04:50:51jgarzik:CodeShark, "soon but not yet"
04:51:10jgarzik:when Elon's or Branson's 1000+ constellations start going up, then you see real volume
04:51:17moa:yeah when SpaceX gets true private competitor
04:52:00jgarzik:Of course must be wary of https://en.wikipedia.org/wiki/Kessler_syndrome Everybody has a deorbit plan these days.
04:52:15bramc:The main fundamental limit on costs of getting stuff into space has to do with the fuel used in the rocket, that's around $500/pound if I recall correctly
04:52:48CodeShark:what about a space elevator?
04:53:06moa:jgarzik: that's topical, you probably seen this link http://science.slashdot.org/story/15/06/19/1623200/orbiting-rest-stops-could-repair-crumbling-satellites
04:53:06CodeShark:or other form of propulsion where the fuel doesn't need to be carried on board
04:53:17rasengan:what if it was cheap back in the day but the lack of transparency allowed funds to be funneled into peoples pockets thru a space program which was believable to be an entity thst would spend a lot due to thr collosal task at hand
04:53:19bramc:space elevator doesn't work from a cost standpoint. Skylon does work in principle.
04:53:28jgarzik:bramc, yes and no -- currently rockets are built and then thrown away. Imagine costs involved in building a one-time-use 747 airplane.
04:53:36moa:orbital service stations could change craft design
04:53:42jgarzik:fuel itself is cheap
04:53:52jgarzik:CodeShark, long way off
04:54:04jgarzik:reuseable rockets bring launch costs down to that of a first class ticket to Paris
04:54:23bramc:jgarzik, Getting the second stage to reuse might be a bit of a pipe dream. The first stage should be doable. Also a much bigger thing getting reused
04:54:25jgarzik:think scale, too -- smallsat rockets are much smaller. One company is using high altitude balloons + old missiles.
04:54:57jgarzik:airplanes and balloons already exist for a usable first stage
04:55:09bramc:jgarzik, When I ran the numbers on high altitude balloons they didn't seem even vaguely promising, they don't get you very high or very fast
04:55:21CodeShark:certainly not very fast
04:55:26CodeShark:but they can get you pretty high
04:55:44bramc:CodeShark, Not really so high, the atmosphere gets thin fairly quickly
04:57:34CodeShark:looks like the unmanned gas balloon record is 53km
04:57:36bramc:CodeShark, Yeah last I ran numbers getting 100km in the air didn't seem like much of a boost
04:57:50moa:if the air's thin then accelerating the craft is a lot cheaper
04:58:03moa:and speed is ultimately what you want
04:59:10bramc:It all boils down to how much less gas you need to carry in order to get into orbit. It doesn't take much gas to get 100km in the air, but the quadratic increase in gas amounts for getting into orbit can make even small boosts helpful
04:59:49jgarzik:moa: yep
05:00:16moa:well every pound less fuel is an additional pound of payload
05:00:43bramc:moa, it's more than that because fuel is used to carry up other fuel. Most of the fuel on a space rocket is used for lifting other fuel.
05:01:10moa:yes, lifting and accelerating
05:01:10bramc:It also may help to start in a thinner atmosphere as you said because you can accelerate faster without destroying the rocket
05:01:40moa:you have less drag friction so it takes less fuel
05:01:59ggreer:rockets lose what, 2km/sec ∆v due to gravity losses and atmosphere? it's significant, but not a game-changer
05:03:08moa:https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation ... now we're really OT
05:06:31bramc:No that isn't the issue, it's that what you really want to do is get up to full speed instantly so that you aren't wasting fuel to lift other fuel. The problem is that those sorts of forces (a) destroy everything on board and (b) cause you to get destroyed by the atmosphere if you're too low
05:07:20CodeShark:unless you're at relativistic speeds, doesn't F=ma continue to hold?
05:08:21CodeShark:and doesn't conservation of energy imply that it doesn't matter how quickly you accelerate? (again, assuming nonrelativistic speeds)
05:09:09bramc:CodeShark, You've got gravity dragging on you the whole time. The quicker you're moving fast enough to not have to waste fuel counteracting gravity, the less of it you waste
05:09:26ggreer:bramc's saying you could get around the rocket equation if you didn't have to carry your fuel up with you. that means an explosion (or a cannon)
05:09:42CodeShark:hmmm - but total energy (kinetic + potential) is also conserved
05:10:15CodeShark:I guess the catch here is that m is changing
05:10:20bramc:CodeShark, Unfortunately you've got this giant momentum sink called 'the earth'
05:11:33bramc:Ironically nuclear rockets have a lot of problems because they tend to put out energy too slowly or, ahem, too quickly.
05:12:14ThinThread:what about https://en.wikipedia.org/wiki/EmDrive
05:12:45ggreer:the constraints for getting off the earth are pretty tricky. you need high energy density, low capital cost, political feasibility, and thrust/weight ratio >> 1
05:12:50bramc:Anyway, somewhat back on topic: I don't get the point of bitcoin in space, although I do somewhat see the point of LEO internet connectivity if it's done absolutely right and low latency is critically important, but satellites at less than $1 million/satellite are a great deal and undoubtedly good for a lot of stuff.
05:13:19ggreer:yeah. secondary payloads are pretty cheap these days. imagine how cheap they'll be when rockets are reusable
05:13:21jgarzik:yep :)
05:13:49jgarzik:and note that $1M is to-orbit price. includes a much-cheaper spacecraft, plus launch, plus insurance and other costs
05:14:05jgarzik:you can reduce a lot of that with volume in various places
05:14:10bramc:The miniaturization of satellites themselves helped a lot by the miniaturization of computers and cameras helps a lot of course
05:14:13jgarzik:that's the one-off price
05:14:49jgarzik:open source + commodity parts lowers costs greatly
05:15:18bramc:jgarzik, Also literally ditching designs which were either from the 60s or based on using contractors in a particular senator's home state
05:15:28ggreer:tiny sats in LEO make sense. they don't have to be reliable; just launch a bunch of them. they can basically be smartphones with a few add-ons. a few years later when they're obsolete or broken, they re-enter and burn up
05:15:39jgarzik:bramc, indeed, that saves quite a bit :)
05:15:44bramc:Also dumping the manned program helps a lot
05:27:07maaku:bramc: ?
05:28:57maaku:manned space has done more than just about anything in bringing down cost per lb
05:29:18maaku:you only *need* heavy-lift for manned programmes
05:33:42bramc:maaku, It's a lot cheaper to not include the goldfish bowl
05:35:19CodeShark:it's also possible to abort the mission by just blowing it all up...without the negative PR aspect
05:36:52CodeShark:for some reason, dead astronauts tends to bug the public
05:39:50CodeShark:getting astronauts back to earth in one piece is very expensive
05:40:15CodeShark:one-way manned space program...now that has some potential :)
05:46:49amiller:jgarzik, i want to hear more about bitcoins and space plans
05:47:05amiller:somehow, that must be on-topic here!
05:47:32amiller:like, is it supposed to be some kind of science experiment? or something that bolsters the network
05:49:54amiller:ok i guess there's a lot more detail than ive ever seen before in the scrollback already..
05:51:19jgarzik:amiller, indeed. I don't want to spam the channel with the same info - happy to chat about it over email or some other day (heading for bed here)
06:52:42Tebbo`:Tebbo` is now known as Tebbo
08:01:05Aquentin:Aquentin is now known as Guest86574
08:05:17leguin.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
08:05:17leguin.freenode.net:Users on #bitcoin-wizards: andy-logbot Guest86574 jtimon rht__ priidu n0n0_ Mably wallet42 gill3s Xh1pher jmcn mjerr damethos antanst shesek sadoshi TheSeven justanotherusr yossef jgarzik moa Dr-G zmanian MrTratta d1ggy_ adam3us1 SwedFTP huseby dc17523be3 elastoma TD-Linux GreenIsMyPepper hulkhogan_ richardus kanzure sl01 sipa arubi_ dgenr8 MoALTz sparetire_ bliljerk101 badmofo michagogo LeMiner ThinThread otoburb goregrind rustyn isis ttttemp phantomcircuit espes kinlo
08:05:17leguin.freenode.net:Users on #bitcoin-wizards: EasyAt nephyrin` hashtag @ChanServ AdrianG Graet morcos sdaftuar xabbix Eliel leakypat brand0 harrigan harrow berndj weex thrasher` smooth iddo Apocalyptic yorick platinuum kumavis runeks artifexd CryptoGoon yrashk s1w so ajweiss wizkid057 bedeho lclc gwillen K1773R CodeShark bsm117532 sundance jcorgan OneFixt Madars ebfull dasource _whitelogger koshii lmatteis triazo akrmn SubCreative tromp_ face epscy mm_1 mkarrer gielbier maaku Meeh_ qawap_
08:05:17leguin.freenode.net:Users on #bitcoin-wizards: jrayhawk_ azariah_ warren merlincorey midnightmagic HM sturles jonasschnelli Taek Zouppen Luke-Jr lnovy Jaamg cfields rasengan AlexStraunoff [d__d] theymos dansmith_ jessepollak cryptowe- a5m0_ tucenaber wumpus petertodd comboy jcluck Xzibit17 Muis gnusha melvster1 binaryatrocity_ starsoccer Iriez ggreer roasbeef heath grubles contrapumpkin helo veox Anduck gavinand1esen yoleaux dignork waxwing guruvan poggy sparetire throughnothing
08:05:17leguin.freenode.net:Users on #bitcoin-wizards: catlasshrugged [ace] BrainOverfl0w indolering grandmaster mengine Guest68586 nanotube gribble Cory fenn jaromil Alanius_ jouke STRML superobserver andytoshi c0rw|zZz scoria Logicwax BananaLotus akstunt600 amiller Starduster Emcy fluffypony mikolalysenko forrestv Fistful_of_Coins davout PRab_ pigeons livegnik kyuupichan jbenet nickler_ wiz mappum prosodyContext_ crescendo luny` Tebbo ryan-c warptangent afdudley0 eric BlueMatt stevenroose spinza
08:05:17leguin.freenode.net:Users on #bitcoin-wizards: go1111111 nessence_ Tiraspol_ optimator adams__ sneak coryfields_ catcow mariorz null_rad- larraboj_ mountaingoat vonzipper tromp__ nsh Krellan
08:09:05antanst:antanst has left #bitcoin-wizards
08:19:48phantomcircuit: petertodd, note that micropayment channels make leaking of the change address significantly less of an issue
08:56:37CodeShark:how far along are you with the segregated witness thing, sipa?
08:57:02CodeShark:is there anything I can help you with? :)
08:59:53sipa:no, it was trivial to implement, it works
09:00:06sipa:we need tests :)
09:04:42CodeShark:so you essentially added an extra hash method
09:05:27CodeShark:you have four hashes now
09:05:35CodeShark:hash, hashWitness, hashFull, hashBitcoin
09:06:31sipa:the last one is for compatibility reasons
09:06:52sipa:but essentially, txid = hash of everything except witness data
09:07:05sipa:txidwitness = hash of just witness data
09:07:23sipa:blocks commit to txidfull = H(txid || txidwitness)
09:07:32sipa:but everything else just uses txid
09:08:09sipa:witness data is scriptsigs, but also the range proofs needed for confidential transactions
09:08:30sipa:they don't change the effect of a transaction, only theit validity
09:10:58sipa:and since the range proofs are huge, this makes a large difference in the amount of data you need to download
09:11:14sipa:if you do not care for signature validation
09:11:22CodeShark:yeah, for sure
09:11:36CodeShark:we'll eventually want to move to a model where not everyone has to validate everything :)
09:11:44CodeShark:but something that actually works, unlike SPV
09:14:39CodeShark:and something where you CAN validate what's important to you without having to trust the prover
09:15:37CodeShark:so what you should do then is use H(txid || H(txidwitness))
09:16:19phantomcircuit:CodeShark, tree of hashes of all the things in the transaction
09:16:27phantomcircuit:download/validate only what you care about
09:20:32CodeShark:I've also been thinking about how to reduce the reorg fragility if we ever want to move to a model where even miners might not validate everything
09:20:59CodeShark:in principle, we don't need to revert an entire block just because of one bad transaction
09:21:06CodeShark:we can still use the block for PoW
09:21:18CodeShark:but just revert all the dependencies of that transaction
09:22:01sipa:amiller had a model a long time ago, where a block could commit to multiple parents, but only one counted for effects; the rest only for pow
09:22:36sipa:and the system's difficulty aimed for a constant not-on-main-chain rate, rather then constant block rate
09:23:54CodeShark:what do you mean by not-on-main-chain rate?
09:24:21sipa:it measures the recent percentage of blocks that are in such secondary parents
09:24:38CodeShark:are we still talking a single blockchain? or multiple blockchains?
09:24:44sipa:one dag
09:25:04sipa:which defines a chain by following only primary parents
09:27:28CodeShark:still not sure I fully get it - so the same block is used for both effects and pow but is inserted in multiple parents of this dag?
09:29:01CodeShark:so if the block turns out to be invalid, it is still used for PoW but the effects are voided?
09:29:44CodeShark:or two separate blocks entirely - one only used for PoW and the other used only for effects?
09:30:48sipa:every block has two parents
09:31:04sipa:one from which it inherits utxo state and pow
09:31:13sipa:another from which it only inheritd pow
09:31:37sipa:the best-pow one with only valid first-parents wins
09:32:07sipa:the utxo set is defined by purely following the first parents up, and these need to be valid
09:32:36sipa:the blocks reachable through non-first parents count for pow, but are otherwise not validated
09:32:59CodeShark:ah, so the objective is to allow miners to create usable blocks without having to validate anything?
09:33:32CodeShark:do these PoW-only parents have parents as well?
09:34:14CodeShark:still not sure I'm getting it p
09:34:26sipa:they are just blocks
09:34:34sipa:and miners still have to validate everything
09:34:53sipa:it is just blocks that would have beenbreorged out in bitcoin
09:35:08CodeShark:oh, so something more akin to GHOST, in a sense
09:35:09amiller:its not a lot different than GHOST
09:35:10sipa:now become linked into the chain again as such a second parent
09:35:12CodeShark:ok :)
09:36:08CodeShark:the pow parents are what some are calling "uncles"
09:37:36amiller:so the difference is
09:37:51amiller:GHOST has some proposed incentive policy about how much reward the uncles get
09:38:14amiller:it's kind of a loose parameter IMO, they don't justify that choice too well.. i think they have an exponential decay thing
09:38:36amiller:also, in every GHOST proposal I know of, including ethereum's, there's still a fixed minimum-time parameter
09:39:29amiller:so... retrofitting that idea as an extension to GHOST, the point of this thing is to use the GHOST incentives to *tune* the block arrival rate.
09:39:50amiller:no more magic block time number! hooray! defeating a magic parameter is its own reward
09:40:30CodeShark:so basically narrowing the variance
09:40:54CodeShark:and not wasting PoW in side chains
09:42:28amiller:i still think thats a good idea but i didn't finish it
09:43:17amiller:also why should there be any particular fixed fraction
09:43:47CodeShark:if you can incorporate pooled mining into it as well somehow, even more horray! :)
09:44:58amiller:basically i think people should spam their partial proofs of work as far as they can
09:45:47amiller:somehow those shares should tolerate a "lossy" network
09:45:54amiller:like, it's okay if not everyone gets all of those
09:46:20amiller:the things that are currently really
09:46:35amiller:infrequent, and worth thousands of dollars, should still propagate everywhere
09:47:23amiller:i think this is about as well thought out as treechains :O
09:48:44CodeShark:it's a good start of something :)
09:55:05CodeShark:have you gotten as far as modeling anything, amiller?
10:02:13amiller:uh, i remember trying to cram it into the pretty limited set of byzantine generals problem things i knew about, and it didn't work very well
10:04:31amiller:since then, some actual people who know what they're doing in that field modeled the "backbone protocol", and i've also learned to use more abstract tools to talk to cryptographers, like Fblockchain
10:05:52CodeShark:fblockchain - not sure I'm familiar with that one
10:07:22CodeShark:who are some of these actual people, btw? :)
10:07:23amiller:its kind of an overidealized "proof of publication"... it's a "simulation based definition"
10:07:46yoleaux:Cryptology ePrint Archive: Report 2014/765
10:08:09amiller:oh well: The Bitcoin Backbone Protocol: Analysis and Applications. Juan Garay and Aggelos Kiayias and Nikos Leonardos
10:15:31stonecoldpat:CodeShark: for f_{blockchain}, i'm guessing amiller is using the terminology that his supervisor used during a presentation to describe the blockchain as a function, https://youtu.be/FQ6Hii69b5U?t=268
10:16:33CodeShark:ah, I see
10:17:19amiller:yes! :D also we will release a preprint of that in a couple days or something
10:25:07CodeShark:sipa: no new genesis block for elements alpha?
10:25:53sipa:eh yes there is
10:26:06sipa:the format for blocks is even different
10:26:23CodeShark:so then it must be somewhere other than chainparams.cpp
10:26:32CodeShark:because in there I only see the familiar one
10:26:40CodeShark:or the familiar two, I should say :p
10:26:49sipa:are you looking in the ElementsProject/elements, branch alpha?
10:26:51CodeShark:The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
10:26:56CodeShark:oh, branch alpha
10:27:07CodeShark:I am
10:27:35stonecoldpat:amiller: awesome looking forward to it
10:28:35sipa:CodeShark: perhaps the message wasn't changed
10:28:49sipa:but the serialized format of blocks is different
10:29:02sipa:as it has signatures instead of pow
10:29:15CodeShark:but the hash is the same, too :)
10:29:56CodeShark:did you break sha256, sipa? :)
10:33:13sipa:what are you looking at?
10:33:38CodeShark:class CMainParams
10:34:21CodeShark:it looks a little bit too familiar ;)
10:39:28sipa:look at testnet
10:39:34sipa:there is no alpha mainnet
10:39:49sipa:but we probably did not remove it from chainparams
10:40:46CodeShark:ok, yeah - CTestNetParams does look a little different
10:42:13CodeShark:so when it runs it just uses testnet...and the --testnet option does nothing?
10:46:34CodeShark:the default datadir needs to be changed as well
10:46:55CodeShark:and the pid
11:06:59sipa:CodeShark: you can run --notestnet, but it will fail if you fo
11:07:21sipa:the datadir should be ~/.bitcoin/alphatestnet3
11:08:14CodeShark:oh, hmmm
11:08:35CodeShark:I was thinking perhaps it would be a good idea to move it into an entirely separate directory
11:08:58CodeShark:makes it harder to corrupt an existing bitcoind installation
11:11:17CodeShark:the two databases are diverging quickly, after all - and will be less and less mutually compatible :p
11:13:06CodeShark:and then https://github.com/ElementsProject/elements/blob/alpha/src/util.cpp#L480
11:15:35jrayhawk_:jrayhawk_ is now known as jrayhawk
11:30:32CodeShark:time for bed - I'll continue checking it out tomorrow, sipa
11:33:42c0rw|zZz:c0rw|zZz is now known as c0rw1n
11:45:16sipa:CodeShark: 'diverging' ?
11:45:26sipa:they're entirely separate, all the time
13:23:16antanst:antanst has left #bitcoin-wizards
14:59:49bramc:Because the subject hasn't been done to death already: https://medium.com/@bramcohen/bitcoin-s-ironic-crisis-32226a85e39f
15:01:56chmod755:"principles on which Bitcoin was founded".........
15:11:39DougieBot5000_:DougieBot5000_ is now known as DougieBot5000
15:24:33temujin:temujin has left #bitcoin-wizards
15:30:01c0rw1n:c0rw1n is now known as c0rw|away
16:14:44wallet42:wallet42 is now known as Guest9149
16:14:44wallet421:wallet421 is now known as wallet42
16:29:13Pasha:Pasha is now known as Cory
16:36:50blablaa:are there some altcoins working entirely using tx fees?
16:37:20sipa:did you use 'altcoins' and 'working' in the same sentence?
16:37:35blablaa:sipa, well yes...
16:38:02sipa:there are a few who have done interesting development, but they are a very small minority
16:38:06sipa:also, offtopic here
16:38:36blablaa:sipa, it's related to bitcoin because bitcoin as it is is supposed to be funded by tx fees in the future
16:39:05sipa:blablaa: that is a controversial position
16:40:30blablaa:sipa, i'm wondering if fees will stay sufficiently high without a strict cap on block size. i know all this is controversial, but it's also interesting, so i'm throwing the question here.
16:41:40zooko:blablaa: I think your question is a good one.
16:41:52zooko:blablaa: I think the answer to it is: the evidence from altcoins so far doesn't tell us.
16:42:06sipa:agree with zooko
16:45:12blablaa:zooko, ok, thx for your answer, i'll wait for more answers :)
16:48:04bramc:The current transaction rate in altcoins seems unlikely to be able to keep things stable based on transaction fees alone
16:48:35sipa:yes, you need a simulation of an economy for that
16:48:49sipa:blablaa: also, apologies, i thought we were on #bitcoin-dev
16:49:01zooko:sipa: Oh, I was wondering about that. So this topic *is* on topic here?
16:49:20sipa:i would say so
16:49:40sipa:people talk about (interesting) changes to bitcoin all the time here, including those implemented in altcoins
16:50:12tromp_:this could be called bitcoin-fantasies :)
16:58:01adam3us:bramc: note in your medium post gavin's latest proposal ses blocks auto-growing from 8MB to 8GB in 2x increments on a biennial schedule.
16:59:22kanzure:"Eventually the two currencies will be completely separated and peacefully coexist," this is not always going to be the outcome, especially if people lose tremendous amounts of BTC during the transition (or when software is spending to the wrong addresses on the worng blockchains, etc.)
16:59:34adam3us:bramc: not that that is necessarily any better. effect i shard to predict but if understand the intent is to subsidise fees to something approximating effectively free fees for foreseeable future
16:59:58adam3us:bramc: wow that text got mangled some how!
17:01:02bramc:adam3us, I'm trying to word what I'm saying carefully to not be accused of misrepresenting what somebody else says. I included some comments about gavin's latest proposal being even more extreme and him saying specifically that he's doing it because of people arguing with him originally but removed them because it sounded a bit personal
17:01:03adam3us:bramc: try again. not that that is necessarily any better. the effect is hard to predict, but if understand Gavin's intent, he aims to subsidise fees so that there are effectively free fees for the foreseeable future
17:01:34bramc:adam3us, I'm going to write another essay later about the long term effects of all this stuff, I'll include all that thinking in there
17:01:50adam3us:bramc: fair enough. thanks for writing anyway - for some reason the tech news seems to focus on some confusion that industry wants this or that gavin is lead developer and other things.
17:02:03bramc:(because, apparently, there isn't enough stress in my life, so I'm proactively delving into bitcoin)
17:02:29bramc:Thanks for the props, adam3us
17:03:15bramc:I've gotta run now, laters everybody
17:50:01heath:did discussion die down in the mailing list or all the messages ping requests / test messages
17:50:12heath:or +are all the...
17:56:40antanst:antanst has left #bitcoin-wizards
18:02:56adam3us:adam3us has left #bitcoin-wizards
18:37:17heath:* heath finally sees acitivity beyond ping requests o/
19:07:28qawap_:qawap_ is now known as qawap
19:37:54StephenM347:"Your membership in the mailing list Bitcoin-development has been disabled due to excessive bounces..."
19:37:59StephenM347:Anyone else get this?
19:38:37kanzure:check #bitcoin-dev irc logs
19:39:14StephenM347:kanzure: thanks, will do
19:42:52StephenM347:kanzure: http://bitcoinstats.com/irc/bitcoin-dev/logs/ doesn't seem to offer a search?
19:44:39kanzure:brutal... hmm.
19:44:58kanzure:well, one of the emails to bitcoin-development@lists.sourceforge.net mentioned this, so perhaps view that email thread
20:54:24lnsybrd_:lnsybrd_ is now known as lnsybrd
21:47:59wallet421:wallet421 is now known as wallet42
22:08:15temujin:temujin has left #bitcoin-wizards
23:36:39sipa:sipa has left #bitcoin-wizards
23:47:54CodeShark:is it possible to create an efficient accumulator that can be used to validate an entire transaction graph?
23:48:23gmaxwell:nwilcox: I think we identified some time ago what additional commitments are needed to efficiently randomly verify all rules (or at least most of them). Indeed, that could have some nice properties; but we're left with a couple issues:
23:49:36gmaxwell:one is that the additional commiments are expensive to maintain (e.g. vaguely a 20 fold increase in IO costs for full nodes) which is a bit unfortunate but perhaps surmountable, more problematic is the issue of censorship, how do you avoid the case where everyone just plays dumb about some invalidity to prevent you from detecting it?
23:50:09gmaxwell:That latter issue makes it less exciting.
23:51:08nwilcox:CodeShark: I'm curious if an "accumulator" is also possible...
23:51:29nwilcox:gmaxwell: Are these additional comments merkle paths to block header for each txin?
23:52:02c0rw|away:c0rw|away is now known as c0rw1n
23:52:58CodeShark:recent results on zkSNARKs give proofs that do not depend on the size of the program nor input...but constructing the proof still is expensive
23:53:20gmaxwell:nwilcox: no, that wouldn't be sufficient because it can't be used to efficiently show the absense of a double spend. State commitments ("an accumulator" as you note) are sufficient (and I think necessary). https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs is the circa 2011/2012 stuff. IIRC there was something else that needed to be commited to that I forget now that isn't there. (kinda
23:53:26gmaxwell:stopped updating it when 99% of the effect it was having was feeding plagerism)
23:54:04gmaxwell:CodeShark: the proof in that space isn't 'recent results' it was always the case that the proofs were constant size, the name even means that ('Succinct' argument of knoweldge). :)
23:54:42CodeShark:right, well I only encountered it recently...so I'm a little behind :p
23:55:20CodeShark:if the cost of proofs are moved over to the sender, it could be conceivably made to scale
23:55:54CodeShark:the sender would only have to incorporate one more witness into the proof they got from each of their inputs
23:56:19gmaxwell:CodeShark: you still need publicaiton unfortunately, proving that a block is valid is fine, but if no one but the block author had the updated accumulator state then only they can produce more blocks. :(
23:58:17CodeShark:why would only the block author have the updated accumulator state?