<gmaxwell>
akrmn: you don't? I'm sorry, I think you've underdefined what you're talking about there. I mean that isn't an issue with UTXO commitments; it's potentially an issue with some unspecified scheme to use them.
<akrmn>
gmaxwell: Then what is an example of a good scheme?
<gmaxwell>
Hm? good for what?
<gmaxwell>
If someone told you that utxo commitments magically make bitcoin scalable they fed you a line of bull. :)
<akrmn>
My use case examples: I want to track the public Bitcoin addresses that my government representative can use for spending.
<akrmn>
or I simply want to track the addresses in my wallet to make sure they weren't stolen.
<gmaxwell>
But no other seperated scheme does substantiavly better they can all all censor within some subdomain. It's perhaps possible to make censorship harder with PIR-ish techniques but those increase costs for servers.
<gmaxwell>
akrmn: in that first example you'd ask the respresentative to prove their spending to you, so I think it's not a great case.
<akrmn>
Well Peter Todd replied to my scaling Bitcoin with Subchains thread and said that UTXO commitments and fraud proofs are already well established, and tree chain structures are only useful for miner decentralization
<akrmn>
gmaxwell: No they can spend without you knowing
<akrmn>
If you don't download the full blocks
<gmaxwell>
akrmn: You can require them to prove to prove the absense of updates to them (assuming address indexed trees).
<akrmn>
So they have to keep moving their coins around to prove to you?
<gmaxwell>
akrmn: what? no!
<akrmn>
I don't understand
<gmaxwell>
akrmn: any commited search tree can show the the absense of an entry as efficiently as it can show the entry.
<akrmn>
gmaxwell: So you are still relying on being able to access the merkle tree of UTXOs
<akrmn>
?
<akrmn>
And if some parts of it are denied to you by the nodes that have those parts?
<gmaxwell>
akrmn: no, I am relying on the representative to be able to access the tree fragments for his own scriptpubkey.
<akrmn>
gmaxwell: ok I see
<akrmn>
still doesn't seem robust
<gmaxwell>
the constituitent never consults the network at all, except to check the identity of the chain.
c0rw1n is now known as c0rw|zZz
<akrmn>
They can say, well we are having technical difficulties and no nodes are feeding it to us
<gmaxwell>
It's prefectly robust for that application. The representative can either show you all the transactions, provable respond incompletely, or fail to respond at all.
<akrmn>
I guess they can just move their coins around if they really have problems to prove it
<gmaxwell>
akrmn: they can claim that perhaps of course, but if they can't find out about the payments to them themselves, then they couldn't spend them either; so someone showing they spent them would prove they were lying about those technical difficulties.
<akrmn>
but then you are trusting the miners maybe a bit too much
<gmaxwell>
There is no moving anything required there.
<gmaxwell>
If they know about the transactions paying them, the process of learning about them was the same membership proofs they need to give to you.
<gmaxwell>
So either everyone is being censored for those addresses (which is possible), and the coins can't even be spent, or at least the representative knows and can comply with your request for information.
<gmaxwell>
In any case, _all_ subset systems have a censorship problem; and the only hope to address that appears to be is to use techniques from PIR but that requires the source have more information to enable an anonymity set for the query; which undermines some of the scaling gain.
<akrmn>
hmm thinking...
<akrmn>
what is PIR?
<gmaxwell>
Might be helpful to also consider that someone fetching a tree fragment could just as well fetch little subsets that he could also serve on, e.g. you're not dependant on someone with all the data to construct membership proofs.
<gmaxwell>
Private information retrieval; where you can fetch data from a server without the server knowing what data you fetched.
<gmaxwell>
E.g. you can fetch record 0 and the server doesn't know if you fetched 0,1,2,3,4... but obviously you can't have fetched any record that the server's behavior didn't depend on.
<akrmn>
gmaxwell: You want to rely on someone showing that they spent the public's coins?
<gmaxwell>
akrmn: ::sigh:: the reliance is on the fact that they cannot hide that they spent a coin without simply failing to respond entirely. (and then people can demand they respond, since the failure is conspicious)
<akrmn>
I still don't understand. I think with my method it is better, because you can download all the full blocks of the subchain corresponding to a wallet, so you can catch EVERY transcation with those addresses.
<gmaxwell>
this is why the politician example is silly, there is obvious recourse if the politician is refusing to comply.
<akrmn>
gmaxwell: Well if there's big blocks and only a few big nodes and only a few miners, then it is plausible that yes they can hide a transaction.
<akrmn>
because no one else will be looking at the full blocks
<gmaxwell>
akrmn: In this respect the systems fail identically. You could download the all the transactions corresponding to a particular utxo subtree. It's just the same as blocks. In either case you could be potentially censored though the censorship wouldn't be secret.
<akrmn>
For a subchain, the miners of a subchain have an incentive to broadcast their blocks, but nodes do not have an incentive to give out the UTXO merkle trees
<gmaxwell>
akrmn: No, they cannot. They can only hide a transaction by hiding the records connected to a particular scriptpubkey _completely_, in which case the representative couldn't spend either. So he would be taking a grave risk in saying "sorry, I can't access those records either" since his spending would _prove_ that he had.
<gmaxwell>
akrmn: what? no. They only have an incentive for a substantial amount of hashpower to build on them. (30% or 50% depending on what information advantage you assume); they have no particular incentive to give them to anyone else. And likewise UTXO commitments do not in any way diminish the requirement of giving your block data to other miners.
<akrmn>
Well ya they need to broadcast to get other miners on their chain, and with more miner decentralization, it is better
<akrmn>
I think the censorship issue is underestimated in the blocksize debate
<akrmn>
and UTXO commitments wont save us
<gmaxwell>
I dunno who said they would, none of the people who are conserviative about blocksize think they would.
<akrmn>
alright just saying to make sure others are aware, and also for myself to know if I understand
<sipa_>
UTXO commitments help for bootstrapping full nodes _in a reduced security mode_, and help SPV nodes prove the non-spentness of coins
<gmaxwell>
Miners are harmed, technically, by giving the data promptly to more than half the hashrate. But again: this is the same across the board-- the censorship is completely orthorgonal to utxo commitments vs subchains. In both cases a miner only needs to provide the data to a subset of other miners.
<sipa_>
they are not a scaling mechanism
<gmaxwell>
what sipa says. (as usual)
<akrmn>
Ah sipa finally :)
<sipa_>
in fact, they hurt scalability, by burdening full nodes with updating the utxo merkle root for every block
<gmaxwell>
They're potentially pretty useful; maybe. Unclear, they appear to be much more expensive to maintain than people were originally estimating, so their narrow uses may not offset their costs.
<akrmn>
sipa_ said my subchains scheme is equivalent to an SPV node downloading just the transactions it thinks are important, but it's not if you understand how UTXO states can be proved
<sipa_>
UTXO commitments are also just SPV security
priidu has quit [Read error: Connection reset by peer]
<sipa_>
they are not useful if you want full node security
jtimon has quit [Ping timeout: 256 seconds]
<sipa_>
because all UTXO commitments do, is prove that miner hashpower agreed with the commitment
<akrmn>
Well it is similar to UTXO commitments, but not quite. Each parent chain stores the hashes of the block headers of the child chains in special transactions
<sipa_>
how do you validate them?
<akrmn>
so no merkle tree is needed to prove UTXO state
<akrmn>
you download the full blocks for the subchains you want to track
<sipa_>
if you don't verify them, you don't get fill node security for them
<sipa_>
then you cannot get full node security for the parents without validating the children
<akrmn>
The parent always decides in case of conflict
<akrmn>
so yes, parent can commit to some bad things deep down in the tree of chains, but the deeper you go the less important it is
<akrmn>
it is a good tradeoff I think
<gmaxwell>
akrmn: I don't know why you think in this respect there is any difference at all. You can download the subtries pubkeys 0000... through 0001... under a utxo commitment scheme and then a party can only censor or not the whole thing. just like they could censor or not a subchain. You argue that miners are incentivized to share but this is exactly as true (not very) in both cases.
<sipa_>
so can parent miners steal coins from the subschain#m
frankenmint has joined #bitcoin-wizards
<akrmn>
sipa_: Parent miners have an incentive to keep the child chain working well since they get fees for including the child chain hashes in their blocks
<gmaxwell>
to the extent that they're different in the subchains case since not all miners are mining all subchains and enforcing validity as a group there are arguably more censorship incentives (e.g. so miners can steal the coins).
<akrmn>
and the fees can only be spent in the children chains (outputs valid only in children chains)
<gmaxwell>
akrmn: why bother with fees under conditions when you could instead just steal the coins?
<akrmn>
gmaxwell: Good question. Have to think about it.
<gmaxwell>
similarly in the utxo commitment stuff the miners have to process updates for the whole utxo or they can't mine at all. I could see where you might argue that this was less scalable, but not less secure. (and indeed, utxo commitments do not generally improve scalability; though they do make some particular cases more efficient)
<akrmn>
Well then the value of those coins will go down
<gmaxwell>
(some particular reduced security use cases)
<akrmn>
just like miners dont have an incentive to steal coins now
<sipa_>
akrmn: then we could just use a central bank too
<sipa_>
much more efficient
<sipa_>
akrmn: miners niw _cannot_ steal coins, because full nodes would reject their blocks
<gmaxwell>
akrmn: they coins they steal are not confined to that system (otherwise you're just describing an altcoin)
<gmaxwell>
sipa_: well subject to not reorging deeper than 100 blocks, but thats a bit hair splitting.
<sipa_>
agree
<akrmn>
Well its in the satoshi paper as I remember that miners wouldn't want to compromise the value of their coins by making the system look bad
<sipa_>
akrmn: blockchains don't solve security of coins
<sipa_>
akrmn: the only authority given to miners in bitcoin is deciding between two equally valid potential versions of historu
<sipa_>
but _valid_ versions of history
<sipa_>
and yes, they can cheat here too, by reverting completed transactions
jmcn has quit [Ping timeout: 276 seconds]
<sipa_>
so there is an incentive necessary for them not to do so
<sipa_>
and that is subsidy and fee
jmcn has joined #bitcoin-wizards
<sipa_>
but it works because it is the only means through which they can earn money
<sipa_>
if they could just steal coins, you are not doing much better than a central bank
<akrmn>
ok true full nodes will reject that, so that's also a reason. I guess full nodes on the child chains could go with the parent chain only if it follows basic rules
<sipa_>
the difference that bitcoin offers is the ability for everyone to verify that nobody is cheating, and just outright reject attempts in which it is tried
<sipa_>
the problem in your case is that to get full node security on the parent chain, you need to already validate all childchains
<sipa_>
afaict
moa has joined #bitcoin-wizards
<akrmn>
well the parent will validate the children, the child will validate the grandchildren, so recursively the system holds together
<akrmn>
and deeper validations can be done by the parent, but it's not so required, and becomes less important the deeper you go
<sipa_>
the children also have to validate the parent for transfers from them
<sipa_>
or from other children
<akrmn>
so you can fine tune the level of security depending on how deep of a chain you use
<sipa_>
no, you just need to validate the whole thing
<akrmn>
ya children track the parents
<gmaxwell>
uhhh. you cannot have X validation depend on Y and then validate X without validating Y. You're being fuzzy there, and I think dishonest about the security levels you're talking about as a result (I don't mean that to imply that its intentional)
gmaxwell has left #bitcoin-wizards [#bitcoin-wizards]
<akrmn>
gmaxwell: Im not saying my scheme is perfect. But I think it is at least better than increasing the blocksize.
<sipa_>
the fundamental problem is that to have coins transferring between coins, the receiver needs to validate that the coin existed in the first place where it was sent from. that means fully validating the sender
<sipa_>
akrmn: at best, it is identical in full node validation cost
<akrmn>
sipa_: Yes but the rule says to trust the parent to commit to the children headers, and (possibly) you need to do an SPV validation using the headers of the sibling chain.
<sipa_>
i think that's an unacceptable compromise
Dr-G has quit [Disconnected by services]
Dr-G2 has joined #bitcoin-wizards
<sipa_>
the security of the whole system can never be better than the bottom blockchains
<sipa_>
you are talking about introducing multiple tradeoffs, which is good
<sipa_>
but you do it at the cost of significantly reducing the best security possible
<sipa_>
when talking about centralization pressure from scaling, it is usually the cost to that best possible security we're talking about
<akrmn>
You just need a proof that the sender from a sibling (not parent or child) has the coins right?
<sipa_>
and to get full node security, that proof is the entire blockchain
<sipa_>
for spv security, it is the headers of that chain
<sipa_>
and if there were coins transferred into it during its history, you need the blockchains of those sender chains too
<sipa_>
you cannot validate a transaction's effect without seeing the transaction
<sipa_>
spv security is relying on the fact that miners vouched for it, but it is not full validation
<akrmn>
The sender had to start from the common parent chain, then transfer to the sibling chain (child of the parent next to the child chain you track). So you just need a proof of all their transactions from when they entered the sibling chain until the present moment.
<sipa_>
not going to argur anymore
<sipa_>
argue
fanquake has joined #bitcoin-wizards
<sipa_>
i think you should try to understand why bitcoin is secure first
<akrmn>
ok no problem
<akrmn>
but even if you like the current way of doing things, you can still do it by tracking all the subchains. It will be equivalent to increasing the blocksize. So I don't see how it can be worse.
<sipa_>
more complex with no benefit
<akrmn>
well for some applications theres a benefit I think
<sipa_>
ok
frankenmint has quit [Remote host closed the connection]
fanquake has quit [Ping timeout: 252 seconds]
fanquake has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
Guest22312 is now known as pigeons
<CodeShark>
sipa, I really like the witness separation thing you're working on :)
<bramc>
utxo commitments become more useful if the block sizes are larger.
<CodeShark>
block size should ultimately be dictated by technological capacity and economics...and must ultimately be dynamic
<bramc>
block size is just fine where it is
<CodeShark>
for an experimental network, sure - for a global payment network capable of handling billions of users, it most certainly is not (unless the blockchain consists merely of hash commitments)
<CodeShark>
the far more important issues of how to schedule hard forks and how to create a fee market got conflated into this whole block size debate
<CodeShark>
I'm glad to see that at least a few people in this space have the vision to give these things their due
rusty has joined #bitcoin-wizards
<bramc>
Here's a good schedule for hard forks: never
<bramc>
Unless there's a critical reason
hashtag has quit [Ping timeout: 246 seconds]
<moa>
it's hard to imagine what a good hard forking would even look like
<CodeShark>
there will be critical reasons sooner or later - we need to at least have a mechanism in place
<CodeShark>
so that it isn't an ad-hoc thing each time
<CodeShark>
and so that people don't use these situations as political opportunity for self promotion
<moa>
opportunists-resistant protocol
<CodeShark>
:)
<CodeShark>
well, I should rephrase that - self-promotion in and of itself isn't what's bad - it's driving wedges in cryptoledgers for political gain that's bad
goregrind has joined #bitcoin-wizards
goregrin1 has quit [Ping timeout: 246 seconds]
[7] has quit [Ping timeout: 265 seconds]
<CodeShark>
but in principle I agree that they should be rather infrequent, bramc
<CodeShark>
some of the most critical things that should be done in a hard fork is precisely to figure out ways to avoid them in the future
<CodeShark>
but no matter how much foresight we think we have we'll surely miss something...and sooner or later we'll either encounter some crisis...or someone will find a brilliant solution to some issue we'd like to incorporate but can only incorporate it via hard fork
<Luke-Jr>
CodeShark: hey, thanks for saying things that need to be said on the ML ☺
<CodeShark>
:)
TheSeven has joined #bitcoin-wizards
<bramc>
The method of doing a hard fork of coming up with an unpopular and dubious proposal and whipping up hysteria on reddit is not a good one
<CodeShark>
I think most of us agree with that, bramc :)
<moa>
r/bitcoin could do with a hard forking
hashtag has joined #bitcoin-wizards
erasmospunk has joined #bitcoin-wizards
the_last has quit [Quit: Leaving.]
afk11 has quit [Ping timeout: 252 seconds]
<phantomcircuit>
CodeShark, there's no way for a hard fork to be orderly unless there is nearly universal consensus
<CodeShark>
phantomcircuit: agreed - which makes it a huge challenge
the_last has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 246 seconds]
erasmospunk has quit [Ping timeout: 246 seconds]
go1111111 has quit [Ping timeout: 250 seconds]
<CodeShark>
more the reason to focus the core protocol on only the critical consensus tasks and move specific details off to
<CodeShark>
other networks
<CodeShark>
ultimately the blockchain is a decentralized timestamping mechanism for converging on a commit history
<phantomcircuit>
CodeShark, bitcoin core's been massively re-factored to get closer to that
<CodeShark>
yes, I'm happy to see those efforts underway
<phantomcircuit>
but ultimately things like the blocksize limit are the critical consensus tasks
<phantomcircuit>
actually i think that's the fundamental disagreement
<CodeShark>
what's the fundamental disagreement?
afk11 has joined #bitcoin-wizards
<phantomcircuit>
CodeShark, those seeking to change the blocksize dont see the fee pressure as part of the consensus critical code
<phantomcircuit>
fees has always been kind of a big question mark in the incentives model
<phantomcircuit>
but there's nothing to replace them!
<CodeShark>
the fee issue is an unsolved one - but the original bitcoin design makes it very clear that ultimately the network is to be subsidized by fees, not block rewards
<CodeShark>
six years into this thing, it's still unsolved
<CodeShark>
shall we wait until block subsidies are in the millibitcoins?
<phantomcircuit>
CodeShark, exactly my point
<phantomcircuit>
"oh well fix that later"
<phantomcircuit>
s/later/never/
<rusty>
CodeShark: I always thought a good model for thinking about hard forking would be an SHA break or equiv.
<phantomcircuit>
without substantial transaction fees (in the range of $1.50/tx) the incentives model for mining doesn't make any sense at all
Populus has joined #bitcoin-wizards
Populus has joined #bitcoin-wizards
<phantomcircuit>
if the incentives model doesn't work... then the pow security is useless
go1111111 has joined #bitcoin-wizards
<CodeShark>
phantomcircuit: if the transaction volume were large enough mining could still be potentially profitable even at much lower fees. But for that to happen we need fundamental architectural and algorithmic improvements to scalability
<CodeShark>
increasing the block size alone will never fix that
<CodeShark>
rusty: so you mean we set a crypto challenge?
<phantomcircuit>
CodeShark, transaction fees will be effectively zero until blocks are full
chmod755 has joined #bitcoin-wizards
<phantomcircuit>
CodeShark, it's an obvious game theory failure
<phantomcircuit>
CodeShark, when selecting the transactions to include in a block right now miners will always include everything that pays a fee upto the size limit
<rusty>
CodeShark: Not quite. I mean if you want to provide a scenario where a hardfork would have almost universal consensus, for the purposes of designing a hardfork protocol (I mean protocol in the human sense).
<phantomcircuit>
if the limit isn't being hit then the fees will tend towards zero
<rusty>
phantomcircuit: gmaxwell's flexcap proposal or something is required, agreed.
<phantomcircuit>
CodeShark, to correct this there needs to be some form of supply fixing
<rusty>
brb
rusty has left #bitcoin-wizards [#bitcoin-wizards]
<CodeShark>
phantomcircuit: correct - we need to hit the limit and we need to design for fee bidding. and we need to apply pressure on all the parts of the ecosystem to start migrating to this.
rusty has joined #bitcoin-wizards
<CodeShark>
we still have block reward subsidies...so we don't need fees to cover the entire cost for pow
<CodeShark>
at least for now
<CodeShark>
so NOW is when we should do this
<CodeShark>
when we still have an economic cushion
frankenmint has joined #bitcoin-wizards
<CodeShark>
then we can focus on scalability and increasing volume
<phantomcircuit>
CodeShark, then we agree
<phantomcircuit>
k
<phantomcircuit>
awkwardish silence
<CodeShark>
heh
<moa>
block rewards can go to anyone who solves the transition to fees only POW security
<CodeShark>
but you do bring up a very important point which I'm starting to put more into perspective - I was thinking perhaps a block size increase is good because it buys us a little more time - but it's clear that the cushion should be in the block reward, not in the block sizd
<CodeShark>
*block size
<CodeShark>
otherwise it only works to the detriment of these developments - as you say, a game theory fail
<phantomcircuit>
CodeShark, and you can probably see why it's so hard to explain this to people
<CodeShark>
the economic pressure is essential to the solution here
<phantomcircuit>
"well you see this is almost a classic prisoners dilemma problem" *eyes glaze over*
<moa>
what about "if tot_fees_last_2016 > X*total_rewards_last_2016 then new_max_block_size = Y*max_block_size" ?
<moa>
X and Y to be bike-shedded
<CodeShark>
lol
<phantomcircuit>
moa, using the fees directly as a proxy doesn't work; unfortunately miners get paid the fees so they can trivially jump up the apparent fees paid
<CodeShark>
well, the problem with that is that it's hard to prevent people from generating fake volume and fees
<CodeShark>
right, phantomcircuit :)
<phantomcircuit>
(note: they should be the ones getting the fees)
frankenmint has quit []
<bramc>
Having wallets set their fees is an interesting problem
<bramc>
(and one which won't be solved until it has to be, one of the reasons real fees are a good thing)
<bramc>
One approach is to have wallets always start at a small fee and increase it over time until it goes through
<moa>
phantomcircuit: which would be the same as miners voting for larger blocks
<CodeShark>
bramc: it would be nice to have fee queries built into the protocol somehow
<CodeShark>
and fee commitments in blocks
<bramc>
CodeShark, Yes it's an interesting question where those should go, and how they could be proven
<bramc>
One interesting extension would be to make minimum fee per byte be part of the root metadata of blocks
<CodeShark>
miners could advertise their fee policy in their blocks - and relayers could advertise their fee policy as either part of their handshake or as a separate message
<CodeShark>
although the latter part is still fundamentally broken because the fees here are only for spam prevention
<bramc>
fee policies should be assumed to be a bidding process where they take the maximum fee/byte and go down the line until the block is full
<CodeShark>
true
<CodeShark>
so I guess you'd need some kind of orderbook
<bramc>
It's more complicated than that because of transaction dependencies of course
<CodeShark>
miners could periodically propagate messages with their orderbook info, I suppose
<CodeShark>
hmmm
<phantomcircuit>
bramc, i actually dont think it's that difficult of a problem if we make one tiny assumption
<phantomcircuit>
if we assume that miners are maximizing for fees
<phantomcircuit>
it becomes nothing but a matter of estimating the fees needed to get you in the next block based on the mempool
* jgarzik
appears
<jgarzik>
phantomcircuit, very bad assumption though
<CodeShark>
but there's another problem even assuming that...which is that wallets then need to track the entire mempool as well
<jgarzik>
the problem is ultimately predicting the collective scope of multiple local miner policies
<bramc>
Yes there's an issue with calculating the going rate
<bramc>
It's unfortunate that bitcoin protocol doesn't require that fees be identical per byte across all transactions
<CodeShark>
it would be nice, perhaps, to be able to set a fee range and have a mechanism that proves that the fee you had to pay was the best available to get into the block...and maybe a way to set confirmation priority
<CodeShark>
"I'm willing to wait longer but want to pay less"
<bramc>
The escalator approach: start at a small value, go up exponentially until you get in, has the advantage of always working and requiring no trust. It does take a while though
<bramc>
It also highlights that there will always be a tradeoff where wallets willing to wait a bit longer can get a cheaper rate
<bramc>
There's likely to be daily and weekly cycles of fees.
<leakypat>
I've often wondered when the fee market is there, won't miners be able to troll $1bn transactions for example?
<phantomcircuit>
CodeShark, what you dont run bitcoin core wallet? :P
<CodeShark>
lol
<phantomcircuit>
jgarzik, yes i've discussed this a bunch around limiting the memory pool
ryan`c is now known as ryan-c
<phantomcircuit>
both limiting the memory pool and estimating fees require coming up with some function that approximates miner policy
<bramc>
I would argue that wallets should always be doing some amount of escalator, as a public good, otherwise weird effects can happen
<phantomcircuit>
with RBF this actually becomes much easier
<CodeShark>
about the best we can do for estimating fee policy is looking at recent block history, I think
<phantomcircuit>
since the easiest way to guess at miners policy is to look at the age of transactions in the mempool
<phantomcircuit>
which you cant really do a priori
<bramc>
like prices can get high and get stuck high for no reason other than that they were that way before. If wallets always try to underbid and then work up to what they're willing to pay things will be much more stable overall, regardless of what algorithm is used to set their initial bid.
Populus has quit [Ping timeout: 246 seconds]
<phantomcircuit>
jgarzik, so... yeah approximating all miners as using nothing but feerate is reasonable so long as there's a fallback
<CodeShark>
bramc, I think the escalator approach is best...if only there were a way for wallets to quickly receive a message from miners saying how likely they are to include it
<phantomcircuit>
without rbf you're taking an educated guess and cant change it though
<phantomcircuit>
in other words rbf is necessary for bitcoin to work long term
<jgarzik>
phantomcircuit, as stated days ago, you need a multi-level approximation... first fee tranche then priority tranche
<bramc>
CodeShark, Bidding is part of the price discovery process, I think *any* algorithm where wallets pick a price and don't adjust it will inevitably cause wacky artifacts
<rusty>
jgarzik: safe rbf makes the fee guessing much more interactive. That may be a bad thing, of course...
<bramc>
jgarzik, Escalator has two, maybe three big parameters: starting value, max value, and rate of increase
<bramc>
What is 'safe rbf'?
<phantomcircuit>
jgarzik, what?
<phantomcircuit>
no you dont
<phantomcircuit>
either way you're making a best guess approximation
<the_last>
i for one am glad our overlord Gavin decided to make a move
<phantomcircuit>
including priority in the equation is assuming all the miners run the default policy
<phantomcircuit>
which is irrational...
<jgarzik>
phantomcircuit, 2 tranches, because that is what miners follow
<jgarzik>
phantomcircuit, the free transaction area must be included in your guesstimate
<rusty>
bramc: basically, allowing a transaction to be replaced in the mempool if it's a superset.
<phantomcircuit>
jgarzik, that seems like a short term attempt to model based on a monoculture of policy
<phantomcircuit>
that really just feels extremely lame
<jgarzik>
phantomcircuit, Translation: You wish to model something other than reality.
<phantomcircuit>
read: im not writing that
<phantomcircuit>
jgarzik, if you'd like i can write a pure fee policy and lobby miners to run it
<phantomcircuit>
apparently the game of the day is changing reality
<jgarzik>
phantomcircuit, your problem set is modelling what miners do, not what you want them to do!
<jgarzik>
If you are unhappy with reality I can't help with that part ;p
<CodeShark>
miners don't optimize for fees because it's a diminishing returns proposition right now
<CodeShark>
a lot of work for very little gain
<CodeShark>
they basically run whatever software they get
<rusty>
phantomcircuit: you could argue that it'll happen eventually. When fees are no longer << subsidy, that free stuff will go away pretty fast.
<phantomcircuit>
jgarzik, im modeling what i expect miners will be doing when it actually matters
<CodeShark>
but if we had an actual fee market there'd be an incentive for people to write more economically rational mining software
<jgarzik>
...then it doesn't get merged for years
<phantomcircuit>
if you think anybody is going to have a free transactions area when there's actual fee pressure
<phantomcircuit>
well
<phantomcircuit>
that's just hilarious
<jgarzik>
because it doesn't match real life for years
<jgarzik>
thus, pointless
stonecoldpat has joined #bitcoin-wizards
<CodeShark>
I think we can assume that given a real fee market, miners would tend to move towards a more rational bidding approach
<CodeShark>
and would abandon the current tx selection algorithms
<jgarzik>
CodeShark, nod - but the foundational assumption remains false today, and possibly for some time yet to come
wallet42 has joined #bitcoin-wizards
<jgarzik>
The __current__ bitcoin economic policy is to prevent fee pressure from developing. This talk of "building a fee market" has to happen in the future, but it is de facto an economic policy _change_, a delta from the years-long policy of avoiding fee pressure to subsidize bitcoin adoption.
<CodeShark>
it was a stupid policy - it's too bad I wasn't in those meetings :p
<jgarzik>
Each block limit size change reboots the fee market.
<jgarzik>
from scratch
wallet42 has quit [Client Quit]
<CodeShark>
the time to solve the problem is BEFORE bitcoin is huge...while it's still relatively experimental and the costs of failure are still relatively small
<CodeShark>
not once it's gone global and we have no solution
<rusty>
jgarzik: I'm pretty sure everyone knew free money wouldn't last forever. If not, they're learning now.
<CodeShark>
bitcoin is already subsidized by block rewards - and even with the current block size limit it took us over 6 years to start to get close to it
<moa>
ok "if total_fee_last_210000 > X*total_reward_last_210000 then new_max_block_size = Y*max_block_size" for the transitional period from rewards to fees
<jgarzik>
rusty, It is highly likely that the block size limit will be increased, and the current policy continued
<CodeShark>
then we need a change of leadership
<CodeShark>
I'm sick of cowtowing to mediocrity
<CodeShark>
we need to set higher standards for our industry
<rusty>
jgarzik: it is highly unlikely that it will happen before low-fee transactions are delayed enough. We're one big burst away from that happening.
<CodeShark>
this isn't a piggy bank
<jgarzik>
rusty, nod, we've already had community-run stress tests along those lines
<rusty>
jgarzik: they're bullshit. We've had mempool fills before and since, no indication those "stress tests" did anything.
<jgarzik>
rusty, Are they comprehensive? No. Are they more than the community & industry have done in the past? Yes. Is that sad? Yes.
<jgarzik>
they are useful wake-up calls
<rusty>
jgarzik: True. AFAICT they haven't changed user behaviour. That 45% of transactions moving < $1 is the number to watch.
<CodeShark>
I should also add that if it was policy to avoid fee pressure, this should have been made more explicit as part of the specifications...rather than pulling fud on forums and scaring everyone into suddently increasing block size
<jgarzik>
the last time blocks got full, the action was Mike Hearn lobbying miners to increase their soft limit ;p
<rusty>
jgarzik: indeed; some people were promised "no fees!" for bitcoin transfers.
<jgarzik>
which they did
<rusty>
jgarzik: indeed, I'd rather see them drop priority txs.
<bramc>
The current main anti-DOS fee measure is to ignore fees and put through bigger transactions first. This makes things work okay when such stress tests happen, but is rather counter to what needs to happen eventually
<bramc>
It also isn't a great anti-dos measure. I ran the numbers a while ago on how much money you'd have to allocate to make it so that $10 transactions could never go through, I think it was like $25,000
arubi has quit [Quit: Leaving]
<bramc>
Blocking less than $100 would require $250,000
<bramc>
And of course the attacker wouldn't lose that deposit, although they might have done some damage to its value in the process of the attack
<moa>
is there any evidence that zero free transactions take any longer than fee-paying TX?
<jgarzik>
bramc, not sure I understand that? The current main anti-DOS measure is that fee pressure begins, once blocks fill up.
<moa>
zero fee
<jgarzik>
Blocks are not full by default, because of anti-dust (anti-spam) policy.
<jgarzik>
Natural economic state of a block is 100% full at all times
<jgarzik>
absent de-spamming
<CodeShark>
blocks not being full because of anti-dust policy is another game theory fail
<CodeShark>
the incentives are all completely screwed up on that one
<bramc>
jgarzik, That isn't my understanding, I could be wrong, I don't have a link handy, I definitely read something which gave a concrete algorithm which involved transaction size and age as the biggest inputs, I think priority was something like size*age
<jgarzik>
bramc, that is the _secondary_ sort
<jgarzik>
bramc, the primary sort is fee/kb
<jgarzik>
bramc, if room is left after primary sort, _then_ size/age sort kicks in
<jgarzik>
bramc, size/age priority is referred to as the "free transaction area"
<jgarzik>
size/age is only used when the fee is otherwise too low for inclusion
<bramc>
jgarzik, You mean for things which are tied, generally with a fee of zero?
<jgarzik>
bramc, not tied -- for all transactions which failed to be picked up by the initial fee/kb sort - and fell below the "dust" (fee) limit just mentioned
<jgarzik>
if your fee is below a certain X, it is considered "zero fee" from the miner's sorting perspective
<bramc>
What is the dust limit set to?
<bramc>
At current standard fees everything might as well be dust
<jgarzik>
bramc, grep for IsDust()
<jgarzik>
bramc, it's not a simple number, but a calculation
<CodeShark>
are we talking about relay selection? or miner selection?
<jgarzik>
CodeShark, miner selection
<jgarzik>
relay has a similar metric though
<bramc>
The fees are miniscule relative to the overhead of transferring between real currencies and bitcoin, which is ridiculous
stonecoldpat has quit [Quit: Leaving.]
<jgarzik>
...this is why I've been poking phantomcircuit about a two-tranche approach. That best simulates miners today. (1) fee/kb (3) priority (size/age)
<rusty>
(2) collect underpants?
<jgarzik>
er (2)
<jgarzik>
:)
<bramc>
I mean, ridiculous in the sense that increasing them isn't a meaningful increase in costs, and they're subsidized
<CodeShark>
indeed, bramc. If ANYTHING is hampering bitcoin adoption, it ain't the fees :p
<jgarzik>
the end result is that you cannot dump video files into the block chain, but you can send "zero fee" transactions if they are "good"
<phantomcircuit>
jgarzik, it doesn't even matter for the memory pool limit whether there's a free transactions space
<jgarzik>
scare quotes intentional
<phantomcircuit>
the default is 48 hours worth of transactions
<phantomcircuit>
if there's a backup that large
<phantomcircuit>
you can be damned sure there wont be any free transactions
<phantomcircuit>
note: im not writing the fee estimation logic
<jgarzik>
phantomcircuit, If a memory pool janitors fails to approximate what is likely to be confirmed in next 48 hours, then NAK - it's not solving the problem
<CodeShark>
I think all transactions should pay at least the smallest fee possible that doesn't create a dust output :)
<jgarzik>
That's why block time approach was taken in the garbage collector "poolman" - you don't have to perform a priority sort
<bramc>
A good first stab at fee estimation is to find the minimum fee/byte of the last block, multiply it by 2/3, randomly add between 0 and 15%, and repeatedly add between 0 and 15% of what you last did for each subsequent block until your transaction is accepted
<bramc>
Also, ummm, needs malleability
<CodeShark>
if for no other reason than to force software developers to make it possible to add a fee :)
<CodeShark>
and get them used to the need for a fee market
mjerr has joined #bitcoin-wizards
<CodeShark>
and we should get rid of the "free" space
<bramc>
And, uh, there needs to be something in the wallet UX to set a maximum acceptable fee
<jgarzik>
bramc, indeed
<jgarzik>
bramc, And that's another can o worms... wallet software UX
<bramc>
A default of a fixed percent of the transaction size is a reasonable first pass
<jgarzik>
a tough, tough problem. Block confirmation wall-clock time is short term unpredictable. Therefore, a user cannot pay to confirm within X time. The user only has rough controls: above average, average, below average or approaching-zero fee choices. It is incredibly difficult to reason, and then for software to figure things out from there.
<CodeShark>
we've basically been encouraging software developers to not even think about fees...and then expect to be able to address the issue of fee-based miner subsidy?
<jgarzik>
Further, transaction fee cost varies based on TX _size_ not value
<jgarzik>
A tiny monetary value with tons of inputs may require a large fee
<jgarzik>
confusing to users
<CodeShark>
sure, that will be a lot easier to do once there's a bunch more money riding on this network, it's got a bunch more users, there's craploads more inertia, and the reward subsidies for blocks are even smaller
<jgarzik>
how to translate into useful UX?
GAit has quit [Read error: Connection reset by peer]
<jgarzik>
CodeShark, no these are all fundamental to bitcoin design itself
<jgarzik>
wallet software improvements only get us so far
<bramc>
jgarzik, I think the things I just said are reasonable defaults: 70% of last smallest fee, rising 0-15% every time including the first, don't go over 5% of the transaction size
<jgarzik>
A user might pay a high fee, and still have to wait an hour for a single confirmation. The economic signalling is _very_ muddy.
<phantomcircuit>
jgarzik, it's provably impossible to solve that problem
<CodeShark>
the fee bidding stuff requires some real design improvements at the protocol level - agreed...but my point is that with the current policy of "let's avoid fee pressure at all costs" encourages even less thinking about how to manage fees in UX
<jgarzik>
phantomcircuit, nod
<phantomcircuit>
better not limit the mempool size at all
<bramc>
or maybe go up 0-30% every time and don't go over 1%, something like that
* phantomcircuit
goes to break something
<jgarzik>
CodeShark, agree there
GAit has joined #bitcoin-wizards
<bramc>
Anyway, these are reasonably understandable values, even for not super technical people
<jgarzik>
It remains highly difficult to translate into a useful UX where the non-technical user may make meaningful conscious choices.
<jgarzik>
To the user, the fee is _random_ because they don't know inputs (and therefore TX size)
<jgarzik>
The user knows monetary values, not technical wizardy
<jgarzik>
It depends on how fragmented is their wallet [collection of unspent outputs]
<bramc>
jgarzik, the general tradeoff between how long to a transaction going through and how much the fee is should be reasonably understandable
<jgarzik>
Users with highly fragmented wallets incur high fees on average
<bramc>
Hopefully their fees are exactly proportional to their amount of dust
<jgarzik>
bramc, very roughly, not exactly
<bramc>
If you're really doing it right every transaction should have two inputs and two outputs
<CodeShark>
bramc, not necessarily
<jgarzik>
bramc, eh, not at all
<CodeShark>
there are many use cases where you cannot do it that way even if you really wanted to
<bramc>
that way you're cleaning up your own dust as you go.
<bramc>
I'm assuming you have a wallet which is doing a bunch of transactions over time
<jgarzik>
wallets should do more defragmenting, yes (and that increases privacy as a side-effect!)
sy5error has quit [Remote host closed the connection]
<bramc>
jgarzik, The effects of defragmenting on privacy are unclear. When I've spoken with people about what algorithms should be used for deciding what to recombine when nobody seems to have particularly clear ideas about how to evaluate the possible approcahes
<CodeShark>
there are also tradeoffs here
<CodeShark>
"privacy" isn't a one-dimensional optimization
<jgarzik>
Related: gmaxwell has proposed including "net-utxo" into the tx size calculation for block size limit
<jgarzik>
to incentivize reducing UTXO
<jgarzik>
IMO a good idea (but needs study etc.)
<rusty>
jgarzik: yeah, enhanced to include checksigops and it could be an all-in-one. I've been calling that "flexcap". But it needs more research and modelling, at least.
<CodeShark>
also, the privacy thing doesn't really apply to certain use cases such as donation addresses or crowdsales where you want to have a public address everyone can send to or check against
<rusty>
jgarzik: note that it could be soft-forked in under some total bytes hardlimit (which is still useful, as allows capacity planning).
<bramc>
CodeShark, still applies, because the privacy of whoever you got the utxo from might matter
<jgarzik>
yup
<CodeShark>
if it all ultimately goes through a single address everything still can be traced
<CodeShark>
but that's a separate issue entirely :)
<CodeShark>
only better crypto will ultimately save us here
<bramc>
There are some cases where you can do a bit better on bytes used to express something, for example if you make multiple payouts at once
<bramc>
Or if you take a bunch of smaller things and glom them all into the same transaction
wallet42 has joined #bitcoin-wizards
<CodeShark>
but the transaction calculation size issue remains
<CodeShark>
or transaction size calculation issue :p
<CodeShark>
coin selection is nontrivial and has no single "correct" solution
<bramc>
If you really want to preserve privacy, then for every transaction you take a utxo bigger than the payout and split it in two
<bramc>
and you... never use your small utxos?
Xh1pher has joined #bitcoin-wizards
<phantomcircuit>
jgarzik, it all needs study... if only we had time.. oh wait we did!
<bramc>
CodeShark, I'd be happy if there was any coherent analysis of it based on non-handwavy metrics
<jgarzik>
...and then there's Confidential Transactions which hides the amount
<bramc>
Confidential transactions are The Right Way to fix the problem, but have some obvious issues
<bramc>
Trying to anonymize transactions via coinswap keeps getting hosed by the amounts giving you away
<CodeShark>
coinjoin would only work if everyone had similar sized inputs and outputs
<bramc>
Chopping into binary tokens helps... sort of... then you're drawing attention to the binary tokens
<Luke-Jr>
confidential transactions pose a problem for miners though
<Luke-Jr>
it basically kills the main indicator of spam vs high priority
<bramc>
CodeShark, coinswap is a lot better than coinjoin, but yeah if if the sizes are similar if they aren't actually the same then you still have a serious problem
<bramc>
Luke-Jr, That's okay if there are real transaction fees
<jgarzik>
CodeShark, RE CoinJoin, one idea I like - though still has problem - is common denominations. Similar to real world analogues of $1 bill, $5 bill, etc. If we break up outputs into common denominations, you preserve privacy through CoinJoin
<Luke-Jr>
bramc: I suppose. I guess we're on the way to real fees anyway.
<jgarzik>
a 96% solution, not 100%
<bramc>
jgarzik, Thats' what I meant by binary tokens
<amiller>
i haven't figured out how you're supposed to combine coinjoin and confidential transactions
<bramc>
amiller, With confidential transactions it's possible to unblind the values to just the recipient
<amiller>
coinjoin works best when there are lots of coins with the same denomination, ct works best when there are coins with hidden value
<bramc>
amiller, When there's confidential transactions you've already solved the amounts problem and are just trying to fix chain of ownership tracing with coinjoin (or hopefully coinswap, because it's better)
<amiller>
is there any way you can do coinjoin on the encrypted values directly
<moa>
coinjoinfidential
nessenc__ is now known as nessence
<bramc>
Hopefully also you have schnorr signatures for doing collaborative signing properly
<amiller>
if you have to open up the value of a coin before doing a coinjoin, then they seem to be sort of at odds
<amiller>
even then it seems like you'd have to find 5 people and tell them all the balance associated with a coin
<bramc>
amiller, I think you have to open them to whoever you're swapping with. Maybe something more clever can be done.
<bramc>
Like, maybe there's a way that we can all collaboratively mush out stuff together so we can make one big transaction with one input from each of us and one output to each of us all with blinded amounts but we can all verify that everybody else is getting their fair output
<phantomcircuit>
jgarzik, power of two outputs is something i actually implemented in a certain wallet ages ago
<bramc>
That's probably a question for greg
<phantomcircuit>
but since nobody else does it you can find it on the blockchain pretttty easily
<phantomcircuit>
amiller, iirc there's a protocol for coinjoin with the encrypted values
<amiller>
phantomcircuit, but you have to reveal your values to the people you're coinjoining with
<Luke-Jr>
phantomcircuit: you might confuse my transactions with those..
<jgarzik>
thus why I like BTC equiv of $1 bill, $5 bill etc.
<phantomcircuit>
amiller, do you? i thought we had one where you didn't
<jgarzik>
has a hope of matching real world use and blending in with the noise (and finding more coinjoin partners)
<amiller>
1 2 5 10 20 50 100 but sometimes you get arrested if you use 2
<jgarzik>
;p
<Luke-Jr>
amiller: what? I used to use $2 all the time
<Luke-Jr>
never had trouble
<amiller>
Luke-Jr, i only said sometimes
<Luke-Jr>
must be pretty rare :P
<jgarzik>
I used $2 to fuck with the system. It created confusion every single time
<jgarzik>
fun^2
<phantomcircuit>
Luke-Jr, younger people who are assistant managers and are newish will flip a shit
<phantomcircuit>
it's amusing
<Luke-Jr>
I encountered a lot of surprise, but not trouble.
<Luke-Jr>
maybe I should try again
<Luke-Jr>
but I had to physically go into a bank to get them
<bramc>
amiller, There might be some mathematical trickery to make the reveal to the other members of the coinjoin unnecessary. I don't know the math well enough to be able to say though.
<CodeShark>
$2 bills and $1 coins never really caught on in the US
<bramc>
Steve Wozniak gets sheets of $2 bills and has tear-off booklets made out of them. He's gotten into legal trouble for them and had to explain that they are, in fact, legal tender, issued by the US government
<phantomcircuit>
amiller, it's equally possible that im too tired btw
<phantomcircuit>
bramc, to a secret service agent no less
<Luke-Jr>
bramc: ah, maybe it's because of the sheets/tear-off
<phantomcircuit>
lol casinos
<phantomcircuit>
Luke-Jr, yup
<phantomcircuit>
he did the perforations himself
<Luke-Jr>
mine were always crisp :p
<phantomcircuit>
which freaked people out
<bramc>
Luke-Jr, Yeah he's totally trolling with those
* Luke-Jr
wonders if those are available to the public
<phantomcircuit>
Luke-Jr, you can buy $2 sheets from the treasury
<phantomcircuit>
and then perf them yourself
<CodeShark>
you can use adhesive, like post-it notes, rather than perforations
<CodeShark>
or even just a simple adhesive binding
<CodeShark>
like notepads
wallet42 has quit [Quit: Leaving.]
<moa>
or toilet roll
<Luke-Jr>
the rubber cement sounds least time consuming
wallet42 has joined #bitcoin-wizards
<Luke-Jr>
wtf, buying sheets costs like 3x face value
<jgarzik>
RE Woz, hehe cool
<jgarzik>
another $2 fan
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
<jgarzik>
Wow, Googling for this shows a lot of "Wozniak prints his own $2 bills" - the smarter ones clarify he gets them uncut from US govt - but I can see how the SS raised an eyebrow
<jgarzik>
dumb journos out there ;p
<jgarzik>
never let the facts get in the way of a good headline or story
wallet42 has quit [Client Quit]
<moa>
hmmm, when can I buy some $2 bills from?
<Luke-Jr>
moa: seems the only reasonable price will be a local bank
<moa>
they had declaration of independence on the reverse side ... can I get them in the mail for bitcoin somewhere lol
wallet42 has joined #bitcoin-wizards
<CodeShark>
lots of interesting developments happening in crypto - I just fear that most of the biggest recent breakthroughs are still based on the discrete log problem
<CodeShark>
would be nice to have a bit more diversity in "hard" problems
nessence_ has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
<nsh>
. Incorporating the property of untraceability of payments into off-line electronic cash systems has turned out to be no easy matter. Two key concepts have been proposed in order to attain the same level of security against double-spending as can be trivially attained in systems with full traceability of payments. The first of these, one-show blind signatures, ensures traceability of double-spenders after the fact. The realizations of this conce
<nsh>
pt that have been proposed unfortunately require either a great sacrifice in efficiency or seem to have questionable security, if not both. The second concept, wallets with observers, guarantees prior restraint of double-spending, while still offering traceability of double-spenders after the fact in case tamper-resistance is compromised. No realization of this concept has yet been proposed in literature, which is a serious problem. It seems tha
<nsh>
t the known cash systems cannot be extended to this important setting without significantly worsening ...
<nsh>
--
erasmospunk has quit [Read error: Connection reset by peer]
<yoleaux>
Non-conventional Digital Signatures and Their Implementations—A Review - Springer
jmcn_ has joined #bitcoin-wizards
rusty2 has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
mjerr has quit [Ping timeout: 256 seconds]
<akrmn>
sipa: For the subchains thing, I've been thinking more about it and I have some ideas to resolve your concerns, but I need more time to fully think about it. Also, gmaxwell said that extension blocks can be argued to be strictly greater than increasing the blocksize. Also, there's the miner decentralization benefits (even Peter Todd agrees). So I think there are some important applications. Give me a week, maybe I'll have more ideas.
<akrmn>
sipa: In the meantime, I would like to know what your vision is for scaling Bitcoin and how will it address censorship resistance and miner decentralization?
afk11 has quit [Ping timeout: 248 seconds]
antanst has joined #bitcoin-wizards
tcrypt has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
tcrypt has quit []
afk11 has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
hashtag_ has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
davi has joined #bitcoin-wizards
antanst has quit [Quit: Leaving.]
jmcn_ has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
davi has quit [Ping timeout: 246 seconds]
bramc has quit [Quit: This computer has gone to sleep]
dEBRUYNE_ is now known as dEBRUYNE
davi has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
davi has quit [Remote host closed the connection]
bramc has joined #bitcoin-wizards
darwin__ has quit []
hearn has quit [Read error: Connection reset by peer]
<isis>
brands' work can sometimes be hard to obtain copies of, not to mention that brands' wasn't shy about patenting every whim that floated through his head.
shesek has quit [Ping timeout: 265 seconds]
www has joined #bitcoin-wizards
* nsh
nods
erasmospunk has quit [Ping timeout: 256 seconds]
erasmosp_ has joined #bitcoin-wizards
Burrito has quit [Quit: gonna try restarting hexchat]
Burrito has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
temujin has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
KFl6WxEUI1Zbp2 has joined #bitcoin-wizards
_biO_ has quit [Remote host closed the connection]
shesek has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
erasmosp_ has quit [Remote host closed the connection]
wallet421 has joined #bitcoin-wizards
wallet421 has joined #bitcoin-wizards
wallet42 is now known as Guest14376
Guest14376 has quit [Killed (wolfe.freenode.net (Nickname regained by services))]
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
shesek has quit [Ping timeout: 252 seconds]
wallet42 has quit [Read error: Connection reset by peer]
jaekwon has quit [Remote host closed the connection]
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
KFl6WxEUI1Zbp2 has quit [Remote host closed the connection]
www has quit [Ping timeout: 264 seconds]
erasmospunk has joined #bitcoin-wizards
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dEBRUYNE has quit [Ping timeout: 244 seconds]
KFl6WxEUI1Zbp2 has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
erasmosp_ has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
shesek has joined #bitcoin-wizards
temujin_ has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
www has joined #bitcoin-wizards
erasmospunk has quit [Ping timeout: 272 seconds]
dEBRUYNE has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
temujin has quit [Ping timeout: 244 seconds]
temujin_ is now known as temujin
wallet421 has joined #bitcoin-wizards
wallet421 has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
wallet421 is now known as wallet42
priidu has quit [Read error: Connection reset by peer]
priidu has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
Xh1pher has quit [Read error: Connection reset by peer]
dgenr8 has quit [Read error: Connection reset by peer]
ThomasV has joined #bitcoin-wizards
kalle_ has joined #bitcoin-wizards
dgenr8 has joined #bitcoin-wizards
Guyver2 has quit [Remote host closed the connection]
arubi_ has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
GAit has quit [Read error: Connection reset by peer]
kalle_ has quit [Quit: Ex-Chat]
damethos has quit [Quit: Bye]
GAit has joined #bitcoin-wizards
temujin has quit [Quit: temujin]
hashtagg_ has joined #bitcoin-wizards
hashtag_ has quit [Ping timeout: 265 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
www has quit [Remote host closed the connection]
AnoAnon has joined #bitcoin-wizards
AnoAnon has quit [Read error: Connection reset by peer]
jaekwon has joined #bitcoin-wizards
sipa has quit [Ping timeout: 265 seconds]
sipa has joined #bitcoin-wizards
sl01 has quit [Ping timeout: 252 seconds]
sl01 has joined #bitcoin-wizards
afk11 has quit [Quit: Leaving.]
afk11 has joined #bitcoin-wizards
GreenIsMyPepper has quit [Ping timeout: 256 seconds]
SwedFTP has quit [Ping timeout: 256 seconds]
huseby has quit [Ping timeout: 256 seconds]
TD-Linux has quit [Ping timeout: 272 seconds]
kanzure has quit [Ping timeout: 256 seconds]
elastoma has quit [Ping timeout: 256 seconds]
afk11 has quit [Ping timeout: 255 seconds]
kanzure has joined #bitcoin-wizards
richardus has quit [Ping timeout: 256 seconds]
Mably has quit [Ping timeout: 256 seconds]
richardus has joined #bitcoin-wizards
darwin__ has quit [Remote host closed the connection]
hulkhogan_ has joined #bitcoin-wizards
darwin_ has joined #bitcoin-wizards
GreenIsMyPepper has joined #bitcoin-wizards
TD-Linux has joined #bitcoin-wizards
TD-Linux has joined #bitcoin-wizards
elastoma has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
dc17523be3 has quit [Ping timeout: 250 seconds]
dc17523be3 has joined #bitcoin-wizards
huseby has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
jmcn has joined #bitcoin-wizards
SwedFTP has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 252 seconds]
prodatalab has quit [Ping timeout: 248 seconds]
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hearn has joined #bitcoin-wizards
KFl6WxEUI1Zbp2 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
KFl6WxEUI1Zbp2 has joined #bitcoin-wizards
<phantomcircuit>
warren, can you send out a test message so people will know that they're subscribed to the correct list?
<sipa>
he's sent a bunch of test mails
<sipa>
others too
<phantomcircuit>
guess im not subscribed correctly..
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 264 seconds]
adam3us1 has quit [Read error: Connection reset by peer]
<nsh>
whoever maintains mailman ironically seems to keep not getting the memo about it no longer being 1992 and asking for passwords so you can send them back in plaintext is maybe not a great idea
<kanzure>
it's not really a password it's more like a textbox where you type random insults
<nsh>
hehe
<nsh>
[random insults which are stored against your permanent record in XKEYSTORE until the heat death of Utah]
prodatalab has joined #bitcoin-wizards
rusty2 has left #bitcoin-wizards [#bitcoin-wizards]
hearn has quit [Read error: Connection reset by peer]
hearn has joined #bitcoin-wizards
jmcn_ has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
chmod755 has quit [Quit: Leaving]
<phantomcircuit>
nsh, given utah heat death is continuously imminent
* nsh
smiles
<nsh>
i think they figured out how to stop everything turning into fire
<nsh>
for the moment, anyway
darwin_ has quit []
jtimon has joined #bitcoin-wizards
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bramc>
After thinking about it some more, I think that practically any attempt to query what the transaction rate on recent blocks were is fraught with danger
<bramc>
Miners can artificially bump up that value with self-payments, which can massively inflate the price if wallets follow it
<bramc>
The only really safe thing is for a wallet to make their first payment by rising up from a small starting value, then each subsequent payment take their last successful value and use some fraction of that as a starting point
<nsh>
why would wallets want to use a measure of transaction volume in making decisions in any case? missed something...
<nsh>
oh, for fee estimation
<nsh>
?
dEBRUYNE has quit [Ping timeout: 244 seconds]
<leakypat>
bramc doesn't that mean waiting to see if it got confirmed before raising the fee?
<bramc>
leakypat, Yeah you raise the fee for each minted block which it didn't get accepted to
<bramc>
nsh, Yeah I'm talking about fee estimation
* nsh
nods
<leakypat>
Right, but that could be hours waiting around and bumping fees
<nsh>
is it not possible to offer variable fee and let miners undercut each other?
<nsh>
not easily at present, i think
<nsh>
some way to recoup a percentage of a high fee offer to ensure rapid confirmation subsequent to mining would be ideal i guess