| 00:00:44 | nsh: | or could add fee gossip to the network protocol but that would probably be gamed too |
| 00:13:30 | bramc: | leakypat, That depends on where you start and how quickly you raise |
| 00:14:43 | bramc: | 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:38 | CodeShark: | 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:07 | bramc: | CodeShark, Yes, exactly |
| 00:28:01 | CodeShark: | however...by doing this they crowd out their own blocks |
| 00:28:09 | CodeShark: | so there must be some equilibrium |
| 00:28:49 | CodeShark: | given a sufficiently small range and a sufficiently large volume, miners would rather be honest than cheat |
| 00:29:50 | bramc: | 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:44 | CodeShark: | they could only really set their own prices by forming a cartel, though - miners can already choose to block transactions at will |
| 00:31:34 | bramc: | Individual mining pools are big enough to pull it off |
| 00:32:13 | CodeShark: | so I think the conclusion is that any fee estimation must also use unconfirmed propagated transactions (mempool) |
| 00:32:14 | bramc: | 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:56 | bramc: | That would help a bit, but it's much safer to only trust your own local experience |
| 00:33:26 | CodeShark: | by own local experience you mean just your own attempts to send? |
| 00:33:57 | bramc: | Yeah |
| 00:34:12 | CodeShark: | 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:29 | CodeShark: | but that seems rather expensive...and still isn't particularly fast |
| 00:34:40 | bramc: | There's no point in probing until you have a payment you actually want to send |
| 00:35:10 | CodeShark: | but you might not want the real transaction to take hours |
| 00:35:22 | CodeShark: | so you probe a few hours before you'll make the real transaction |
| 00:35:35 | CodeShark: | but you still miss things like daily cycles and other high frequency phenomena |
| 00:35:43 | bramc: | No, you remember your last transaction which worked and start at half that rate |
| 00:36:38 | bramc: | Actually I did my math wrong - that one should be four hours |
| 00:36:59 | CodeShark: | well, three or four hours...still WAY too long |
| 00:37:18 | bramc: | 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:29 | bramc: | too long for what? |
| 00:37:39 | CodeShark: | to send a transaction |
| 00:37:46 | bramc: | You're free to make it go faster by doubling your fee every time |
| 00:38:14 | bramc: | But that costs more, and is likely to hit bad parts of the daily cycle (taking a while might have inherent advantages) |
| 00:38:31 | CodeShark: | 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:00 | CodeShark: | so I think any practical approach will have to check the mempool |
| 00:39:24 | leakypat: | bramc: I'm trying to picture the scenario, I guess it is systems bidding to settle large transactions? |
| 00:39:45 | bramc: | bitcoin payments are not what you call fast. If you want fast transactions, you use micropayment channels |
| 00:41:06 | bramc: | leakypat, In the long run it's likely to be that most transactions are large |
| 00:41:15 | CodeShark: | 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:26 | leakypat: | I agree with you on this stuff, yes |
| 00:41:28 | bramc: | 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:58 | leakypat: | So who's might be a lightning channel or centralized micropayment system bidding to settle their payments |
| 00:42:28 | leakypat: | They just want the cheapest fee they can get and require settlement within x hours |
| 00:42:28 | bramc: | 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:41 | bramc: | er, 45% I mean, but due to noise it may be worse |
| 00:43:13 | bramc: | leakypat, micropayment channels can completely short circuit all of this stuff once their initial deposits are put down |
| 00:43:49 | leakypat: | The channels have to close to the blockchain at some point right? |
| 00:44:09 | bramc: | leakypat, When their net is settled out, yes |
| 00:44:11 | leakypat: | Or have the possibility to do so |
| 00:44:25 | leakypat: | Yes, that's what I was imagining |
| 00:44:34 | sl01: | is there any issue using centralized service(s) that provide APIs to wallet to get fee estimate information? |
| 00:45:06 | sl01: | and those services can use whaterver witchcraft they want to provide you best guess information on fee and conf times |
| 00:45:15 | bramc: | 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:15 | c0rw|afk: | c0rw|afk is now known as c0rw|zZz |
| 00:45:41 | bramc: | sl01, We're discussing the mechanics of that |
| 00:45:43 | leakypat: | It will be on the miners interests to have a transparent fee market |
| 00:46:10 | sl01: | 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:22 | leakypat: | Although , Hmm, there is no guarantee who is going to mine which block ... Interesting |
| 00:46:31 | bramc: | sl01, Well 'no requests' is a simple to implement API :-) |
| 00:46:39 | sl01: | which makes the problem much harder |
| 00:46:46 | leakypat: | So users aren't direct customers in that sense |
| 00:46:51 | sl01: | thats why i was just wondering if it might become 100x easier if you just "rely on a service" |
| 00:47:15 | CodeShark: | everything is a lot easier if you just "rely on a service" |
| 00:47:19 | CodeShark: | the challenge is how not to |
| 00:47:27 | bramc: | 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:33 | sl01: | right, and for some things in bitcoin you dont want to, but this seems like the sort of thing its ok to |
| 00:48:07 | bramc: | 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:50 | sl01: | 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:32 | bramc: | sl01, Eh... sort of. It can possibly come up with more accurate amounts faster. |
| 00:49:54 | bramc: | sl01, But you'll always be able to get payments sent with lower transaction fees if you're willing to wait longer |
| 00:50:17 | bramc: | Possibly vasty different. It wouldn't surprise me to get a daily cycle of fees with swings of 10x |
| 00:50:19 | CodeShark: | I think we need to consider these as somewhat separate use cases |
| 00:50:54 | CodeShark: | 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:21 | CodeShark: | there' |
| 00:51:34 | CodeShark: | there could even be a market for "fee market makers" :p |
| 00:52:46 | sl01: | 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:07 | bramc: | 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:22 | bramc: | Maybe smart wallets could recombine their dust in the middle of the night. |
| 00:55:05 | CodeShark: | 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:46 | CodeShark: | hmm - it's tricky :) |
| 00:58:09 | CodeShark: | not sure I like the idea of entities having mining contracts on behalf of clients |
| 00:58:25 | bramc: | I'm proposing straight escalator as a starting point. It should be the beginning. |
| 01:00:38 | CodeShark: | 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:41 | bramc: | 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:18 | bramc: | 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:07 | bramc: | This is a very conservative approach which is optimizing for low fees over time, although its amounts of time aren't crazy |
| 01:03:25 | CodeShark: | 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:30 | nsh: | 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:44 | sl01: | 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:18 | bramc: | sl01, petertodd's code has a minimum increment |
| 01:04:27 | sl01: | ah cool, didnt see that |
| 01:04:42 | bramc: | 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:50 | nsh: | (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:58 | bramc: | One could reasonably argue that the minimum increment should be a percentage |
| 01:05:49 | bramc: | 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:57 | CodeShark: | yes, please do that |
| 01:06:15 | CodeShark: | I really wish people would stop claiming that we need to make Bitcoin integration possible for even idiots |
| 01:07:22 | ggreer: | oh, zero confirmations. for a second I thought you talking about zero configuration networking |
| 01:08:16 | bramc: | 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:16 | CodeShark: | 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:44 | CodeShark: | in infosec, "I've never gotten hacked before so it's probably OK to continue doing" is how many downfalls begin :) |
| 01:10:24 | bramc: | 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:16 | CodeShark: | 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:53 | CodeShark: | and encouraging people to accept them just to "boost adoption" is folly |
| 01:14:21 | CodeShark: | might as well encourage people to use shitty passwords to encourage more "online banking" |
| 01:17:07 | CodeShark: | I don't even understand why this would be controversial |
| 01:17:19 | CodeShark: | other than complete myopia |
| 01:17:37 | bramc: | It isn't very controversial in this crowd, except for two people, you'd have to ask them why they like it |
| 01:21:29 | jgarzik: | c.f. the mailing list to which I responded |
| 01:21:32 | leakypat: | Bitcoin has been sold as send money anywhere in the world instantly for free |
| 01:21:44 | jgarzik: | plenty of business cases where zero conf works just fine -- it's in the realm of business risk |
| 01:21:58 | jgarzik: | physically shipping goods - just fine to initiate order @ 0-conf |
| 01:22:13 | jgarzik: | it doesn't go out the door until confirmed. order processing occurs in parallel with confirmations |
| 01:22:22 | jgarzik: | ditto subscriptions - the good can be revoked |
| 01:22:49 | CodeShark: | 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:22:58 | CodeShark: | thoroughly |
| 01:23:04 | petertodd: | jgarzik: it'd really help this discussion if for those cases you said you weren't relying on zeroconf |
| 01:23:22 | petertodd: | jgarzik: I'm finding people thinking that zeroconf means someone other than the sender can cancel the tx |
| 01:24:39 | CodeShark: | basically, if you choose to accept unconfirmed transactions you can no longer rely on bitcoin's security model at all |
| 01:24:46 | CodeShark: | so you need to create another security model |
| 01:24:53 | jgarzik: | correct |
| 01:24:58 | jgarzik: | zero conf = zero security, by default |
| 01:25:28 | jgarzik: | It does not however mean zero security holistically, when including business risk and business case |
| 01:25:32 | bramc: | jgarzik, That isn't really zero conf, it's delaying the conf until later |
| 01:25:52 | bramc: | real zeroconf is letting you take money out of the ATM |
| 01:26:03 | jgarzik: | yep |
| 01:26:31 | jgarzik: | bramc, nevertheless, programmatically Some Things Happen at zero confirmations at legit merchants without introducing risk |
| 01:27:20 | CodeShark: | 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:27:37 | jgarzik: | correct |
| 01:28:03 | leakypat: | I suppose the question is, should the fact these external systems exists dictate how the Bitcoin protocol is developed? |
| 01:28:03 | bramc: | Also authorizing the customer to walk out of the store with the goods |
| 01:28:07 | jgarzik: | i.e. some businesses get ID and/or take pictures of their customers, which provides recourse and mitigate risk |
| 01:28:23 | jgarzik: | amusingly to address chargeback fraud primarily |
| 01:28:58 | jgarzik: | leakypat, dictate - no - however it is true that you cannot just nuke zero-conf without a What To Transition To plan |
| 01:29:17 | jgarzik: | ie. no mainstream wallet yet supports even 2-way payment channels |
| 01:30:00 | bramc: | jgarzik, Arguably it only matters for vendors of ATMs and payment processors who rely on it |
| 01:30:01 | jgarzik: | Just complaining or nuking does nothing to help users today |
| 01:31:13 | jgarzik: | 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:20 | bramc: | 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:46 | bramc: | jgarzik, The points that zeroconf has no real security and what should be done about it are two separate things |
| 01:32:55 | jgarzik: | bramc, e.g. You seem to have missed the relevant mailing list discussion |
| 01:33:02 | jgarzik: | that CodeShark participated in |
| 01:33:22 | petertodd: | 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:55 | petertodd: | 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:23 | bramc: | I'm not on the mailing list |
| 01:35:37 | CodeShark: | it just moved today |
| 01:36:21 | CodeShark: | still not 100% it's all fully working yet...but we'll see :) |
| 01:37:27 | CodeShark: | I'd be happy to write more on this topic, jgarzik. I think people sometimes get too extreme on both sides |
| 01:38:03 | bramc: | I just looked up the mailing list and was going to ask why it's on sourceforge |
| 01:41:13 | CodeShark: | security isn't really about a few crypto algorithms, schemes, and protocols - these are merely tools. it's about managing risk. |
| 01:41:31 | jgarzik: | nod |
| 01:42:29 | CodeShark: | 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:07 | petertodd: | 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:07 | jgarzik: | petertodd's favorite theoretical bug-a-boo |
| 01:44:13 | CodeShark: | heh |
| 01:44:24 | CodeShark: | well, it is a potentially serious problem |
| 01:44:28 | petertodd: | jgarzik: hang around bankers more often :) |
| 01:44:39 | petertodd: | jgarzik: and regulators |
| 01:45:43 | petertodd: | 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:38 | CodeShark: | 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:43 | CodeShark: | why are they killing Bitcoin to do this? |
| 01:48:02 | petertodd: | CodeShark: enforcing AML/KYC - remember that these are the people who are happy to stop hawala if they can find a way |
| 01:48:27 | bramc: | Yeah, umm, bitcoin-backed credit cards aren't too exciting if they're just ordinary credit cards with bitcoin headaches added on |
| 01:48:51 | petertodd: | CodeShark: it's not about alternatives, is that from their perspective Bitcoin shouldn't exist in its current form (where their==regulators) |
| 01:48:52 | CodeShark: | if you're a regulated entity with contracts and all that, why use a trustless p2p protocol at all? |
| 01:49:50 | petertodd: | 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:02 | CodeShark: | Bitcoin RIP...2009-20?? |
| 01:55:22 | petertodd: | CodeShark: eventually the sun explodes and we all die - I'll make that prediction :P |
| 01:55:23 | bramc: | 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:28 | petertodd: | 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:41 | petertodd: | bramc: one of those things where you don't be too restrictive |
| 01:58:48 | bramc: | 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:24 | petertodd: | 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:37 | petertodd: | bramc: the blocksize issue *does* come up in these discussions |
| 02:00:34 | petertodd: | 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:10 | petertodd: | bramc: (this was the conf/workshop: http://blockchainworkshops.org/) |
| 02:01:35 | bramc: | KYC is a ludicrously expensive program for the actual amount of law enforcement it results in |
| 02:02:59 | petertodd: | bramc: indeed |
| 02:22:45 | bramc: | 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:20 | bramc: | err, I mean replace by fee, I guess that's the term of art for actually malleating transactions in practice |
| 02:24:34 | bramc: | malleating by changing the outputs I mean |
| 02:26:11 | bramc: | Arguably now that one major pool is accepting rbf the jig is up and everyone else will just follow |
| 02:31:55 | leakypat: | 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:36 | leakypat: | In one sense a lot of companies / people are pushing adoption to the wrong use case |
| 02:33:03 | jgarzik: | bramc, FSS RBF, not full RBF |
| 02:33:51 | moa: | leakypat: only misinformed people were 'selling' bitcoin as instant |
| 02:33:56 | jgarzik: | bramc, https://github.com/bitcoin/bitcoin/pull/6176 |
| 02:34:25 | leakypat: | moa: I know, but that's most people |
| 02:34:32 | moa: | or duplicitous maybe |
| 02:34:32 | jgarzik: | petertodd, FYI I'm meeting with Coinalytics... should be interesting |
| 02:34:59 | jgarzik: | petertodd, FYI I'm meeting with Coinalytics... should be interesting |
| 02:35:18 | jgarzik: | * jgarzik kicks xchat |
| 02:35:22 | petertodd: | jgarzik: yeah, I know jonathan levin from coinalysis |
| 02:35:30 | petertodd: | jgarzik: or is there now a Coinalytics?! |
| 02:36:46 | leakypat: | How will layer 2 networks play out for these kind of companies I wonder |
| 02:37:08 | leakypat: | I'm still sketchy on the privacy of lightning etc. |
| 02:37:12 | jgarzik: | petertodd, http://coinalytics.co |
| 02:37:18 | jgarzik: | petertodd, they are doing something w/ AML too |
| 02:37:21 | jgarzik: | don't know what |
| 02:37:37 | petertodd: | jgarzik: god help us... purely on the basis of shit names :) |
| 02:37:51 | yossef: | yossef has left #bitcoin-wizards |
| 02:38:47 | moa: | ... and ye shall know them by there fruit |
| 02:39:30 | bramc: | 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:28 | moa: | hide in the weeds versus hide in the crowds |
| 02:41:18 | leakypat: | bramc eg. If I hop to user c via user b? User b will see my transactions |
| 02:41:34 | petertodd: | bramc: note how lightning is not unlike Tor in this respect when you think about it |
| 02:41:34 | bramc: | 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:02 | bramc: | petertodd, Yes you could in principle provide onion payment services through lightning |
| 02:42:36 | bramc: | leakypat, Yeah that's the idea |
| 02:42:45 | leakypat: | bramc: you add new inputs and outputs as required |
| 02:42:56 | leakypat: | As long as the original ones are still there |
| 02:42:59 | petertodd: | bramc: exactly! :) |
| 02:43:22 | bramc: | 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:24 | petertodd: | bramc: equally, hub-and-spoke can do privacy tech like chaum tokens pretty easily and obviously |
| 02:43:32 | petertodd: | bramc: yeah, that's kinda ugly |
| 02:43:41 | leakypat: | bramc: yes |
| 02:44:43 | bramc: | For fee increases you want the exact opposite, that outputs can only go down and no new outputs can be added |
| 02:45:37 | leakypat: | Yeah really you would just drop the value of your change output, but which one is the change? |
| 02:45:44 | bramc: | 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:47 | petertodd: | leakypat: whichever one you want it to be ;) |
| 02:45:54 | jgarzik: | bramc, which sucks for privacy |
| 02:46:06 | leakypat: | s/really/ideally |
| 02:48:00 | bramc: | 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:14 | bramc: | jgarzik, And forcing a new input to be added is arguably even worse |
| 02:49:27 | petertodd: | bramc: yeah, yet another reason why estimating the fee correctly in the first place is ideal |
| 02:49:41 | bramc: | 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:58 | bramc: | 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:12 | bramc: | I mean, it can wind up in bizarre and incorrect feedback loops. |
| 02:51:41 | petertodd: | 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:05 | petertodd: | bramc: making a bad estimate once in awhile isn't such a big deal |
| 02:52:56 | bramc: | 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:56 | petertodd: | 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:21 | petertodd: | bramc: (f2pool implementing full-rbf was kinda surprising to me actually) |
| 02:54:56 | bramc: | didn't jgarzik just say that f2pool only implemented fss-rbf? |
| 02:55:20 | jgarzik: | bramc, they went full first, then backed down to fuss |
| 02:55:20 | petertodd: | 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:29 | jgarzik: | * jgarzik kicks autocorrect |
| 02:55:40 | jgarzik: | bramc, they went full first, then backed down to fss |
| 02:55:42 | petertodd: | bramc: (they're chinese, so there can be language barriers and misunderstandings obviously) |
| 02:55:50 | leakypat: | 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:52 | petertodd: | bramc: right now I think they knew exactly what they were doing :) |
| 02:56:16 | petertodd: | leakypat: to be exact, the extra input is what is bad for privacy - you'll leak what your change output is |
| 02:56:17 | jgarzik: | leakypat, nothing about RBF is privacy enhancing... you leak privacy no matter what you do |
| 02:56:36 | petertodd: | leakypat: fss-rbf is worse than rbf, but they're both worse than guessing right in the first place |
| 02:56:49 | jgarzik: | RBF is an outlier action |
| 02:56:55 | jgarzik: | makes you stick out in the noise |
| 02:57:17 | bramc: | the big problem with fss-rbf is that you're wasting transaction space while increasing your fee |
| 02:57:26 | petertodd: | 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:53 | petertodd: | 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:04 | bramc: | petertodd, No I did not |
| 02:58:30 | petertodd: | 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:45 | petertodd: | bramc: and also http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07868.html |
| 02:58:50 | bramc: | 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:17 | petertodd: | bramc: which we've done! changetip is one such example |
| 03:01:43 | bramc: | petertodd, I don't see how changetip fixes anything btc-related other than just avoiding it completely |
| 03:02:07 | petertodd: | bramc: prior to changetip there were on-chain tipping services, where much of the tip was eaten up by fees |
| 03:02:16 | petertodd: | bramc: it might not be a pretty solution, but it very much is a solution |
| 03:02:50 | petertodd: | 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:53 | leakypat: | * leakypat wonders if mining will end up with cartel style fee pricing |
| 03:03:04 | petertodd: | leakypat: explain? |
| 03:03:26 | leakypat: | They just come to a general agreement of what the fees should be and all play ball |
| 03:03:49 | petertodd: | leakypat: if they enforced that, they'd need to 51% attack other miners... |
| 03:04:13 | bramc: | 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:31 | petertodd: | leakypat: note how jgarzik's miner vote proposal is not unlike a gentlemanly and safe way of negotiating such a cartel |
| 03:04:45 | leakypat: | petertodd: I don't understand the 51% attack thing..? |
| 03:04:51 | bramc: | 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:29 | petertodd: | leakypat: if 75% of miners play ball, and the other 25% don't... then what? (esp. in an unlimited blocksize scenario) |
| 03:05:54 | petertodd: | bramc: you're probably not familiar with the sorrid history of gavin's fee estimator... :) |
| 03:06:24 | jgarzik: | petertodd, sorry, you continue to vastly oversimplify BIP 100 to the point of being inaccurate |
| 03:06:27 | petertodd: | 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:38 | leakypat: | petertodd: I see |
| 03:06:55 | bramc: | petertodd, I am not. From that comment it sounds like it's about as troubled as I'd expect. |
| 03:07:52 | bramc: | 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:59 | petertodd: | 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:18 | bramc: | 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:02 | petertodd: | 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:24 | petertodd: | 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:22 | bramc: | petertodd, I've foreseen those problems and didn't even have to code them up to realize it :-P |
| 03:10:57 | petertodd: | 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:22 | bramc: | 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:15 | bramc: | Unfortunately it doesn't work at all in fss-rbf world |
| 03:12:35 | petertodd: | 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:45 | bramc: | Yes that's fine although presumably a large number of transactions are on the edge |
| 03:13:51 | petertodd: | 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:56 | bramc: | And also I'm guessing the daily cycle will be quite prominent |
| 03:14:43 | bramc: | petertodd, *insert rant about how the ethos of bitcoin is that broken software will be weeded out and die here* |
| 03:15:25 | petertodd: | 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:07 | bramc: | Presumably the not-time-sensitive applications will need different fee setting algorithms |
| 03:16:08 | petertodd: | 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:55 | bramc: | The only way to find out is to have real fees with algorithms which set the fees properly and see what happens |
| 03:19:14 | bramc: | A bit advantage of escalator is that it clearly works properly. The stuff about using mempool seems dubious. |
| 03:19:45 | petertodd: | 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:32 | jgarzik: | and insert block size debate at this point :) |
| 03:32:39 | jgarzik: | no real fees without block pressure |
| 03:32:48 | jgarzik: | economic policy -- for years -- has been to suppress fee pressure |
| 03:43:48 | bramc: | What does cpfp stand for? |
| 03:45:42 | jgarzik: | bramc, Child Pays For Parent. A secondary transaction boosts the priority of the primary transaction. 2nd tx adds fees to 1st. |
| 03:45:42 | bramc: | 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:19 | bramc: | Oh right. cpfp has overhead and may need to increase its own fee, which runs into the same issues |
| 03:46:37 | jgarzik: | 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:32 | leakypat: | CPFP is worse because you have to pay twice too |
| 03:48:13 | bramc: | 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:38 | bramc: | 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:21 | bramc: | 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:31 | jgarzik: | bramc, The block size limit, which implies the transaction rate limit, yes. The current community debate is about raising that limit. |
| 03:49:43 | jgarzik: | bramc, when that happens there will be little fee pressure |
| 03:49:52 | jgarzik: | bramc, which has been the case historically for years |
| 03:50:09 | jgarzik: | bramc, anytime fee pressure approaches, people lobby miners to raise their soft limit, eliminating fee pressure |
| 03:50:13 | bramc: | jgarzik, I for one am very strongly against raising that limit, for a number of reasons |
| 03:52:02 | bramc: | One of them being that low transaction fees are a bad thing unto themselves |
| 03:53:20 | moa: | anybody know what a BIP 47 payment code actually looks like? |
| 03:53:23 | moa: | i.e. data format? |
| 03:53:24 | jgarzik: | 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:51 | jgarzik: | 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:25 | bramc: | jgarzik, Raising the limit is the thing which optimizes for the short term at the expense of the long term |
| 03:55:45 | bramc: | 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:24 | bramc: | Plus damage to the credibility of the claim that bitcoin isn't centrally controlled |
| 03:56:33 | jgarzik: | 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:40 | jgarzik: | bramc, i.e. externalities |
| 03:57:16 | bramc: | jgarzik, A single order of magnitude increase changes very few of those calculations. |
| 03:58:41 | bramc: | 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:41 | jgarzik: | 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:02 | bramc: | I meant to say that full-rbf doesn't make it less useful |
| 04:04:04 | jgarzik: | From that narrow perspective, fss-rbf is simply less damaging |
| 04:06:20 | bramc: | 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:20 | jgarzik: | bramc, agree with the latter statement (temporary) |
| 04:07:36 | jgarzik: | bramc, It very much depends on the real world risk scenario whether it is sane or not |
| 04:08:37 | jgarzik: | In fact, I think a timeline for deploying full-RBF would help focus people |
| 04:09:02 | jgarzik: | Wallet software and other stuff needs much work still |
| 04:09:07 | bramc: | That is something I would be fine with |
| 04:14:10 | petertodd: | jgarzik: potentially could be done with a Bitcoin Core release that enabled full-RBF at a specific date in the future |
| 04:16:10 | jgarzik: | petertodd, I'm OK with that |
| 04:16:43 | jgarzik: | petertodd, Decidedly -not- OK with surprise rollouts the community is not prepared for |
| 04:17:03 | bramc: | Wow, we're having actual productive discussion |
| 04:17:10 | petertodd: | jgarzik: rough guess, how far into the future? |
| 04:17:54 | jgarzik: | petertodd, rough guess? 6 months too short, longer than 12 months probably too long |
| 04:18:18 | petertodd: | jgarzik: 9 months it is :) |
| 04:18:29 | bramc: | 9 months sounds great |
| 04:18:41 | jgarzik: | Have to upgrade -all- wallet software, websites, decentralized wallets, etc. |
| 04:18:48 | jgarzik: | Have to endorse a useful solution like CLTV+paychan |
| 04:19:09 | jgarzik: | ie. wallet software authors need to know a direction other than "panic!" |
| 04:19:46 | petertodd: | 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:07 | bramc: | uh, dumb question, what is cltv? |
| 04:20:35 | petertodd: | bramc: CHECKLOCKTIMEVERIFY - BIP65 - my baby :) |
| 04:20:55 | bramc: | Also, the thing which full rbf breaks is zeroconf, not transaction fee pressure |
| 04:21:15 | bramc: | petertodd, Is that including relative now? Is it in utxos or transactions or both? |
| 04:21:30 | petertodd: | bramc: just absolute, to keep the # of lines of code changed down |
| 04:21:45 | petertodd: | bramc: I 100% agree relative would be nice, but I wanted something *really* simple as a first-effort |
| 04:22:04 | petertodd: | bramc: I've literally given more interviews about CLTV than there are lines of code in CLTV... |
| 04:22:09 | moa: | CLTV is going into v0.11.0 ? |
| 04:22:16 | jgarzik: | bramc, CLTV is _huge_. Freeze funds on-chain until X time. |
| 04:22:19 | jgarzik: | lots of uses |
| 04:22:31 | bramc: | petertodd, cltv in utxos is the least important thing, because cltv is already in transactions |
| 04:22:36 | petertodd: | moa: well, it got a bunch of review by maaku for elements, which helps |
| 04:23:02 | petertodd: | 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:12 | bramc: | Although I agree that it's the simplest thing |
| 04:23:21 | jgarzik: | 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:26 | jgarzik: | Much better than proof-of-burn. |
| 04:23:31 | jgarzik: | CLTV enables pay-to-future miner. |
| 04:23:42 | jgarzik: | (freeze an anyone-can-spend TX) |
| 04:23:58 | jgarzik: | CLTV must be integrated ASAP. :) |
| 04:24:01 | petertodd: | jgarzik: CLTV is both a floor wax and a dessert topping! |
| 04:24:17 | jgarzik: | and sex lube too |
| 04:24:17 | moa: | jgarzik: california loosens the tongue |
| 04:24:18 | bramc: | 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:38 | bramc: | jgarzik, You're in the bay area now? I'm headquartered here. |
| 04:25:01 | jgarzik: | bramc, agree -- the main issue is that locktime transactions are not relayed across the network, nor remembered in mempools. easy DoS + malleate. |
| 04:25:10 | jgarzik: | gotta get it into the chain. |
| 04:25:14 | CodeShark: | making timelock part of the script is far more powerful |
| 04:25:28 | jgarzik: | yep |
| 04:25:29 | bramc: | Although relative timelock, both in transactions and utxos, should get in asap as well. |
| 04:26:04 | petertodd: | jgarzik: +1 |
| 04:26:11 | petertodd: | jgarzik: (the sex lube bit) |
| 04:26:22 | CodeShark: | gotta work on the branding |
| 04:26:32 | jgarzik: | 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:50 | jgarzik: | based in Atlanta |
| 04:26:53 | bramc: | jgarzik, I can't tell if that's satire |
| 04:26:59 | jgarzik: | bramc, nope 100% truth |
| 04:27:54 | bramc: | jgarzik, I... I can't... I don't know what to say |
| 04:28:06 | jgarzik: | bramc, rackspace in space |
| 04:28:26 | bramc: | Because latencies on earth are too low? |
| 04:30:01 | jgarzik: | 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:46 | bramc: | The latencies on earth are mostly incurred at the local ISP and by limitations in the speed of light. |
| 04:31:16 | CodeShark: | you don't really gain much in the latter, do you? |
| 04:31:19 | jgarzik: | 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:33 | jgarzik: | bramc, yes - it's the hops - in space has fewer optical hops at speed of light |
| 04:31:49 | jgarzik: | easier to repair than sea cables too |
| 04:32:21 | bramc: | 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:22 | bramc: | https://www.youtube.com/watch?v=BVn1oQL9sWg |
| 04:32:40 | CodeShark: | I think he said LEO |
| 04:32:49 | jgarzik: | yep |
| 04:32:55 | KFl6WxEUI1Zbp2: | jgarzik: don't blockchain satellites also allow people to avoid certain miner attacks? |
| 04:32:56 | jgarzik: | under the van allen rad belts |
| 04:33:24 | CodeShark: | geostationary satellites are good for high throughput/high latency |
| 04:33:30 | jgarzik: | correct |
| 04:33:40 | bramc: | for LEO it depends on exactly how high |
| 04:33:54 | jgarzik: | geostationary are way up there, higher earth orbit, higher power, higher rad shielding, higher launch costs, higher latency |
| 04:34:06 | moa: | bramc: space money jurisidiction has low latency dev times |
| 04:34:08 | CodeShark: | but the simpler the math :) |
| 04:34:33 | moa: | he's the CEO of LEO |
| 04:34:38 | jgarzik: | rofl |
| 04:35:01 | CodeShark: | I'm still not 100% sure I fully grok the vision, jgarzik |
| 04:35:11 | KFl6WxEUI1Zbp2: | jgarzik was that 'correct' directed at me or CodeShark |
| 04:35:20 | CodeShark: | I mean, I understand that satellites and space are cool and all |
| 04:35:26 | jgarzik: | CodeShark, yeah I can't say too much in public about the stealth mode bits ;p |
| 04:36:00 | CodeShark: | but to an outside observer it just looks like a very expensive way to do something relatively simple |
| 04:36:30 | jgarzik: | the public gets the basic open source satellite design, but not the biz details. http://dunveganspace.com/assets/bitsat-design-pdr.pdf |
| 04:36:35 | bramc: | CodeShark, But it's spaaaaaace! |
| 04:36:53 | jgarzik: | KFl6WxEUI1Zbp2, both! :) |
| 04:37:14 | jgarzik: | Let's just say you can do a lot with worldwide global broadcast network |
| 04:37:22 | zooko: | lol ; I love this channel. Especially the bit about "CTLV must be deployed!" |
| 04:37:36 | zooko: | I think I might have played a role in getting petertodd started on CTLV. |
| 04:38:30 | KFl6WxEUI1Zbp2: | 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:20 | jgarzik: | all other sats are "dumb" repeaters with no trustless crypto security vis the ground |
| 04:39:53 | KFl6WxEUI1Zbp2: | all other ^bitcoin sats? |
| 04:39:59 | bramc: | The best use of super low latency communications is price arbitrage between the london and nyc stock exchanges |
| 04:40:38 | jgarzik: | all other satellites besides my own BitSats |
| 04:42:24 | moa: | jgarzik: could i reserve some dedicated hardware on a BitSat ... sole access, etc? |
| 04:43:12 | CodeShark: | how much to rent a rack? :) |
| 04:43:38 | jgarzik: | moa: In theory yes - probably outside your budget though :) - See MSRP: http://dunveganspace.com/assets/bitsat-infosheet.pdf |
| 04:44:01 | moa: | that's presumptious but thanx |
| 04:44:18 | CodeShark: | $19 million for a 24 unit constellation - what a deal! |
| 04:44:20 | jgarzik: | some customers are looking to put custom circuits on board |
| 04:44:42 | jgarzik: | CodeShark, in space terms it is 1000x cheaper than 10 years ago for same capability :) |
| 04:44:50 | CodeShark: | yes, so are CPUs :p |
| 04:45:00 | moa: | neilsen's law in space too? |
| 04:45:12 | KFl6WxEUI1Zbp2: | moa lol |
| 04:45:25 | jgarzik: | yep. same cost curves are applying to space now. launch & spacecraft costs fell exponentially, and will continue another iteration. |
| 04:46:12 | bramc: | A lot of those price falls haven't been new technology so much as the legacy space launch system finally getting replaced |
| 04:48:01 | zooko: | goodnight folks. Don't break the internet before I wake up. |
| 04:49:08 | jgarzik: | bramc, that's one part |
| 04:49:17 | moa: | i'm intrigued by the 'Dunvegan' name origin ... sounds irish |
| 04:49:35 | jgarzik: | bramc, legacy replacement + reuseable + increased competition for smallsat launches + ride-share |
| 04:50:11 | jgarzik: | moa: Dunvegan Castle in Scotland |
| 04:50:13 | bramc: | 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:16 | CodeShark: | when does economy of scale start to kick in? |
| 04:50:20 | moa: | ah |
| 04:50:28 | moa: | celtic |
| 04:50:51 | jgarzik: | CodeShark, "soon but not yet" |
| 04:51:10 | jgarzik: | when Elon's or Branson's 1000+ constellations start going up, then you see real volume |
| 04:51:17 | moa: | yeah when SpaceX gets true private competitor |
| 04:52:00 | jgarzik: | Of course must be wary of https://en.wikipedia.org/wiki/Kessler_syndrome Everybody has a deorbit plan these days. |
| 04:52:15 | bramc: | 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:48 | CodeShark: | what about a space elevator? |
| 04:53:06 | moa: | 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:06 | CodeShark: | or other form of propulsion where the fuel doesn't need to be carried on board |
| 04:53:17 | rasengan: | 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:19 | bramc: | space elevator doesn't work from a cost standpoint. Skylon does work in principle. |
| 04:53:28 | jgarzik: | 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:36 | moa: | orbital service stations could change craft design |
| 04:53:42 | jgarzik: | fuel itself is cheap |
| 04:53:52 | jgarzik: | CodeShark, long way off |
| 04:54:04 | jgarzik: | reuseable rockets bring launch costs down to that of a first class ticket to Paris |
| 04:54:23 | bramc: | 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:25 | jgarzik: | think scale, too -- smallsat rockets are much smaller. One company is using high altitude balloons + old missiles. |
| 04:54:57 | jgarzik: | airplanes and balloons already exist for a usable first stage |
| 04:55:01 | jgarzik: | *reusable |
| 04:55:09 | bramc: | 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:21 | CodeShark: | certainly not very fast |
| 04:55:26 | CodeShark: | but they can get you pretty high |
| 04:55:31 | jgarzik: | exactly |
| 04:55:44 | bramc: | CodeShark, Not really so high, the atmosphere gets thin fairly quickly |
| 04:56:36 | CodeShark: | https://en.wikipedia.org/wiki/Flight_altitude_record |
| 04:57:34 | CodeShark: | looks like the unmanned gas balloon record is 53km |
| 04:57:36 | bramc: | CodeShark, Yeah last I ran numbers getting 100km in the air didn't seem like much of a boost |
| 04:57:50 | moa: | if the air's thin then accelerating the craft is a lot cheaper |
| 04:58:03 | moa: | and speed is ultimately what you want |
| 04:58:17 | moa: | deltaV |
| 04:59:10 | bramc: | 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:49 | jgarzik: | moa: yep |
| 05:00:16 | moa: | well every pound less fuel is an additional pound of payload |
| 05:00:43 | bramc: | 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:10 | moa: | yes, lifting and accelerating |
| 05:01:10 | bramc: | It also may help to start in a thinner atmosphere as you said because you can accelerate faster without destroying the rocket |
| 05:01:40 | moa: | you have less drag friction so it takes less fuel |
| 05:01:59 | ggreer: | rockets lose what, 2km/sec ∆v due to gravity losses and atmosphere? it's significant, but not a game-changer |
| 05:03:08 | moa: | https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation ... now we're really OT |
| 05:06:31 | bramc: | 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:20 | CodeShark: | unless you're at relativistic speeds, doesn't F=ma continue to hold? |
| 05:08:21 | CodeShark: | and doesn't conservation of energy imply that it doesn't matter how quickly you accelerate? (again, assuming nonrelativistic speeds) |
| 05:09:09 | bramc: | 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:26 | ggreer: | 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:42 | CodeShark: | hmmm - but total energy (kinetic + potential) is also conserved |
| 05:10:15 | CodeShark: | I guess the catch here is that m is changing |
| 05:10:20 | ggreer: | yes |
| 05:10:20 | bramc: | CodeShark, Unfortunately you've got this giant momentum sink called 'the earth' |
| 05:11:33 | bramc: | Ironically nuclear rockets have a lot of problems because they tend to put out energy too slowly or, ahem, too quickly. |
| 05:12:14 | ThinThread: | what about https://en.wikipedia.org/wiki/EmDrive |
| 05:12:45 | ggreer: | 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:50 | bramc: | 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:19 | ggreer: | yeah. secondary payloads are pretty cheap these days. imagine how cheap they'll be when rockets are reusable |
| 05:13:21 | jgarzik: | yep :) |
| 05:13:49 | jgarzik: | and note that $1M is to-orbit price. includes a much-cheaper spacecraft, plus launch, plus insurance and other costs |
| 05:14:05 | jgarzik: | you can reduce a lot of that with volume in various places |
| 05:14:10 | bramc: | The miniaturization of satellites themselves helped a lot by the miniaturization of computers and cameras helps a lot of course |
| 05:14:13 | jgarzik: | that's the one-off price |
| 05:14:49 | jgarzik: | open source + commodity parts lowers costs greatly |
| 05:15:18 | bramc: | 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:28 | ggreer: | 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:39 | jgarzik: | bramc, indeed, that saves quite a bit :) |
| 05:15:44 | bramc: | Also dumping the manned program helps a lot |
| 05:27:07 | maaku: | bramc: ? |
| 05:28:57 | maaku: | manned space has done more than just about anything in bringing down cost per lb |
| 05:29:18 | maaku: | you only *need* heavy-lift for manned programmes |
| 05:33:42 | bramc: | maaku, It's a lot cheaper to not include the goldfish bowl |
| 05:35:19 | CodeShark: | it's also possible to abort the mission by just blowing it all up...without the negative PR aspect |
| 05:36:52 | CodeShark: | for some reason, dead astronauts tends to bug the public |
| 05:39:50 | CodeShark: | getting astronauts back to earth in one piece is very expensive |
| 05:40:15 | CodeShark: | one-way manned space program...now that has some potential :) |
| 05:46:49 | amiller: | jgarzik, i want to hear more about bitcoins and space plans |
| 05:47:05 | amiller: | somehow, that must be on-topic here! |
| 05:47:32 | amiller: | like, is it supposed to be some kind of science experiment? or something that bolsters the network |
| 05:49:54 | amiller: | ok i guess there's a lot more detail than ive ever seen before in the scrollback already.. |
| 05:51:19 | jgarzik: | 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:42 | Tebbo`: | Tebbo` is now known as Tebbo |
| 08:01:05 | Aquentin: | Aquentin is now known as Guest86574 |
| 08:05:17 | leguin.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:17 | leguin.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:17 | leguin.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:17 | leguin.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:17 | leguin.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:17 | leguin.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:05 | antanst: | antanst has left #bitcoin-wizards |
| 08:19:48 | phantomcircuit: | petertodd, note that micropayment channels make leaking of the change address significantly less of an issue |
| 08:56:37 | CodeShark: | how far along are you with the segregated witness thing, sipa? |
| 08:57:02 | CodeShark: | is there anything I can help you with? :) |
| 08:59:53 | sipa: | no, it was trivial to implement, it works |
| 09:00:06 | sipa: | we need tests :) |
| 09:04:42 | CodeShark: | so you essentially added an extra hash method |
| 09:05:27 | CodeShark: | you have four hashes now |
| 09:05:35 | CodeShark: | hash, hashWitness, hashFull, hashBitcoin |
| 09:06:31 | sipa: | the last one is for compatibility reasons |
| 09:06:52 | sipa: | but essentially, txid = hash of everything except witness data |
| 09:07:05 | sipa: | txidwitness = hash of just witness data |
| 09:07:23 | sipa: | blocks commit to txidfull = H(txid || txidwitness) |
| 09:07:32 | sipa: | but everything else just uses txid |
| 09:08:09 | sipa: | witness data is scriptsigs, but also the range proofs needed for confidential transactions |
| 09:08:30 | sipa: | they don't change the effect of a transaction, only theit validity |
| 09:09:47 | CodeShark: | right |
| 09:10:58 | sipa: | and since the range proofs are huge, this makes a large difference in the amount of data you need to download |
| 09:11:14 | sipa: | if you do not care for signature validation |
| 09:11:22 | CodeShark: | yeah, for sure |
| 09:11:36 | CodeShark: | we'll eventually want to move to a model where not everyone has to validate everything :) |
| 09:11:44 | CodeShark: | but something that actually works, unlike SPV |
| 09:14:39 | CodeShark: | and something where you CAN validate what's important to you without having to trust the prover |
| 09:15:37 | CodeShark: | so what you should do then is use H(txid || H(txidwitness)) |
| 09:16:19 | phantomcircuit: | CodeShark, tree of hashes of all the things in the transaction |
| 09:16:26 | CodeShark: | yeah |
| 09:16:27 | phantomcircuit: | download/validate only what you care about |
| 09:16:30 | CodeShark: | exactly |
| 09:20:32 | CodeShark: | 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:59 | CodeShark: | in principle, we don't need to revert an entire block just because of one bad transaction |
| 09:21:06 | CodeShark: | we can still use the block for PoW |
| 09:21:18 | CodeShark: | but just revert all the dependencies of that transaction |
| 09:22:01 | sipa: | 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:36 | sipa: | and the system's difficulty aimed for a constant not-on-main-chain rate, rather then constant block rate |
| 09:23:54 | CodeShark: | what do you mean by not-on-main-chain rate? |
| 09:24:21 | sipa: | it measures the recent percentage of blocks that are in such secondary parents |
| 09:24:38 | CodeShark: | are we still talking a single blockchain? or multiple blockchains? |
| 09:24:44 | sipa: | one dag |
| 09:25:04 | sipa: | which defines a chain by following only primary parents |
| 09:27:28 | CodeShark: | 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:01 | CodeShark: | so if the block turns out to be invalid, it is still used for PoW but the effects are voided? |
| 09:29:44 | CodeShark: | or two separate blocks entirely - one only used for PoW and the other used only for effects? |
| 09:30:42 | sipa: | no |
| 09:30:48 | sipa: | every block has two parents |
| 09:31:04 | sipa: | one from which it inherits utxo state and pow |
| 09:31:13 | sipa: | another from which it only inheritd pow |
| 09:31:37 | sipa: | the best-pow one with only valid first-parents wins |
| 09:32:07 | sipa: | the utxo set is defined by purely following the first parents up, and these need to be valid |
| 09:32:36 | sipa: | the blocks reachable through non-first parents count for pow, but are otherwise not validated |
| 09:32:59 | CodeShark: | ah, so the objective is to allow miners to create usable blocks without having to validate anything? |
| 09:33:32 | CodeShark: | do these PoW-only parents have parents as well? |
| 09:34:14 | CodeShark: | still not sure I'm getting it p |
| 09:34:26 | sipa: | they are just blocks |
| 09:34:34 | sipa: | and miners still have to validate everything |
| 09:34:53 | sipa: | it is just blocks that would have beenbreorged out in bitcoin |
| 09:35:08 | CodeShark: | oh, so something more akin to GHOST, in a sense |
| 09:35:09 | amiller: | its not a lot different than GHOST |
| 09:35:10 | sipa: | now become linked into the chain again as such a second parent |
| 09:35:12 | CodeShark: | ok :) |
| 09:35:15 | sipa: | lol |
| 09:36:08 | CodeShark: | the pow parents are what some are calling "uncles" |
| 09:37:33 | amiller: | yes |
| 09:37:36 | amiller: | so the difference is |
| 09:37:51 | amiller: | GHOST has some proposed incentive policy about how much reward the uncles get |
| 09:38:14 | amiller: | 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:36 | amiller: | also, in every GHOST proposal I know of, including ethereum's, there's still a fixed minimum-time parameter |
| 09:39:29 | amiller: | 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:50 | amiller: | no more magic block time number! hooray! defeating a magic parameter is its own reward |
| 09:40:30 | CodeShark: | so basically narrowing the variance |
| 09:40:54 | CodeShark: | and not wasting PoW in side chains |
| 09:41:54 | amiller: | yes |
| 09:42:28 | amiller: | i still think thats a good idea but i didn't finish it |
| 09:43:17 | amiller: | also why should there be any particular fixed fraction |
| 09:43:47 | CodeShark: | if you can incorporate pooled mining into it as well somehow, even more horray! :) |
| 09:44:58 | amiller: | basically i think people should spam their partial proofs of work as far as they can |
| 09:45:05 | CodeShark: | yeah |
| 09:45:47 | amiller: | somehow those shares should tolerate a "lossy" network |
| 09:45:54 | amiller: | like, it's okay if not everyone gets all of those |
| 09:46:20 | amiller: | the things that are currently really |
| 09:46:35 | amiller: | infrequent, and worth thousands of dollars, should still propagate everywhere |
| 09:47:23 | amiller: | i think this is about as well thought out as treechains :O |
| 09:48:44 | CodeShark: | it's a good start of something :) |
| 09:55:05 | CodeShark: | have you gotten as far as modeling anything, amiller? |
| 10:02:13 | amiller: | 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:31 | amiller: | 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:52 | CodeShark: | fblockchain - not sure I'm familiar with that one |
| 10:07:22 | CodeShark: | who are some of these actual people, btw? :) |
| 10:07:23 | amiller: | its kind of an overidealized "proof of publication"... it's a "simulation based definition" |
| 10:07:44 | amiller: | https://eprint.iacr.org/2014/765 |
| 10:07:46 | amiller: | .title |
| 10:07:46 | yoleaux: | Cryptology ePrint Archive: Report 2014/765 |
| 10:08:09 | amiller: | oh well: The Bitcoin Backbone Protocol: Analysis and Applications. Juan Garay and Aggelos Kiayias and Nikos Leonardos |
| 10:15:31 | stonecoldpat: | 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:33 | CodeShark: | ah, I see |
| 10:17:19 | amiller: | yes! :D also we will release a preprint of that in a couple days or something |
| 10:25:07 | CodeShark: | sipa: no new genesis block for elements alpha? |
| 10:25:53 | sipa: | eh yes there is |
| 10:26:06 | sipa: | the format for blocks is even different |
| 10:26:23 | CodeShark: | so then it must be somewhere other than chainparams.cpp |
| 10:26:31 | sipa: | no? |
| 10:26:32 | CodeShark: | because in there I only see the familiar one |
| 10:26:40 | CodeShark: | or the familiar two, I should say :p |
| 10:26:49 | sipa: | are you looking in the ElementsProject/elements, branch alpha? |
| 10:26:51 | CodeShark: | The Times 03/Jan/2009 Chancellor on brink of second bailout for banks |
| 10:26:56 | CodeShark: | oh, branch alpha |
| 10:27:05 | CodeShark: | yes |
| 10:27:07 | CodeShark: | I am |
| 10:27:15 | CodeShark: | https://github.com/ElementsProject/elements/blob/alpha/src/chainparams.cpp |
| 10:27:35 | stonecoldpat: | amiller: awesome looking forward to it |
| 10:28:35 | sipa: | CodeShark: perhaps the message wasn't changed |
| 10:28:49 | sipa: | but the serialized format of blocks is different |
| 10:29:02 | sipa: | as it has signatures instead of pow |
| 10:29:15 | CodeShark: | but the hash is the same, too :) |
| 10:29:26 | CodeShark: | 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f |
| 10:29:56 | CodeShark: | did you break sha256, sipa? :) |
| 10:33:04 | sipa: | heh |
| 10:33:13 | sipa: | what are you looking at? |
| 10:33:24 | CodeShark: | chainparams.cpp |
| 10:33:38 | CodeShark: | class CMainParams |
| 10:34:21 | CodeShark: | it looks a little bit too familiar ;) |
| 10:39:28 | sipa: | look at testnet |
| 10:39:34 | sipa: | there is no alpha mainnet |
| 10:39:49 | sipa: | but we probably did not remove it from chainparams |
| 10:40:46 | CodeShark: | ok, yeah - CTestNetParams does look a little different |
| 10:42:13 | CodeShark: | so when it runs it just uses testnet...and the --testnet option does nothing? |
| 10:46:34 | CodeShark: | the default datadir needs to be changed as well |
| 10:46:55 | CodeShark: | and the pid |
| 11:06:59 | sipa: | CodeShark: you can run --notestnet, but it will fail if you fo |
| 11:07:21 | sipa: | the datadir should be ~/.bitcoin/alphatestnet3 |
| 11:08:14 | CodeShark: | oh, hmmm |
| 11:08:35 | CodeShark: | I was thinking perhaps it would be a good idea to move it into an entirely separate directory |
| 11:08:58 | CodeShark: | makes it harder to corrupt an existing bitcoind installation |
| 11:11:17 | CodeShark: | the two databases are diverging quickly, after all - and will be less and less mutually compatible :p |
| 11:13:06 | CodeShark: | and then https://github.com/ElementsProject/elements/blob/alpha/src/util.cpp#L480 |
| 11:15:35 | jrayhawk_: | jrayhawk_ is now known as jrayhawk |
| 11:30:32 | CodeShark: | time for bed - I'll continue checking it out tomorrow, sipa |
| 11:33:42 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 11:45:16 | sipa: | CodeShark: 'diverging' ? |
| 11:45:26 | sipa: | they're entirely separate, all the time |
| 13:23:16 | antanst: | antanst has left #bitcoin-wizards |
| 14:59:49 | bramc: | Because the subject hasn't been done to death already: https://medium.com/@bramcohen/bitcoin-s-ironic-crisis-32226a85e39f |
| 15:01:56 | chmod755: | "principles on which Bitcoin was founded"......... |
| 15:11:39 | DougieBot5000_: | DougieBot5000_ is now known as DougieBot5000 |
| 15:24:33 | temujin: | temujin has left #bitcoin-wizards |
| 15:30:01 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 16:14:44 | wallet42: | wallet42 is now known as Guest9149 |
| 16:14:44 | wallet421: | wallet421 is now known as wallet42 |
| 16:29:13 | Pasha: | Pasha is now known as Cory |
| 16:36:50 | blablaa: | are there some altcoins working entirely using tx fees? |
| 16:37:20 | sipa: | did you use 'altcoins' and 'working' in the same sentence? |
| 16:37:35 | blablaa: | sipa, well yes... |
| 16:38:02 | sipa: | there are a few who have done interesting development, but they are a very small minority |
| 16:38:06 | sipa: | also, offtopic here |
| 16:38:36 | blablaa: | sipa, it's related to bitcoin because bitcoin as it is is supposed to be funded by tx fees in the future |
| 16:39:05 | sipa: | blablaa: that is a controversial position |
| 16:40:30 | blablaa: | 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:40 | zooko: | blablaa: I think your question is a good one. |
| 16:41:52 | zooko: | blablaa: I think the answer to it is: the evidence from altcoins so far doesn't tell us. |
| 16:42:06 | sipa: | agree with zooko |
| 16:45:12 | blablaa: | zooko, ok, thx for your answer, i'll wait for more answers :) |
| 16:48:04 | bramc: | The current transaction rate in altcoins seems unlikely to be able to keep things stable based on transaction fees alone |
| 16:48:35 | sipa: | yes, you need a simulation of an economy for that |
| 16:48:49 | sipa: | blablaa: also, apologies, i thought we were on #bitcoin-dev |
| 16:49:01 | zooko: | sipa: Oh, I was wondering about that. So this topic *is* on topic here? |
| 16:49:20 | sipa: | i would say so |
| 16:49:24 | zooko: | Cool. |
| 16:49:40 | sipa: | people talk about (interesting) changes to bitcoin all the time here, including those implemented in altcoins |
| 16:50:12 | tromp_: | this could be called bitcoin-fantasies :) |
| 16:50:18 | zooko: | lol |
| 16:58:01 | adam3us: | 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:22 | kanzure: | "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:34 | adam3us: | 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:58 | adam3us: | bramc: wow that text got mangled some how! |
| 17:01:02 | bramc: | 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:03 | adam3us: | 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:34 | bramc: | 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:50 | adam3us: | 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:03 | bramc: | (because, apparently, there isn't enough stress in my life, so I'm proactively delving into bitcoin) |
| 17:02:29 | bramc: | Thanks for the props, adam3us |
| 17:03:15 | bramc: | I've gotta run now, laters everybody |
| 17:50:01 | heath: | did discussion die down in the mailing list or all the messages ping requests / test messages |
| 17:50:12 | heath: | or +are all the... |
| 17:56:40 | antanst: | antanst has left #bitcoin-wizards |
| 18:02:56 | adam3us: | adam3us has left #bitcoin-wizards |
| 18:37:17 | heath: | * heath finally sees acitivity beyond ping requests o/ |
| 19:07:28 | qawap_: | qawap_ is now known as qawap |
| 19:37:54 | StephenM347: | "Your membership in the mailing list Bitcoin-development has been disabled due to excessive bounces..." |
| 19:37:59 | StephenM347: | Anyone else get this? |
| 19:38:33 | kanzure: | yep |
| 19:38:37 | kanzure: | check #bitcoin-dev irc logs |
| 19:39:14 | StephenM347: | kanzure: thanks, will do |
| 19:42:52 | StephenM347: | kanzure: http://bitcoinstats.com/irc/bitcoin-dev/logs/ doesn't seem to offer a search? |
| 19:44:39 | kanzure: | brutal... hmm. |
| 19:44:58 | kanzure: | well, one of the emails to bitcoin-development@lists.sourceforge.net mentioned this, so perhaps view that email thread |
| 20:54:24 | lnsybrd_: | lnsybrd_ is now known as lnsybrd |
| 21:47:59 | wallet421: | wallet421 is now known as wallet42 |
| 22:08:15 | temujin: | temujin has left #bitcoin-wizards |
| 23:36:39 | sipa: | sipa has left #bitcoin-wizards |
| 23:47:54 | CodeShark: | is it possible to create an efficient accumulator that can be used to validate an entire transaction graph? |
| 23:48:23 | gmaxwell: | 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:36 | gmaxwell: | 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:09 | gmaxwell: | That latter issue makes it less exciting. |
| 23:51:08 | nwilcox: | CodeShark: I'm curious if an "accumulator" is also possible... |
| 23:51:29 | nwilcox: | gmaxwell: Are these additional comments merkle paths to block header for each txin? |
| 23:51:36 | nwilcox: | s/comments/commitments/ |
| 23:52:02 | c0rw|away: | c0rw|away is now known as c0rw1n |
| 23:52:58 | CodeShark: | 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:20 | gmaxwell: | 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:26 | gmaxwell: | stopped updating it when 99% of the effect it was having was feeding plagerism) |
| 23:54:04 | gmaxwell: | 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:42 | CodeShark: | right, well I only encountered it recently...so I'm a little behind :p |
| 23:55:20 | CodeShark: | if the cost of proofs are moved over to the sender, it could be conceivably made to scale |
| 23:55:54 | CodeShark: | the sender would only have to incorporate one more witness into the proof they got from each of their inputs |
| 23:56:19 | gmaxwell: | 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:17 | CodeShark: | why would only the block author have the updated accumulator state? |