<nsh>
or could add fee gossip to the network protocol but that would probably be gamed too
Giszmo has joined #bitcoin-wizards
<bramc>
leakypat, That depends on where you start and how quickly you raise
<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
n0n0_ has quit [Ping timeout: 246 seconds]
zooko has joined #bitcoin-wizards
KFl6WxEUI1Zbp2 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<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
<bramc>
CodeShark, Yes, exactly
<CodeShark>
however...by doing this they crowd out their own blocks
<CodeShark>
so there must be some equilibrium
<CodeShark>
given a sufficiently small range and a sufficiently large volume, miners would rather be honest than cheat
priidu has quit [Ping timeout: 264 seconds]
<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
JackH has quit [Ping timeout: 244 seconds]
<CodeShark>
they could only really set their own prices by forming a cartel, though - miners can already choose to block transactions at will
<bramc>
Individual mining pools are big enough to pull it off
<CodeShark>
so I think the conclusion is that any fee estimation must also use unconfirmed propagated transactions (mempool)
<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
<bramc>
That would help a bit, but it's much safer to only trust your own local experience
<CodeShark>
by own local experience you mean just your own attempts to send?
<bramc>
Yeah
<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
<CodeShark>
but that seems rather expensive...and still isn't particularly fast
<bramc>
There's no point in probing until you have a payment you actually want to send
<CodeShark>
but you might not want the real transaction to take hours
<CodeShark>
so you probe a few hours before you'll make the real transaction
<CodeShark>
but you still miss things like daily cycles and other high frequency phenomena
<bramc>
No, you remember your last transaction which worked and start at half that rate
<bramc>
Actually I did my math wrong - that one should be four hours
<CodeShark>
well, three or four hours...still WAY too long
<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
<bramc>
too long for what?
<CodeShark>
to send a transaction
<bramc>
You're free to make it go faster by doubling your fee every time
<bramc>
But that costs more, and is likely to hit bad parts of the daily cycle (taking a while might have inherent advantages)
<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
jtimon has quit [Ping timeout: 244 seconds]
<CodeShark>
so I think any practical approach will have to check the mempool
<leakypat>
bramc: I'm trying to picture the scenario, I guess it is systems bidding to settle large transactions?
<bramc>
bitcoin payments are not what you call fast. If you want fast transactions, you use micropayment channels
<bramc>
leakypat, In the long run it's likely to be that most transactions are large
<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
<leakypat>
I agree with you on this stuff, yes
<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
<leakypat>
So who's might be a lightning channel or centralized micropayment system bidding to settle their payments
<leakypat>
They just want the cheapest fee they can get and require settlement within x hours
<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
<bramc>
er, 45% I mean, but due to noise it may be worse
<bramc>
leakypat, micropayment channels can completely short circuit all of this stuff once their initial deposits are put down
<leakypat>
The channels have to close to the blockchain at some point right?
<bramc>
leakypat, When their net is settled out, yes
<leakypat>
Or have the possibility to do so
<leakypat>
Yes, that's what I was imagining
<sl01>
is there any issue using centralized service(s) that provide APIs to wallet to get fee estimate information?
<sl01>
and those services can use whaterver witchcraft they want to provide you best guess information on fee and conf times
<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
c0rw|afk is now known as c0rw|zZz
<bramc>
sl01, We're discussing the mechanics of that
<leakypat>
It will be on the miners interests to have a transparent fee market
<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"
<leakypat>
Although , Hmm, there is no guarantee who is going to mine which block ... Interesting
<bramc>
sl01, Well 'no requests' is a simple to implement API :-)
<sl01>
which makes the problem much harder
<leakypat>
So users aren't direct customers in that sense
<sl01>
thats why i was just wondering if it might become 100x easier if you just "rely on a service"
<CodeShark>
everything is a lot easier if you just "rely on a service"
<CodeShark>
the challenge is how not to
<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
<sl01>
right, and for some things in bitcoin you dont want to, but this seems like the sort of thing its ok to
Aquentin has quit [Ping timeout: 252 seconds]
<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
<sl01>
but it seems like a service has a much better chance of giving dynamic/contextual fee estimates than some code built into clients
<bramc>
sl01, Eh... sort of. It can possibly come up with more accurate amounts faster.
<bramc>
sl01, But you'll always be able to get payments sent with lower transaction fees if you're willing to wait longer
<bramc>
Possibly vasty different. It wouldn't surprise me to get a daily cycle of fees with swings of 10x
<CodeShark>
I think we need to consider these as somewhat separate use cases
<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
<CodeShark>
there'
<CodeShark>
there could even be a market for "fee market makers" :p
<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
<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
<bramc>
Maybe smart wallets could recombine their dust in the middle of the night.
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Read error: Connection reset by peer]
d1ggy_ has joined #bitcoin-wizards
<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
<CodeShark>
hmm - it's tricky :)
<CodeShark>
not sure I like the idea of entities having mining contracts on behalf of clients
<bramc>
I'm proposing straight escalator as a starting point. It should be the beginning.
d1ggy has quit [Ping timeout: 255 seconds]
belcher has quit [Quit: Leaving]
<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?
Quanttek has quit [Ping timeout: 272 seconds]
<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.
<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%
<bramc>
This is a very conservative approach which is optimizing for low fees over time, although its amounts of time aren't crazy
<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
<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
<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?
<bramc>
sl01, petertodd's code has a minimum increment
<sl01>
ah cool, didnt see that
<bramc>
Although there is an interesting question of how escalator might interact with the minimum increment, which I think is rather large right now
<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)
<bramc>
One could reasonably argue that the minimum increment should be a percentage
<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
<CodeShark>
yes, please do that
<CodeShark>
I really wish people would stop claiming that we need to make Bitcoin integration possible for even idiots
<ggreer>
oh, zero confirmations. for a second I thought you talking about zero configuration networking
<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.
<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
<CodeShark>
in infosec, "I've never gotten hacked before so it's probably OK to continue doing" is how many downfalls begin :)
<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.
<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
<CodeShark>
and encouraging people to accept them just to "boost adoption" is folly
<CodeShark>
might as well encourage people to use shitty passwords to encourage more "online banking"
<CodeShark>
I don't even understand why this would be controversial
<CodeShark>
other than complete myopia
<bramc>
It isn't very controversial in this crowd, except for two people, you'd have to ask them why they like it
<jgarzik>
c.f. the mailing list to which I responded
<leakypat>
Bitcoin has been sold as send money anywhere in the world instantly for free
<jgarzik>
plenty of business cases where zero conf works just fine -- it's in the realm of business risk
<jgarzik>
physically shipping goods - just fine to initiate order @ 0-conf
<jgarzik>
it doesn't go out the door until confirmed. order processing occurs in parallel with confirmations
<jgarzik>
ditto subscriptions - the good can be revoked
<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
<CodeShark>
thoroughly
<petertodd>
jgarzik: it'd really help this discussion if for those cases you said you weren't relying on zeroconf
<petertodd>
jgarzik: I'm finding people thinking that zeroconf means someone other than the sender can cancel the tx
<CodeShark>
basically, if you choose to accept unconfirmed transactions you can no longer rely on bitcoin's security model at all
<CodeShark>
so you need to create another security model
<jgarzik>
correct
MrTratta has quit [Read error: Connection timed out]
<jgarzik>
zero conf = zero security, by default
<jgarzik>
It does not however mean zero security holistically, when including business risk and business case
MrTratta has joined #bitcoin-wizards
<bramc>
jgarzik, That isn't really zero conf, it's delaying the conf until later
<bramc>
real zeroconf is letting you take money out of the ATM
<jgarzik>
yep
<jgarzik>
bramc, nevertheless, programmatically Some Things Happen at zero confirmations at legit merchants without introducing risk
<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
<jgarzik>
correct
<leakypat>
I suppose the question is, should the fact these external systems exists dictate how the Bitcoin protocol is developed?
<bramc>
Also authorizing the customer to walk out of the store with the goods
<jgarzik>
i.e. some businesses get ID and/or take pictures of their customers, which provides recourse and mitigate risk
<jgarzik>
amusingly to address chargeback fraud primarily
<jgarzik>
leakypat, dictate - no - however it is true that you cannot just nuke zero-conf without a What To Transition To plan
<jgarzik>
ie. no mainstream wallet yet supports even 2-way payment channels
<bramc>
jgarzik, Arguably it only matters for vendors of ATMs and payment processors who rely on it
<jgarzik>
Just complaining or nuking does nothing to help users today
<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.
<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
<bramc>
jgarzik, The points that zeroconf has no real security and what should be done about it are two separate things
<jgarzik>
bramc, e.g. You seem to have missed the relevant mailing list discussion
<jgarzik>
that CodeShark participated in
<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"
<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
<bramc>
I'm not on the mailing list
fanquake has joined #bitcoin-wizards
<CodeShark>
it just moved today
<CodeShark>
still not 100% it's all fully working yet...but we'll see :)
<CodeShark>
I'd be happy to write more on this topic, jgarzik. I think people sometimes get too extreme on both sides
<bramc>
I just looked up the mailing list and was going to ask why it's on sourceforge
<CodeShark>
security isn't really about a few crypto algorithms, schemes, and protocols - these are merely tools. it's about managing risk.
<jgarzik>
nod
<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 :)
<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
<CodeShark>
well, it is a potentially serious problem
<petertodd>
jgarzik: hang around bankers more often :)
<petertodd>
jgarzik: and regulators
<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
<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
<CodeShark>
why are they killing Bitcoin to do this?
<petertodd>
CodeShark: enforcing AML/KYC - remember that these are the people who are happy to stop hawala if they can find a way
<bramc>
Yeah, umm, bitcoin-backed credit cards aren't too exciting if they're just ordinary credit cards with bitcoin headaches added on
<petertodd>
CodeShark: it's not about alternatives, is that from their perspective Bitcoin shouldn't exist in its current form (where their==regulators)
<CodeShark>
if you're a regulated entity with contracts and all that, why use a trustless p2p protocol at all?
<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
zmanian has joined #bitcoin-wizards
Dr-G has joined #bitcoin-wizards
Dr-G has joined #bitcoin-wizards
<CodeShark>
Bitcoin RIP...2009-20??
<petertodd>
CodeShark: eventually the sun explodes and we all die - I'll make that prediction :P
<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...
Dr-G has quit [Read error: Connection reset by peer]
Dr-G has joined #bitcoin-wizards
Dr-G has quit [Read error: Connection reset by peer]
Dr-G2 has quit [Ping timeout: 256 seconds]
<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
<petertodd>
bramc: one of those things where you don't be too restrictive
Dr-G has joined #bitcoin-wizards
<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
Dr-G has quit [Read error: Connection reset by peer]
<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
<petertodd>
bramc: the blocksize issue *does* come up in these discussions
Dr-G has joined #bitcoin-wizards
<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
<bramc>
KYC is a ludicrously expensive program for the actual amount of law enforcement it results in
<petertodd>
bramc: indeed
moa has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
jaekwon has quit [Remote host closed the connection]
<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
<bramc>
err, I mean replace by fee, I guess that's the term of art for actually malleating transactions in practice
<bramc>
malleating by changing the outputs I mean
<bramc>
Arguably now that one major pool is accepting rbf the jig is up and everyone else will just follow
erasmosp_ has quit [Remote host closed the connection]
<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
<leakypat>
In one sense a lot of companies / people are pushing adoption to the wrong use case
<jgarzik>
bramc, FSS RBF, not full RBF
<moa>
leakypat: only misinformed people were 'selling' bitcoin as instant
<jgarzik>
petertodd, they are doing something w/ AML too
<jgarzik>
don't know what
<petertodd>
jgarzik: god help us... purely on the basis of shit names :)
yossef has left #bitcoin-wizards [#bitcoin-wizards]
<moa>
... and ye shall know them by there fruit
<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.
<moa>
hide in the weeds versus hide in the crowds
<leakypat>
bramc eg. If I hop to user c via user b? User b will see my transactions
<petertodd>
bramc: note how lightning is not unlike Tor in this respect when you think about it
<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...
<bramc>
petertodd, Yes you could in principle provide onion payment services through lightning
yossef has joined #bitcoin-wizards
<bramc>
leakypat, Yeah that's the idea
<leakypat>
bramc: you add new inputs and outputs as required
<leakypat>
As long as the original ones are still there
<petertodd>
bramc: exactly! :)
<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
<petertodd>
bramc: equally, hub-and-spoke can do privacy tech like chaum tokens pretty easily and obviously
<petertodd>
bramc: yeah, that's kinda ugly
<leakypat>
bramc: yes
<bramc>
For fee increases you want the exact opposite, that outputs can only go down and no new outputs can be added
<leakypat>
Yeah really you would just drop the value of your change output, but which one is the change?
<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
<petertodd>
leakypat: whichever one you want it to be ;)
<jgarzik>
bramc, which sucks for privacy
<leakypat>
s/really/ideally
<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
<bramc>
jgarzik, And forcing a new input to be added is arguably even worse
hashtagg_ has quit [Ping timeout: 265 seconds]
<petertodd>
bramc: yeah, yet another reason why estimating the fee correctly in the first place is ideal
<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.
<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.
<bramc>
I mean, it can wind up in bizarre and incorrect feedback loops.
<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
<petertodd>
bramc: making a bad estimate once in awhile isn't such a big deal
<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.
<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
<petertodd>
bramc: (f2pool implementing full-rbf was kinda surprising to me actually)
<bramc>
didn't jgarzik just say that f2pool only implemented fss-rbf?
<jgarzik>
bramc, they went full first, then backed down to fuss
<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
* jgarzik
kicks autocorrect
<jgarzik>
bramc, they went full first, then backed down to fss
<petertodd>
bramc: (they're chinese, so there can be language barriers and misunderstandings obviously)
<leakypat>
So full rbf is what is required to do the fee adjustments in practice, otherwise you are adjusting transaction size and leaking privacy
<petertodd>
bramc: right now I think they knew exactly what they were doing :)
<petertodd>
leakypat: to be exact, the extra input is what is bad for privacy - you'll leak what your change output is
<jgarzik>
leakypat, nothing about RBF is privacy enhancing... you leak privacy no matter what you do
<petertodd>
leakypat: fss-rbf is worse than rbf, but they're both worse than guessing right in the first place
<jgarzik>
RBF is an outlier action
<jgarzik>
makes you stick out in the noise
<bramc>
the big problem with fss-rbf is that you're wasting transaction space while increasing your fee
<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.
<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
<bramc>
All this discussion is a good example of how you actually need to hit the transaction limit for things to actually get solved
<petertodd>
bramc: which we've done! changetip is one such example
KFl6WxEUI1Zbp2 has joined #bitcoin-wizards
<bramc>
petertodd, I don't see how changetip fixes anything btc-related other than just avoiding it completely
<petertodd>
bramc: prior to changetip there were on-chain tipping services, where much of the tip was eaten up by fees
<petertodd>
bramc: it might not be a pretty solution, but it very much is a solution
<petertodd>
bramc: for a service like changetip where the average person might have $20 max deposited, there's just not much demand for security
* leakypat
wonders if mining will end up with cartel style fee pricing
<petertodd>
leakypat: explain?
<leakypat>
They just come to a general agreement of what the fees should be and all play ball
<petertodd>
leakypat: if they enforced that, they'd need to 51% attack other miners...
<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
<petertodd>
leakypat: note how jgarzik's miner vote proposal is not unlike a gentlemanly and safe way of negotiating such a cartel
<leakypat>
petertodd: I don't understand the 51% attack thing..?
<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
hashtagg_ has joined #bitcoin-wizards
<petertodd>
leakypat: if 75% of miners play ball, and the other 25% don't... then what? (esp. in an unlimited blocksize scenario)
<petertodd>
bramc: you're probably not familiar with the sorrid history of gavin's fee estimator... :)
<jgarzik>
petertodd, sorry, you continue to vastly oversimplify BIP 100 to the point of being inaccurate
<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
<leakypat>
petertodd: I see
<bramc>
petertodd, I am not. From that comment it sounds like it's about as troubled as I'd expect.
<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
<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
<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
prodatalab has quit [Ping timeout: 248 seconds]
<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
<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
<bramc>
petertodd, I've foreseen those problems and didn't even have to code them up to realize it :-P
<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 :)
<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
<bramc>
Unfortunately it doesn't work at all in fss-rbf world
<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 :)
hashtagg_ has quit [Ping timeout: 248 seconds]
<bramc>
Yes that's fine although presumably a large number of transactions are on the edge
<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 :(
<bramc>
And also I'm guessing the daily cycle will be quite prominent
<bramc>
petertodd, *insert rant about how the ethos of bitcoin is that broken software will be weeded out and die here*
<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
<bramc>
Presumably the not-time-sensitive applications will need different fee setting algorithms
<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
jmcn_ has quit [Ping timeout: 277 seconds]
jmcn has joined #bitcoin-wizards
<bramc>
The only way to find out is to have real fees with algorithms which set the fees properly and see what happens
<bramc>
A bit advantage of escalator is that it clearly works properly. The stuff about using mempool seems dubious.
<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
hashtag_ has joined #bitcoin-wizards
<jgarzik>
and insert block size debate at this point :)
<jgarzik>
no real fees without block pressure
<jgarzik>
economic policy -- for years -- has been to suppress fee pressure
hashtag_ has quit [Ping timeout: 244 seconds]
justanot1erusr has joined #bitcoin-wizards
justanotherusr has quit [Quit: Reconnecting]
<bramc>
What does cpfp stand for?
<jgarzik>
bramc, Child Pays For Parent. A secondary transaction boosts the priority of the primary transaction. 2nd tx adds fees to 1st.
<bramc>
jgarzik, You keep saying that but I'm not sure what you're referring to, other than the raising of the soft limit
<bramc>
Oh right. cpfp has overhead and may need to increase its own fee, which runs into the same issues
justanot1erusr has quit [Ping timeout: 252 seconds]
<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
justanotherusr has joined #bitcoin-wizards
<leakypat>
CPFP is worse because you have to pay twice too
KFl6WxEUI1Zbp2 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[7] has quit [Ping timeout: 256 seconds]
<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
<bramc>
jgarzik, Huh? There's a transaction rate limit and it hasn't been hit yet. When it is hit there will be pressure
jaekwon has joined #bitcoin-wizards
<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
jaekwon has quit [Remote host closed the connection]
<jgarzik>
bramc, The block size limit, which implies the transaction rate limit, yes. The current community debate is about raising that limit.
<jgarzik>
bramc, when that happens there will be little fee pressure
<jgarzik>
bramc, which has been the case historically for years
<jgarzik>
bramc, anytime fee pressure approaches, people lobby miners to raise their soft limit, eliminating fee pressure
<bramc>
jgarzik, I for one am very strongly against raising that limit, for a number of reasons
<bramc>
One of them being that low transaction fees are a bad thing unto themselves
<moa>
anybody know what a BIP 47 payment code actually looks like?
<moa>
i.e. data format?
<jgarzik>
bramc, <shrug> 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.
TheSeven has joined #bitcoin-wizards
<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.
<bramc>
jgarzik, Raising the limit is the thing which optimizes for the short term at the expense of the long term
KFl6WxEUI1Zbp2 has joined #bitcoin-wizards
<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
<bramc>
Plus damage to the credibility of the claim that bitcoin isn't centrally controlled
<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.
<jgarzik>
bramc, i.e. externalities
<bramc>
jgarzik, A single order of magnitude increase changes very few of those calculations.
<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.
<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.
<bramc>
I meant to say that full-rbf doesn't make it less useful
<jgarzik>
From that narrow perspective, fss-rbf is simply less damaging
KFl6WxEUI1Zbp2 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<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
<jgarzik>
bramc, agree with the latter statement (temporary)
<jgarzik>
bramc, It very much depends on the real world risk scenario whether it is sane or not
<jgarzik>
In fact, I think a timeline for deploying full-RBF would help focus people
<jgarzik>
Wallet software and other stuff needs much work still
<bramc>
That is something I would be fine with
<petertodd>
jgarzik: potentially could be done with a Bitcoin Core release that enabled full-RBF at a specific date in the future
sadoshi has joined #bitcoin-wizards
<jgarzik>
petertodd, I'm OK with that
<jgarzik>
petertodd, Decidedly -not- OK with surprise rollouts the community is not prepared for
<bramc>
Wow, we're having actual productive discussion
<petertodd>
jgarzik: rough guess, how far into the future?
<jgarzik>
petertodd, rough guess? 6 months too short, longer than 12 months probably too long
<petertodd>
jgarzik: 9 months it is :)
<bramc>
9 months sounds great
<jgarzik>
Have to upgrade -all- wallet software, websites, decentralized wallets, etc.
<jgarzik>
Have to endorse a useful solution like CLTV+paychan
<jgarzik>
ie. wallet software authors need to know a direction other than "panic!"
KFl6WxEUI1Zbp2 has joined #bitcoin-wizards
<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?
<bramc>
uh, dumb question, what is cltv?
<petertodd>
bramc: CHECKLOCKTIMEVERIFY - BIP65 - my baby :)
<bramc>
Also, the thing which full rbf breaks is zeroconf, not transaction fee pressure
<bramc>
petertodd, Is that including relative now? Is it in utxos or transactions or both?
<petertodd>
bramc: just absolute, to keep the # of lines of code changed down
<petertodd>
bramc: I 100% agree relative would be nice, but I wanted something *really* simple as a first-effort
<petertodd>
bramc: I've literally given more interviews about CLTV than there are lines of code in CLTV...
<moa>
CLTV is going into v0.11.0 ?
<jgarzik>
bramc, CLTV is _huge_. Freeze funds on-chain until X time.
<jgarzik>
lots of uses
<bramc>
petertodd, cltv in utxos is the least important thing, because cltv is already in transactions
<petertodd>
moa: well, it got a bunch of review by maaku for elements, which helps
<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
<bramc>
Although I agree that it's the simplest thing
<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.
<jgarzik>
Much better than proof-of-burn.
<jgarzik>
CLTV enables pay-to-future miner.
<jgarzik>
(freeze an anyone-can-spend TX)
<jgarzik>
CLTV must be integrated ASAP. :)
<petertodd>
jgarzik: CLTV is both a floor wax and a dessert topping!
<jgarzik>
and sex lube too
<moa>
jgarzik: california loosens the tongue
<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 :-)
<bramc>
jgarzik, You're in the bay area now? I'm headquartered here.
<jgarzik>
bramc, agree -- the main issue is that locktime transactions are not relayed across the network, nor remembered in mempools. easy DoS + malleate.
<jgarzik>
gotta get it into the chain.
<CodeShark>
making timelock part of the script is far more powerful
<jgarzik>
yep
<bramc>
Although relative timelock, both in transactions and utxos, should get in asap as well.
<petertodd>
jgarzik: +1
<petertodd>
jgarzik: (the sex lube bit)
<CodeShark>
gotta work on the branding
<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.
<jgarzik>
based in Atlanta
<bramc>
jgarzik, I can't tell if that's satire
<jgarzik>
bramc, nope 100% truth
cosmo has joined #bitcoin-wizards
<bramc>
jgarzik, I... I can't... I don't know what to say
<jgarzik>
bramc, rackspace in space
<bramc>
Because latencies on earth are too low?
<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.
<bramc>
The latencies on earth are mostly incurred at the local ISP and by limitations in the speed of light.
<CodeShark>
you don't really gain much in the latter, do you?
<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.
<jgarzik>
bramc, yes - it's the hops - in space has fewer optical hops at speed of light
<jgarzik>
easier to repair than sea cables too
<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
<jgarzik>
Let's just say you can do a lot with worldwide global broadcast network
<zooko>
lol ; I love this channel. Especially the bit about "CTLV must be deployed!"
<zooko>
I think I might have played a role in getting petertodd started on CTLV.
<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
<jgarzik>
all other sats are "dumb" repeaters with no trustless crypto security vis the ground
<KFl6WxEUI1Zbp2>
all other ^bitcoin sats?
<bramc>
The best use of super low latency communications is price arbitrage between the london and nyc stock exchanges
<jgarzik>
all other satellites besides my own BitSats
<moa>
jgarzik: could i reserve some dedicated hardware on a BitSat ... sole access, etc?
<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
<CodeShark>
when does economy of scale start to kick in?
<moa>
ah
<moa>
celtic
shesek has joined #bitcoin-wizards
<jgarzik>
CodeShark, "soon but not yet"
<jgarzik>
when Elon's or Branson's 1000+ constellations start going up, then you see real volume
<moa>
yeah when SpaceX gets true private competitor
<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
<CodeShark>
or other form of propulsion where the fuel doesn't need to be carried on board
<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
<bramc>
space elevator doesn't work from a cost standpoint. Skylon does work in principle.
<jgarzik>
bramc, yes and no -- currently rockets are built and then thrown away. Imagine costs involved in building a one-time-use 747 airplane.
<moa>
orbital service stations could change craft design
<jgarzik>
fuel itself is cheap
<jgarzik>
CodeShark, long way off
<jgarzik>
reuseable rockets bring launch costs down to that of a first class ticket to Paris
<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
<jgarzik>
think scale, too -- smallsat rockets are much smaller. One company is using high altitude balloons + old missiles.
<jgarzik>
airplanes and balloons already exist for a usable first stage
<jgarzik>
*reusable
<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
<CodeShark>
certainly not very fast
<CodeShark>
but they can get you pretty high
<jgarzik>
exactly
<bramc>
CodeShark, Not really so high, the atmosphere gets thin fairly quickly
<CodeShark>
looks like the unmanned gas balloon record is 53km
<bramc>
CodeShark, Yeah last I ran numbers getting 100km in the air didn't seem like much of a boost
<moa>
if the air's thin then accelerating the craft is a lot cheaper
<moa>
and speed is ultimately what you want
<moa>
deltaV
<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
<jgarzik>
moa: yep
<moa>
well every pound less fuel is an additional pound of payload
<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.
<moa>
yes, lifting and accelerating
<bramc>
It also may help to start in a thinner atmosphere as you said because you can accelerate faster without destroying the rocket
<moa>
you have less drag friction so it takes less fuel
<ggreer>
rockets lose what, 2km/sec ∆v due to gravity losses and atmosphere? it's significant, but not a game-changer
<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
<CodeShark>
unless you're at relativistic speeds, doesn't F=ma continue to hold?
<CodeShark>
and doesn't conservation of energy imply that it doesn't matter how quickly you accelerate? (again, assuming nonrelativistic speeds)
<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
<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)
<CodeShark>
hmmm - but total energy (kinetic + potential) is also conserved
<CodeShark>
I guess the catch here is that m is changing
<ggreer>
yes
<bramc>
CodeShark, Unfortunately you've got this giant momentum sink called 'the earth'
cosmo has quit [Quit: Leaving]
<bramc>
Ironically nuclear rockets have a lot of problems because they tend to put out energy too slowly or, ahem, too quickly.
<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
<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.
<ggreer>
yeah. secondary payloads are pretty cheap these days. imagine how cheap they'll be when rockets are reusable
<jgarzik>
yep :)
<jgarzik>
and note that $1M is to-orbit price. includes a much-cheaper spacecraft, plus launch, plus insurance and other costs
<jgarzik>
you can reduce a lot of that with volume in various places
<bramc>
The miniaturization of satellites themselves helped a lot by the miniaturization of computers and cameras helps a lot of course
<jgarzik>
that's the one-off price
<jgarzik>
open source + commodity parts lowers costs greatly
<bramc>
jgarzik, Also literally ditching designs which were either from the 60s or based on using contractors in a particular senator's home state
<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
<jgarzik>
bramc, indeed, that saves quite a bit :)
<bramc>
Also dumping the manned program helps a lot
frankenmint has joined #bitcoin-wizards
shesek has joined #bitcoin-wizards
fanquake has quit [Ping timeout: 275 seconds]
KFl6WxEUI1Zbp2 has quit [Max SendQ exceeded]
<maaku>
bramc: ?
<maaku>
manned space has done more than just about anything in bringing down cost per lb
<maaku>
you only *need* heavy-lift for manned programmes
GAit has quit [Read error: Connection reset by peer]
<bramc>
maaku, It's a lot cheaper to not include the goldfish bowl
GAit has joined #bitcoin-wizards
<CodeShark>
it's also possible to abort the mission by just blowing it all up...without the negative PR aspect
<CodeShark>
for some reason, dead astronauts tends to bug the public
droark has quit [Quit: ZZZzzz…]
frankenmint has quit [Remote host closed the connection]
GAit has quit [Remote host closed the connection]
<CodeShark>
getting astronauts back to earth in one piece is very expensive
<CodeShark>
one-way manned space program...now that has some potential :)
Giszmo has quit [Quit: Leaving.]
<amiller>
jgarzik, i want to hear more about bitcoins and space plans
<amiller>
somehow, that must be on-topic here!
<amiller>
like, is it supposed to be some kind of science experiment? or something that bolsters the network
<amiller>
ok i guess there's a lot more detail than ive ever seen before in the scrollback already..
<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)
_biO_ has joined #bitcoin-wizards
sy5error has quit [Remote host closed the connection]
Xh1pher has joined #bitcoin-wizards
_biO_ has quit [Read error: Connection reset by peer]
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
antanst has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
mjerr has joined #bitcoin-wizards
Xh1pher has quit [Read error: Connection reset by peer]
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
Xh1pher has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
pollux-bts has quit [Quit: Connection closed for inactivity]
btcdrak has quit [Quit: Connection closed for inactivity]
gill3s has joined #bitcoin-wizards
Tebbo` is now known as Tebbo
wallet42 has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
bramc has quit [Quit: This computer has gone to sleep]
ThomasV has quit [Ping timeout: 252 seconds]
n0n0_ has joined #bitcoin-wizards
paveljanik has quit [Ping timeout: 264 seconds]
priidu has joined #bitcoin-wizards
rht__ has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
Aquentin has joined #bitcoin-wizards
Aquentin is now known as Guest86574
andy-logbot has quit [Remote host closed the connection]
andy-logbot has joined #bitcoin-wizards
* andy-logbot
is logging
ThomasV has joined #bitcoin-wizards
antanst has left #bitcoin-wizards [#bitcoin-wizards]
jcluck has quit [Read error: Connection reset by peer]
mkarrer has quit [Read error: Connection reset by peer]
jcluck has joined #bitcoin-wizards
fanquake has joined #bitcoin-wizards
mkarrer has joined #bitcoin-wizards
Guest86574 has quit [Quit: Leaving]
darwin__ has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
phantomcircuit has quit [Ping timeout: 250 seconds]
kanzure has quit [Ping timeout: 250 seconds]
kanzure has joined #bitcoin-wizards
rubensayshi has joined #bitcoin-wizards
fanquake has quit [Quit: Leaving.]
yossef has quit [Ping timeout: 255 seconds]
phantomcircuit has joined #bitcoin-wizards
MrTratta has quit [Ping timeout: 264 seconds]
<phantomcircuit>
<phantomcircuit> petertodd, note that micropayment channels make leaking of the change address significantly less of an issue
MrTratta has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
Quanttek has joined #bitcoin-wizards
CoinMuncher has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 244 seconds]
hearn has quit [Read error: Connection reset by peer]
hearn has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
orperelman has joined #bitcoin-wizards
ThomasV has quit [Quit: Quitte]
MrTratta has quit [Ping timeout: 246 seconds]
<CodeShark>
how far along are you with the segregated witness thing, sipa?
MrTratta has joined #bitcoin-wizards
<CodeShark>
is there anything I can help you with? :)
cdecker has joined #bitcoin-wizards
<sipa>
no, it was trivial to implement, it works
<sipa>
we need tests :)
priidu has quit [Ping timeout: 252 seconds]
priidu has joined #bitcoin-wizards
<CodeShark>
so you essentially added an extra hash method
<sipa>
but essentially, txid = hash of everything except witness data
<sipa>
txidwitness = hash of just witness data
MrTratta has quit [Ping timeout: 244 seconds]
<sipa>
blocks commit to txidfull = H(txid || txidwitness)
<sipa>
but everything else just uses txid
Quanttek has quit [Ping timeout: 276 seconds]
MrTratta has joined #bitcoin-wizards
<sipa>
witness data is scriptsigs, but also the range proofs needed for confidential transactions
<sipa>
they don't change the effect of a transaction, only theit validity
Quanttek has joined #bitcoin-wizards
<CodeShark>
right
airbreather has joined #bitcoin-wizards
<sipa>
and since the range proofs are huge, this makes a large difference in the amount of data you need to download
<sipa>
if you do not care for signature validation
<CodeShark>
yeah, for sure
<CodeShark>
we'll eventually want to move to a model where not everyone has to validate everything :)
<CodeShark>
but something that actually works, unlike SPV
paveljanik has joined #bitcoin-wizards
stonecoldpat has joined #bitcoin-wizards
MrTratta has quit [Ping timeout: 265 seconds]
<CodeShark>
and something where you CAN validate what's important to you without having to trust the prover
<CodeShark>
so what you should do then is use H(txid || H(txidwitness))
<phantomcircuit>
CodeShark, tree of hashes of all the things in the transaction
<CodeShark>
yeah
<phantomcircuit>
download/validate only what you care about
<CodeShark>
exactly
ThomasV has joined #bitcoin-wizards
<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
sparetire_ has quit [Quit: sparetire_]
<CodeShark>
in principle, we don't need to revert an entire block just because of one bad transaction
<CodeShark>
we can still use the block for PoW
<CodeShark>
but just revert all the dependencies of that transaction
<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
<sipa>
and the system's difficulty aimed for a constant not-on-main-chain rate, rather then constant block rate
MrTratta has joined #bitcoin-wizards
<CodeShark>
what do you mean by not-on-main-chain rate?
<sipa>
it measures the recent percentage of blocks that are in such secondary parents
<CodeShark>
are we still talking a single blockchain? or multiple blockchains?
<sipa>
one dag
<sipa>
which defines a chain by following only primary parents
Mably has quit [Ping timeout: 246 seconds]
<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?
Mably has joined #bitcoin-wizards
MrTratta has quit [Ping timeout: 264 seconds]
<CodeShark>
so if the block turns out to be invalid, it is still used for PoW but the effects are voided?
<CodeShark>
or two separate blocks entirely - one only used for PoW and the other used only for effects?
<sipa>
no
<sipa>
every block has two parents
<sipa>
one from which it inherits utxo state and pow
<sipa>
another from which it only inheritd pow
<sipa>
the best-pow one with only valid first-parents wins
cdecker has quit [Ping timeout: 276 seconds]
cdecker has joined #bitcoin-wizards
<sipa>
the utxo set is defined by purely following the first parents up, and these need to be valid
<sipa>
the blocks reachable through non-first parents count for pow, but are otherwise not validated
<CodeShark>
ah, so the objective is to allow miners to create usable blocks without having to validate anything?
MrTratta has joined #bitcoin-wizards
<CodeShark>
do these PoW-only parents have parents as well?
<CodeShark>
still not sure I'm getting it p
<sipa>
they are just blocks
<sipa>
and miners still have to validate everything
<sipa>
it is just blocks that would have beenbreorged out in bitcoin
<CodeShark>
oh, so something more akin to GHOST, in a sense
<amiller>
its not a lot different than GHOST
<sipa>
now become linked into the chain again as such a second parent
hearn has quit [Read error: Connection reset by peer]
<CodeShark>
ok :)
<sipa>
lol
<CodeShark>
the pow parents are what some are calling "uncles"
hearn has joined #bitcoin-wizards
cdecker has quit [Ping timeout: 276 seconds]
<amiller>
yes
<amiller>
so the difference is
cdecker has joined #bitcoin-wizards
<amiller>
GHOST has some proposed incentive policy about how much reward the uncles get
MrTratta has quit [Ping timeout: 246 seconds]
<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
<amiller>
also, in every GHOST proposal I know of, including ethereum's, there's still a fixed minimum-time parameter
<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.
<amiller>
no more magic block time number! hooray! defeating a magic parameter is its own reward
<CodeShark>
so basically narrowing the variance
MrTratta has joined #bitcoin-wizards
<CodeShark>
and not wasting PoW in side chains
<amiller>
yes
<amiller>
i still think thats a good idea but i didn't finish it
<amiller>
also why should there be any particular fixed fraction
<CodeShark>
if you can incorporate pooled mining into it as well somehow, even more horray! :)
Mably has quit [Ping timeout: 246 seconds]
<amiller>
basically i think people should spam their partial proofs of work as far as they can
<CodeShark>
yeah
<amiller>
somehow those shares should tolerate a "lossy" network
<amiller>
like, it's okay if not everyone gets all of those
Mably has joined #bitcoin-wizards
<amiller>
the things that are currently really
<amiller>
infrequent, and worth thousands of dollars, should still propagate everywhere
Tiraspol has joined #bitcoin-wizards
<amiller>
i think this is about as well thought out as treechains :O
Tiraspol_ has quit [Ping timeout: 272 seconds]
<CodeShark>
it's a good start of something :)
cdecker has quit [Ping timeout: 276 seconds]
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
cdecker has joined #bitcoin-wizards
bedeho has quit [Ping timeout: 272 seconds]
<CodeShark>
have you gotten as far as modeling anything, amiller?
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
bedeho has joined #bitcoin-wizards
<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
<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
<CodeShark>
fblockchain - not sure I'm familiar with that one
jmcn has quit [Ping timeout: 277 seconds]
<CodeShark>
who are some of these actual people, btw? :)
<amiller>
its kind of an overidealized "proof of publication"... it's a "simulation based definition"
<amiller>
oh well: The Bitcoin Backbone Protocol: Analysis and Applications. Juan Garay and Aggelos Kiayias and Nikos Leonardos
jmcn has joined #bitcoin-wizards
<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
<CodeShark>
ah, I see
afk11 has joined #bitcoin-wizards
<amiller>
yes! :D also we will release a preprint of that in a couple days or something
Populus has joined #bitcoin-wizards
d1ggy has joined #bitcoin-wizards
d1ggy_ has quit [Ping timeout: 265 seconds]
dEBRUYNE has joined #bitcoin-wizards
<CodeShark>
sipa: no new genesis block for elements alpha?
<sipa>
eh yes there is
<sipa>
the format for blocks is even different
<CodeShark>
so then it must be somewhere other than chainparams.cpp
<sipa>
no?
pavel_ has joined #bitcoin-wizards
<CodeShark>
because in there I only see the familiar one
<CodeShark>
or the familiar two, I should say :p
<sipa>
are you looking in the ElementsProject/elements, branch alpha?
<CodeShark>
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
jgarzik has quit [Quit: This computer has gone to sleep]
MrTratta has quit [Ping timeout: 244 seconds]
<chmod755>
"principles on which Bitcoin was founded".........
MrTratta has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
spinza has quit [Excess Flood]
nwilcox has joined #bitcoin-wizards
SDCDev has quit [Ping timeout: 256 seconds]
Giszmo has joined #bitcoin-wizards
MrTratta has quit [Ping timeout: 276 seconds]
MrTratta has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
DougieBot5000_ has joined #bitcoin-wizards
DougieBot5000 has quit [Killed (wolfe.freenode.net (Nickname regained by services))]
DougieBot5000_ is now known as DougieBot5000
zooko has joined #bitcoin-wizards
austinhill has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
Giszmo has quit [Read error: Connection timed out]
Giszmo has joined #bitcoin-wizards
ThinThread has joined #bitcoin-wizards
temujin has left #bitcoin-wizards [#bitcoin-wizards]
temujin has joined #bitcoin-wizards
lnsybrd has joined #bitcoin-wizards
temujin has quit [Client Quit]
temujin has joined #bitcoin-wizards
fragzle has joined #bitcoin-wizards
c0rw1n is now known as c0rw|away
MrTratta has quit [Ping timeout: 248 seconds]
_biO__ has joined #bitcoin-wizards
airbreather has quit [Remote host closed the connection]
rubensayshi has quit [Ping timeout: 252 seconds]
zmanian has quit [Ping timeout: 256 seconds]
binaryFate has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
eudoxia has joined #bitcoin-wizards
MrTratta has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
priidu has quit [Ping timeout: 255 seconds]
cdecker has quit [Ping timeout: 276 seconds]
cdecker has joined #bitcoin-wizards
MrTratta has quit [Ping timeout: 256 seconds]
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
antanst has joined #bitcoin-wizards
MrTratta has joined #bitcoin-wizards
davi has quit [Ping timeout: 246 seconds]
cdecker has quit [Ping timeout: 272 seconds]
spinza has quit [Ping timeout: 276 seconds]
MrTratta has quit [Ping timeout: 276 seconds]
wallet421 has joined #bitcoin-wizards
wallet421 has joined #bitcoin-wizards
wallet42 is now known as Guest9149
Guest9149 has quit [Killed (sendak.freenode.net (Nickname regained by services))]
wallet421 is now known as wallet42
MrTratta has joined #bitcoin-wizards
shen_noe has joined #bitcoin-wizards
davi has joined #bitcoin-wizards
Cory has quit [Ping timeout: 264 seconds]
sy5error has joined #bitcoin-wizards
Pasha has joined #bitcoin-wizards
AndroUser2 has quit [Remote host closed the connection]
cdecker has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Pasha is now known as Cory
JackH has quit [Ping timeout: 244 seconds]
lnsybrd has quit [Quit: lnsybrd]
Mably has quit [Quit: Page closed]
blablaa has joined #bitcoin-wizards
<blablaa>
are there some altcoins working entirely using tx fees?
<sipa>
did you use 'altcoins' and 'working' in the same sentence?
<blablaa>
sipa, well yes...
<sipa>
there are a few who have done interesting development, but they are a very small minority
<sipa>
also, offtopic here
<blablaa>
sipa, it's related to bitcoin because bitcoin as it is is supposed to be funded by tx fees in the future
<sipa>
blablaa: that is a controversial position
<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.
<zooko>
blablaa: I think your question is a good one.
<zooko>
blablaa: I think the answer to it is: the evidence from altcoins so far doesn't tell us.
<sipa>
agree with zooko
gill3s has joined #bitcoin-wizards
Burrito has joined #bitcoin-wizards
Emcy_ has joined #bitcoin-wizards
Emcy_ has joined #bitcoin-wizards
<blablaa>
zooko, ok, thx for your answer, i'll wait for more answers :)
Emcy has quit [Ping timeout: 276 seconds]
<bramc>
The current transaction rate in altcoins seems unlikely to be able to keep things stable based on transaction fees alone
<sipa>
yes, you need a simulation of an economy for that
<sipa>
blablaa: also, apologies, i thought we were on #bitcoin-dev
<zooko>
sipa: Oh, I was wondering about that. So this topic *is* on topic here?
<sipa>
i would say so
<zooko>
Cool.
<sipa>
people talk about (interesting) changes to bitcoin all the time here, including those implemented in altcoins
<tromp_>
this could be called bitcoin-fantasies :)
<zooko>
lol
jmcn has quit [Ping timeout: 276 seconds]
elastoma has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 252 seconds]
damethos has quit [Quit: Bye]
tucenaber has quit [Remote host closed the connection]
lnsybrd has joined #bitcoin-wizards
erasmosp_ has quit [Quit: ttm]
erasmospunk has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<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.
mjerr has joined #bitcoin-wizards
<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.)
<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
Mably has joined #bitcoin-wizards
<adam3us>
bramc: wow that text got mangled some how!
<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
<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
wallet42 has quit [Quit: Leaving.]
<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
<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.
<bramc>
(because, apparently, there isn't enough stress in my life, so I'm proactively delving into bitcoin)
goregrind has quit [Ping timeout: 252 seconds]
<bramc>
Thanks for the props, adam3us
nwilcox_ has joined #bitcoin-wizards
<bramc>
I've gotta run now, laters everybody
bramc has quit [Quit: Leaving]
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 256 seconds]
dEBRUYNE has quit [Ping timeout: 255 seconds]
nwilcox has joined #bitcoin-wizards
nwilcox_ has quit [Ping timeout: 252 seconds]
priidu has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Client Quit]
wallet42 has joined #bitcoin-wizards
elastoma has joined #bitcoin-wizards
bliljerk101 has joined #bitcoin-wizards
n0n0_ has quit [Ping timeout: 256 seconds]
wallet42 has quit [Client Quit]
damethos has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 255 seconds]
goregrind has joined #bitcoin-wizards
goregrind has quit [Changing host]
goregrind has joined #bitcoin-wizards
gill3s has joined #bitcoin-wizards
damethos has quit [Ping timeout: 255 seconds]
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
binaryFate has quit [Ping timeout: 255 seconds]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
shen_noe has quit [Remote host closed the connection]
shen_noe has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
blablaa has quit [Quit: Sto andando via]
erasmosp_ has joined #bitcoin-wizards
erasmospunk has quit [Ping timeout: 276 seconds]
JackH has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
erasmosp_ has quit [Quit: ttm]
erasmospunk has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
lnsybrd has quit [Quit: lnsybrd]
GAit has joined #bitcoin-wizards
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jaekwon has joined #bitcoin-wizards
wallet42 has quit [Client Quit]
wallet42 has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 275 seconds]
cdecker has quit [Ping timeout: 275 seconds]
jmcn has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
<heath>
did discussion die down in the mailing list or all the messages ping requests / test messages
<heath>
or +are all the...
cdecker has joined #bitcoin-wizards
lnsybrd has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
hashtag_ has joined #bitcoin-wizards
antanst has left #bitcoin-wizards [#bitcoin-wizards]
jgarzik has quit [Quit: This computer has gone to sleep]
hashtag has quit [Ping timeout: 244 seconds]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Client Quit]
stonecoldpat has quit [Quit: Leaving.]
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
adam3us has left #bitcoin-wizards [#bitcoin-wizards]
nwilcox has quit [Quit: leaving]
jcluck has quit [Quit: Leaving]
p15x has quit [Max SendQ exceeded]
p15x has joined #bitcoin-wizards
mountaingoat has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 255 seconds]
spinza has joined #bitcoin-wizards
lnsybrd has quit [Quit: lnsybrd]
CoinMuncher has quit [Quit: Leaving.]
erasmospunk has quit [Remote host closed the connection]
erasmospunk has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Changing host]
jgarzik has joined #bitcoin-wizards
erasmospunk has quit [Ping timeout: 244 seconds]
* heath
finally sees acitivity beyond ping requests \o/
erasmospunk has joined #bitcoin-wizards
cosmo has joined #bitcoin-wizards
cdecker has quit [Ping timeout: 276 seconds]
lnsybrd has joined #bitcoin-wizards
cdecker has joined #bitcoin-wizards
shen_noe has quit [Remote host closed the connection]
getplank has joined #bitcoin-wizards
erasmospunk has quit [Remote host closed the connection]
tcrypt has joined #bitcoin-wizards
erasmospunk has joined #bitcoin-wizards
shen_noe has joined #bitcoin-wizards
Xh1pher has quit [Read error: Connection reset by peer]
erasmospunk has quit [Ping timeout: 256 seconds]
davi has quit [Ping timeout: 246 seconds]
cdecker has quit [Ping timeout: 277 seconds]
cdecker has joined #bitcoin-wizards
qawap_ is now known as qawap
cdecker has quit [Write error: Broken pipe]
cdecker has joined #bitcoin-wizards
cdecker has quit [Ping timeout: 276 seconds]
cdecker has joined #bitcoin-wizards
rht__ has quit [Quit: Connection closed for inactivity]
frankenmint has joined #bitcoin-wizards
mjerr has quit [Ping timeout: 256 seconds]
frankenmint has quit [Client Quit]
<StephenM347>
"Your membership in the mailing list Bitcoin-development has been disabled due to excessive bounces..."
<kanzure>
well, one of the emails to bitcoin-development@lists.sourceforge.net mentioned this, so perhaps view that email thread
contrapumpkin has quit [Ping timeout: 252 seconds]
copumpkin has joined #bitcoin-wizards
copumpkin has quit [Excess Flood]
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
_biO__ has quit [Remote host closed the connection]
lnsybrd has quit [Quit: lnsybrd]
nessence_ has quit []
copumpkin has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
lnsybrd has joined #bitcoin-wizards
kmels has quit [Ping timeout: 265 seconds]
zooko has quit [Remote host closed the connection]
Quanttek has quit [Ping timeout: 252 seconds]
mjerr has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
cdecker has quit [Ping timeout: 276 seconds]
cdecker has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
mjerr has quit [Ping timeout: 256 seconds]
zooko has joined #bitcoin-wizards
zmanian has joined #bitcoin-wizards
nwilcox has joined #bitcoin-wizards
justanotherusr has quit [Ping timeout: 246 seconds]
justanotherusr has joined #bitcoin-wizards
lnsybrd_ has joined #bitcoin-wizards
UllrSkis has joined #bitcoin-wizards
justanotherusr has quit [Ping timeout: 256 seconds]
justanotherusr has joined #bitcoin-wizards
lnsybrd has quit [Ping timeout: 256 seconds]
lnsybrd_ is now known as lnsybrd
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
mjerr has joined #bitcoin-wizards
JackH has quit [Ping timeout: 264 seconds]
lnsybrd has quit [Quit: lnsybrd]
mjerr has quit [Ping timeout: 255 seconds]
Populus has quit [Remote host closed the connection]
b_lumenkraft has quit [Quit: b_lumenkraft]
tucenaber has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
wallet42 has joined #bitcoin-wizards
Tebbo has quit [Read error: Connection reset by peer]
rht__ has joined #bitcoin-wizards
Tebbo has joined #bitcoin-wizards
tcrypt has quit [Read error: Connection reset by peer]
Luke-Jr has quit [Excess Flood]
tcrypt has joined #bitcoin-wizards
Luke-Jr has joined #bitcoin-wizards
AnoAnon has joined #bitcoin-wizards
AnoAnon has quit [Max SendQ exceeded]
wallet421 has joined #bitcoin-wizards
wallet421 has joined #bitcoin-wizards
wallet42 has quit [Killed (sinisalo.freenode.net (Nickname regained by services))]
wallet421 is now known as wallet42
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
getplank has quit [Read error: Connection reset by peer]
Cory has quit [Read error: Connection reset by peer]
forrestv has quit [Ping timeout: 252 seconds]
UllrSkis has quit []
JackH has joined #bitcoin-wizards
gnusha has quit [Ping timeout: 256 seconds]
espes has quit [Ping timeout: 252 seconds]
Cory has joined #bitcoin-wizards
gnusha has joined #bitcoin-wizards
espes has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
UllrSkis has joined #bitcoin-wizards
forrestv has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
temujin has left #bitcoin-wizards [#bitcoin-wizards]
ruby32 has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 272 seconds]
nwilcox has quit [Quit: leaving]
StephenM347 has quit []
cdecker has quit [Ping timeout: 276 seconds]
droark has quit [Quit: Later.]
cdecker has joined #bitcoin-wizards
pavel_ has joined #bitcoin-wizards
droark has joined #bitcoin-wizards
paveljanik has quit [Ping timeout: 276 seconds]
sdaftuar has quit [Ping timeout: 272 seconds]
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
airbreather has joined #bitcoin-wizards
zooko has quit [Quit: BATTLE FOR WESNOTH!!!]
jmcn_ has joined #bitcoin-wizards
wallet42 has quit [Client Quit]
nwilcox has joined #bitcoin-wizards
blazes816 has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 275 seconds]
DougieBot5000 has quit [Quit: Leaving]
airbreather_ has joined #bitcoin-wizards
tcrypt has quit [Ping timeout: 246 seconds]
blazes816 has quit [Ping timeout: 276 seconds]
airbreather has quit [Ping timeout: 276 seconds]
PRab_ has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.5/20150525141253]]
darwin__ has quit []
ruby32 has quit [Quit: ruby32]
belcher has joined #bitcoin-wizards
Mably has quit [Ping timeout: 264 seconds]
jmcn_ has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
hearn has quit [Ping timeout: 252 seconds]
hearn has joined #bitcoin-wizards
hearn has quit [Client Quit]
JackH has quit [Ping timeout: 252 seconds]
jgarzik has quit [Quit: This computer has gone to sleep]
PaulCapestany has joined #bitcoin-wizards
rustyn has quit [Ping timeout: 250 seconds]
rustyn has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 272 seconds]
DougieBot5000 has joined #bitcoin-wizards
Tebbo has quit [Read error: Connection reset by peer]
Tebbo has joined #bitcoin-wizards
lnovy has quit [Ping timeout: 252 seconds]
lnovy has joined #bitcoin-wizards
sipa has left #bitcoin-wizards [#bitcoin-wizards]
zmanian has quit [Ping timeout: 252 seconds]
jgarzik has joined #bitcoin-wizards
zmanian has joined #bitcoin-wizards
gmaxwell has joined #bitcoin-wizards
PRab has joined #bitcoin-wizards
melvster1 has quit [Ping timeout: 252 seconds]
<CodeShark>
is it possible to create an efficient accumulator that can be used to validate an entire transaction graph?
<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:
dEBRUYNE has quit [Read error: Connection reset by peer]
<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?
<gmaxwell>
That latter issue makes it less exciting.
<nwilcox>
CodeShark: I'm curious if an "accumulator" is also possible...
<nwilcox>
gmaxwell: Are these additional comments merkle paths to block header for each txin?
<nwilcox>
s/comments/commitments/
c0rw|away is now known as c0rw1n
<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
<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
<gmaxwell>
stopped updating it when 99% of the effect it was having was feeding plagerism)
<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). :)
<CodeShark>
right, well I only encountered it recently...so I'm a little behind :p
<CodeShark>
if the cost of proofs are moved over to the sender, it could be conceivably made to scale
<CodeShark>
the sender would only have to incorporate one more witness into the proof they got from each of their inputs
<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. :(
<CodeShark>
why would only the block author have the updated accumulator state?