sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
PRab has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
eudoxia has quit [Quit: Leaving]
MoALTz has joined #bitcoin-wizards
liteIRC_ has joined #bitcoin-wizards
smk has quit [Ping timeout: 252 seconds]
zooko has quit [Ping timeout: 240 seconds]
liteIRC_ is now known as zooko
JackH has quit [Ping timeout: 240 seconds]
meZee has joined #bitcoin-wizards
smk has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
mrkent has quit []
mrkent has joined #bitcoin-wizards
DougieBot5000 has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
brg444 has quit [Ping timeout: 252 seconds]
CubicEarth has quit [Remote host closed the connection]
zookolaptop has joined #bitcoin-wizards
chmod755 has quit [Quit: Ex-Chat]
tcrypt has quit [Remote host closed the connection]
mrkent has quit []
<Taek42>
midnightmagic: being able to communicate effectively with 'morons' is a powerful timesaving skill. Beneficial to both you and everyone else.
Taek42 is now known as Taek
<Taek>
I had an idea for being able to retroactively add new signature schemes to outputs
<Taek>
Instead of a pubkey, you provide the hash of some secret entropy that could be used to derive a pubkey
<gmaxwell>
then the ZKP that proves its linked is just your 'signature scheme'. :)
<Taek>
Basically
<gmaxwell>
Taek: I'd suggested before if there were a DLP break we could spend unspent coins that way; problem is, of course, all sufficiently performant ZKP schemes are also discrete log assumption (and a much stronger form than ECDSA)
<katu>
Taek: ID-based sig schemes are tad bit heavier than classic schnorr/dsa
<gmaxwell>
Taek: have you seen 'guy fawkes signatures'?
<Taek>
katu: not a problem, you really only want this for emergency situations
<katu>
Taek: depends if you mean guy fawkes, or id based. guy fawkes is just commitment, id based allows pubkeys to be based on specific data
<Taek>
gmaxwell: the snark can be soft-forked into bitcoin after the fact. If a snark ever exists which dodges the discreet log problem then you can still use the scheme.
<Taek>
Actually, p2sh is probably already good enough to offer this protection
<Taek>
gmaxwell: I have not seen guy fawkes sigs before, checking it out now
<gmaxwell>
Taek: can't be soft-forked.
<gmaxwell>
You can't add a new way to spend a existing coin in a softfork.
<gmaxwell>
But who cares? if such a problem existed adding a hardfork way to securely spend the coins would be fine.
<zookolaptop>
There's even a paper on Guy Fawkes Coin by Joe Bonneau.
<yoleaux>
1 Dec 2015 04:11Z <Taek> zookolaptop: <zookolaptop> "Taek: are you the taek mentioned in https://github.com/NebulousLabs/Sia ?" Yes
<Taek>
Oh, right. You'd need a new type of script designed to allow that type of soft-fork to happen.
<Taek>
Which would be a soft fork itself, it just wouldn't apply to today's outputs
<midnightmagic>
Taek: Recognising it is not possible to do so saves even more; further, recognising that the actual intended audience is not the person that someone seems to be responding to is a useful diplomatic ability.
dstadulis has joined #bitcoin-wizards
bendavenport_ has quit [Quit: bendavenport_]
jcorgan|away is now known as jcorgan
liteIRC_ has joined #bitcoin-wizards
Yoghur114_2 has quit [Remote host closed the connection]
zooko has quit [Ping timeout: 264 seconds]
liteIRC_ is now known as zooko
Ylbam has quit [Quit: Connection closed for inactivity]
dstadulis has quit [Quit: ZZZzzz…]
<bramc>
ZKP is fun but in practice protocols are basically all protocols are built on top of the basics: secure hashes, signatures, encryption, and maybe some, ahem, n of n+1 error correcting codes.
rusty1 has joined #bitcoin-wizards
tachys has quit [Remote host closed the connection]
<gmaxwell>
perhaps you'll finally be the person with enough motivation to crunch out the combinitorics for security paramters so I can actually publish the darn thing for other people to read it? :P
<bramc>
gmaxwell, Thanks, I'll read through that to enhance my understanding of ZKP, which is unfortunately rather lacking.
<gmaxwell>
I came up with it as a teching tool to get programmers who are compfortable with hashes, but think of ZKP for general computation as implausable magic.
<katu>
gmaxwell: very lamport-ey
<gmaxwell>
er to get them to open their mind to the idea that these things can work, and that they can be understood.
<bramc>
Funny thing, my very simple signature scheme may or may not have directly lead to the more sophisticated gizmos based on the same math. I suspect nobody really knows, my mention of them seems to be the first time they were discussed and they were sort of 'in the air' for a while.
<bramc>
I also suspect that the work on communication complexity of recovery schemes is directly based on me explaining that that was the interesting problem after I'd worked out my own solution to it. Unsurprisingly other people worked out better solutions later, but the timing seems to indicate that the work got kickstarted by me blabbing to a few people (exactly whom I've forgotten) about what the interesting problem was. Aga
<bramc>
in I suspect nobody really knows.
<katu>
bramc: you mean your lamportey-knapsack or is there something i missed :)
TBI_ has joined #bitcoin-wizards
<bramc>
katu: That's the one. The stupid knapsack trick.
TBI has quit [Ping timeout: 240 seconds]
<bramc>
katu, Actually it's an encryption scheme rather than a signature scheme. I also independently figured out most of the tricks for making lamport signatures independently (I missed winternitz) but that was a few years after the basic had already been published
<jl2012>
do you think it is good to have a bitcoin-wizards mailing list, so people may share academic idea which may not be otherwise suitable in bitcoin-dev?
<bramc>
That reminds me, I came up with some other tricks more recently which aren't in the published literature which I need to explain to somebody. I spent some time thinking about them because they're useful to nonoutsourceability. It's possible to make strongly non-reusable signatures, meaning ones which you can't use more than once without essentially giving away your key. That doesn't play so well with winternitz though.
<bramc>
jl2012, That depends on the signal/noise ratio it manages to maintain.
<gmaxwell>
bramc: "single show signatures" (or even n-show) are a thing in the crypto lit; they're very easy to construct for discrete log signature systems.
<bramc>
gmaxwell, Is there anything in the literature on doing them for lamport signatures?
<gmaxwell>
I see how you could construct one with a hash based scheme, that was a threshold. "x matching preimages out of a bag of m"
<gmaxwell>
Not that I'm aware of.
<gmaxwell>
but I've never looked.
tcrypt has joined #bitcoin-wizards
dstadulis has joined #bitcoin-wizards
<bramc>
The trick is fairly cute, instead of revealing roughly 1/2 of the preimages, you set it up so you have to reveal 99% of the preimages, so if you sign two things you've probably given away way too much. You can make it efficient by making the preimages be generated in a tree, so when you have to reveal a bunch of things next to each other you reveal their common parent.
jcorgan is now known as jcorgan|away
<bramc>
It's entirely possible somebody else figured that out already of course.
<gmaxwell>
high radix digits and you reveal all bit the value of the digit?
<bramc>
I think that's what I said but I'm not sure what you mean.
<gmaxwell>
like take your message hash in (example) base 16 and for each digit reveal 15 of the preimages?
<jl2012>
bramc: there are many interesting ideas in Bitcoin but not well organized. For example, the idea of checking block height in script has been discussed even by Satoshi in 2010, while deployed through BIP65 5 years later. It'd be nice if there is a single place to collect these idea
<bramc>
jl2012, Sounds like a job for a wiki
<gmaxwell>
jl2012: well in particular, people lose track of what costs or benefits these ideas have.
liteIRC_ has joined #bitcoin-wizards
<jl2012>
gmaxwell: yes, and we have to discuss the same over and over again
<gmaxwell>
yes, also some of us get tired of that and tune out, and the discussions can sometimes become less informed over time. :(
<amiller>
a wiki would be good
<amiller>
we have plenty of material for a snarks wiki
<jl2012>
Sometime it is difficult even for me to search my old idea
zooko has quit [Ping timeout: 250 seconds]
liteIRC_ is now known as zooko
<amiller>
a whole bunch of utxo hash data structures
<Taek>
jl2012: I've been pulling together a set of readmes that point to good sources of information. Bit different from a wiki
<gmaxwell>
jl2012: I have a funny story related to that. a while back, I solved a problem that had troubled me for a while in how to create a system for ring signatures which prevent double usage but where participants could not prove they didn't sign later. ... a tool for selecting trusted judges but keeping them private.
<Taek>
I don't like wiki's because they don't give you a good sense of what else exists that you might be interested in. If two pages are mostly unrelated, you are unlikely to find the second after looking at the first
<gmaxwell>
jl2012: I wrote up my solution. Then a week later, I went to look for it... and found a document I wrote nearly a year before. that had the same solution.
<gmaxwell>
and the same optimizations that I thought I was so clever in coming up with just then. :)
<katu>
it infested google results at some point :/
GGuyZ has quit [Quit: GGuyZ]
<gmaxwell>
katu: there have been a bunch of these that proxy the site and replace random links with malware. :(
p15 has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
sparetire_ has quit [Quit: sparetire_]
dstadulis has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
oldbrew has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
paulbernard has left #bitcoin-wizards ["Leaving"]
tromp has quit [Remote host closed the connection]
zooko has quit [Remote host closed the connection]
RoboTeddy has quit [Remote host closed the connection]
Burrito has quit [Quit: Leaving]
brg444 has quit [Ping timeout: 252 seconds]
<Taek>
Ah sorry about that. Fun fact I gave my btt password to one of those once.
<gmaxwell>
erp.
tripleslash has joined #bitcoin-wizards
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
dstadulis has quit [Quit: ZZZzzz…]
tromp has quit [Ping timeout: 256 seconds]
jcorgan|away is now known as jcorgan
ThomasV has joined #bitcoin-wizards
<bramc>
Taek, Password managers are your friend
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 250 seconds]
alexkuck_ has quit [Ping timeout: 264 seconds]
tromp has joined #bitcoin-wizards
alexkuck_ has joined #bitcoin-wizards
adam3us1 has quit [Ping timeout: 272 seconds]
bliljerk101 has quit [Ping timeout: 240 seconds]
adam3us has joined #bitcoin-wizards
tromp has quit [Ping timeout: 250 seconds]
<bsm117532>
Taek: would still be happy to throw up a wiki. The hard part is finding maintainers. It's a lot of work.
<bsm117532>
There are a lot of topics discussed here that lack enough work on them to properly evaluate them. (e.g. DAGs)
<bsm117532>
Which is why I haven't contributed to your knosys yet...I need to finish forming my opinion, which includes simulations and a more quantitative analysis.
<bsm117532>
I chose to present a mostly-introductory talk at Scaling Bitcoin because no one really understands anyone about DAGs AFAICT. But that's mostly useless. We need quantitative analysis to make decisions.
<bsm117532>
*anyone->anything.
<bsm117532>
I've tried to explain to numerous people how the "bitcoin community makes decisions" because it keeps coming up on ignoramous places like reddit and bitcointalk...but my answer is science: demonstrate, quantitatively that whatever you're doing is better. Either the community accepts it and adopts it, or your analysis is wrong (and someone should prove it) or the community is full of idiots and a fork is called for
<bramc>
The process of decision-making in bitcoin is intentionally haphazardous
<bsm117532>
bramc: BTW I've been thinking about your Merkle Sets...I need a data structure like a hash map which can contain mostly-similar data. (e.g. 1000 hash maps differing by one hash each) I've been wondering if your Merkle Set could be used?
bliljerk101 has joined #bitcoin-wizards
<bsm117532>
Doing this wrong costs n^2 while doing it right is linear...
sdaftuar has quit [Ping timeout: 240 seconds]
<bramc>
bsm117532 Not sure what you mean. What makes something a merkle set as opposed to a regular set is that it maintains a merkle root at all times. Unfortunately this obliterates a hash data structure and forces you to use a tree.
morcos has quit [Ping timeout: 246 seconds]
zxzzt has quit [Ping timeout: 260 seconds]
<bsm117532>
Yeah. :-/
<bsm117532>
Also forces you to log(n) complexity instead of O(1) :-/
sdaftuar has joined #bitcoin-wizards
zxzzt has joined #bitcoin-wizards
morcos has joined #bitcoin-wizards
<bsm117532>
Anyway, if you're interested, the "siblings" and "cohort" notions in my talk involve a lot of nearly-same data.
licnep has quit [Quit: Connection closed for inactivity]
<bramc>
bsm117532 How do you propose splitting transaction fees when a transaction occurs in multiple sides of a braid?
<bsm117532>
See slide 17. I use a difficulty-weighting.
<bsm117532>
Each miner receives a difficulty-weighted proportional split.
<bramc>
There needs to be a sanity check of how many generations a braid is allowed to be split before it can't be merged back in. My suggestion would be one: siblings can be merged together, but no uncles or cousins
<bsm117532>
Why?
<bsm117532>
That's the purpose of "cohort". If a bead contains many uncles and cousins, its reward is reduced.
<bramc>
That would get rid of most orphans without reducing the incentive to mine all the latest stuff because you could always get merged it later anyway
<bsm117532>
Orphans in bitcoin get no reward. In my proposal they get a proportional reward. There are no orphans.
<bramc>
I don't see a need for all that complexity. Allowing merging of siblings already gets rid of the vast majority of orphans
<bsm117532>
The incentive to include the latest stuff is that it creates a bread with higher work, incentivizing other miners to mine on top of yours, preferentially.
<bsm117532>
bramc: I agree, merging of siblings works with less complexity, but you still have to keep the block rate low so as to not generate more complex graphs that cannot be described simply as "siblings" and a diamond graph.
<bsm117532>
e.g. your new orphan is a pentagon graph.
<bramc>
Reducing the block rate is viewed as a bit of a pipe dream. You're never going to get it down to seconds, so you're never going to make it fast enough for point of sale transactions anyway.
<bramc>
The risk of incompatible transactions in siblings is very real. In the future it might be the norm.
<bsm117532>
bramc: there's a fundamental limit related to the size of the earth and the speed of light. Bitcoin is many orders of magnitude slower than that. POS not withstanding...
<bsm117532>
bramc: Yep and they're forks.
<bramc>
If everything is a fork the ability to merge siblings doesn't help any
<bramc>
I have enough trouble thinking through all the potential ramifications of just being able to merge siblings, much less anything more complicated. And of course the biggest problem here is that it just isn't going to happen, although the idea has a fair amount of appeal.
<bsm117532>
If it "just isn't going to happen" despite being better than that's dumb...If it's not better then that's the right choice. We'll see.
<bsm117532>
Not everything is a fork, only conflicting transactions.
Guest94083 is now known as [Derek]
[Derek] has quit [Changing host]
[Derek] has joined #bitcoin-wizards
<bramc>
Conflicting transactions might become the norm. For example if rbf becomes standard the way I'm recommending, you're going to see a lot of conflict between similar transactions with differing fees. And if anyone has potential benefits to sneaking in conflicting transactions they're likely to do so.
<bsm117532>
bramc: This has the same consequence for bitcoin/blockchain as it has for my proposal. There's no way to ensure that every miner has the same mempool. Mining is how you select one of the conflicting transactions.
<bramc>
There's 'better' and then there's 'clearly better': If something adds complexity, or concern about possible new attacks (even vague feelings of uneasiness about them because it can't be shown to be clearly safe) then it's likely to not happen. And of course hard forks are generally not going to happen just because.
<bsm117532>
bramc: Don't really care about people's vague feelings, I'll back mine up with numbers. Paper due by the end of the month...
<bramc>
Whenever there's a conflict resolution algorithm people are going to feel queasy about it unless its properties can be absolutely nailed down. That's generally very hard to do.
<bsm117532>
I've absorbed many good suggestions, but prognostication about decision processes based on vague feelings is not productive...
<bsm117532>
Will do the best I can...
<bsm117532>
I'm uneasy about making an altcoin. But I'll do it if necessary.
<bramc>
Well to date there's no process for doing hard forks and many people are against it even in principle, so that's a hurdle.
<bramc>
Even for soft forks decision making tends to be slow and haphazard, as you'd expect from something which intentionally tries to make it impossible to have central control.
<bsm117532>
I'll just quote jgarzik here: "A hard fork will signal that we’re willing to grow, that we’re willing to change, that we’re willing to change the system. Not increasing it will be seen as, we want to increase fees, we want to push people off the system."
<bramc>
That is hardly a consensus view. Many take the opposite view that transaction fees are not only a good but a necessary thing, and pushing them off creates permanent weaknesses
<bsm117532>
tx fees are good and necessary. Increasing them by failing to increase blocksize or otherwise increase scalability is dumb.
<bramc>
Increasing the blocksize in many ways decreases scalability because it makes it much harder to run nodes.
<bsm117532>
Good. Run faster nodes. And let's talk about sharding.
<bramc>
AUGH
<bramc>
those both directly impact security in a horrible way
<bsm117532>
I simply don't understand this perspective of keeping bitcoin slow as being in any way desirable.
<bsm117532>
I've never seen any sensible sharding proposal, but we need to go there.
bit2017 has joined #bitcoin-wizards
<bramc>
The generally favored approach of improving transaction times is to use microchannels. Running the numbers on proposals for reducing block times, even with crazy block-merging tricks, looks fairly hopeless
<bramc>
Sharding is inherently susceptible to all kinds of crazy attacks. You're never going to see the community as a whole build consensus behind it being a good idea.
<bsm117532>
bramc: I've never seen any numbers on "crazy block-merging tricks". Do you have any refs?
<bsm117532>
bramc: if bitcoin can't shard, it's dead.
<bramc>
bsm117532 only stuff I've run myself, the main point is that to work for point of sale you need transaction times well under 10 seconds. If you reduce block times to like 1 second and figure orphans always get merged you start getting extremely unpleasant intentional forking attacks.
<bramc>
Sharding isn't going to happen. It doesn't even improve scaling all that much. Net settlement is a fundamentally better approach.
<bsm117532>
bramc: I don't think my proposal can make a blockchain fast enough for POS. I do think it could get confirmation times under 10s though.
<bsm117532>
bramc: We may be talking about different things WRT sharding. I mean a node processing only a fraction of the blockchain, while maintaining the security as though every node was processing every transaction. I don't know how to do that yet...
<bramc>
I don't think trying to get the block interval much lower is a particularly useful thing in and of itself if it can't hit POS. Getting the orphan rate down is a good thing for its own reasons though, even if the block time and overall transaction rate remain the same as they are right now.
<bsm117532>
Intentional forking attacks just increase confirmation time.
<bsm117532>
bramc: That's my target, I don't think POS is possible.
<bramc>
Keeping miners from killing the orphans of others is a good thing, the problem is avoiding giving them new ways of elbowing each other in the process of getting rid of the old ones.
<bramc>
Intentional forkage could be very valuable if it enables fraud
<bsm117532>
It's something deserving of careful analysis before adopting any faster idea.
<bsm117532>
Too much dismissal of ideas without analysis here. Agreed it's an issue, not agreed that it's insurmountable...
<bramc>
There are proposals to allow peers to do partial validation, that's a bit different from sharding.
<aj>
bramc: i keep wondering if it wouldn't be interesting to make a "crobots" style game, where you could program strategies for miners and test them against different potential rulesets for bitcoin
<bramc>
aj usually the strategies are simple enough to work out with pencil and paper
oldbrew has quit []
<bsm117532>
bramc: partial validation with a ZKP proving that validation had been done on the portion of the UTXO set I'm not holding would work.
<bsm117532>
aj: I agree with bramc, it isn't that complicated. ;-)
<aj>
bramc: yeah; but i wonder if something more interactive/demo-like would be more persuasive for the people who aren't already convinced
<aj>
bramc: (there's also the handful of cases where when you work it out via pen-and-paper you miss a case that turns out to be important)
<bramc>
bsm117532 I didn't say that the problems with merging of blocks are insurmountable, just that there are many problems. I will grant you that I'm rather flatly saying that I don't think they'll reduce block times enough to make a fundamental difference there.
<bramc>
That would be an interesting use of ZKP. It probably would create way too much latency with current technology and also still leaves open attacks where someone could hog all the nodes in a certain part of the space and cause the data there to become completely unrecoverable
<bsm117532>
bramc: Regardless of block time the double-spend attack dominates when the attacker is willing/able to give a different double-spend to each node. It could be done with bitcoin now if an attacker wanted to create 6000 double-spends. That no one has done it is that 10m and 6000 are annoying numbers, not that it's impractical or impossible.
<bramc>
Generally it's a good idea to wait until a few blocks have passed before accepting a transaction as truly committed
<bramc>
aj Having a simulation could easily miss the sorts of malicious behavior which a pencil and paper 'simulation' does as well.
<bramc>
There is one clear benefit to a shardable architecture: It guarantees that a node with many cores will be able to scale up with the cores. That's worth something, especially in the future as the number of cores goes up.
<bsm117532>
I'm not saying I have a ZKP proposal. But it seems possible. Sharding is necessary or we're doomed to 3tps.
damethos has joined #bitcoin-wizards
<fluffypony>
isn't that just what Lightning is? shard transactions by payment hub, settle back to the blockchain
<bsm117532>
Maybe we can get it to 10 with segwit and braids, but sharding is very, very important.
<bsm117532>
fluffypony: see the projections at Scaling by the lightning folks. Even with all their desired features, they're talking ~200M accounts. Not enough for the people and businesses of the world.
<bsm117532>
(though, granted, a huge improvement and we should jump on it ASAP)
<aj>
bsm117532: it's only a factor of 50x off being that, though; 50MB blocks aren't unimaginable
* bsm117532
shivers at the 50mb orphan rates.
<fluffypony>
"To some extent, these are pretty vague, but I would say if you do have 200 million people using the lightning network, it's probably the case that not half of the transactions are channel open and channel close transactions, it would probably be 80 to 90% of the blockchain transactions are LN related, in which case you could probably get to 800 million users."
frankenmint has quit [Remote host closed the connection]
<bsm117532>
Let's call that optimistic and pursue all available options. ;-) Also, I don't want to wait a week for my LN channel to close (which is a bitcoin problem, not a LN problem)
<bsm117532>
LN opens a new attack channel in which one party forces the other to close their channel, locking up their funds. Locking up someone else's funds can be profitable in the right circumstances.
<aj>
bsm117532: hmm, my bad; 200M users per dryja was 32MB blocks, so 1.6GB for 10B users
<bsm117532>
Yikes.
tromp has joined #bitcoin-wizards
<fluffypony>
at some point you've got to decide whether you want to kick the can down the proverbial road (which might be 10-20 years in the future before it becomes a problem)
<fluffypony>
or you want to solve all of the things now, in which case we might be here for 10-20 years before we have a solution :-P
<bsm117532>
Let's put all available effort into all available options. ;-)
<aj>
bsm117532: ah, i get 228MB/block for 10B users, but I'm assuming 100% lightning txs, 100% of closes are reopens, and channels last 12 months not 6 months
<aj>
bsm117532: "sharding" by just having pegged sidechains is one easy solution for that, of course
* bsm117532
waits for a mined sidechain.
<bsm117532>
federated pegs are a centralized solution.
<bsm117532>
So, not easy.
tromp has quit [Ping timeout: 256 seconds]
<bramc>
sidechain pegging isn't meant as a scalability solution
<fluffypony>
they're not, but what if you sharded it by country - a sidechain + LN per country, cross-country payments are merely moving funds between sidechains
<bsm117532>
bramc: It could be though, by localizing a pile of tx's somewhere else.
<fluffypony>
s/cross-/inter-
<bramc>
With relative timelock you can keep channels open essentially indefinitely. Right now we aren't even at the most basic transaction rate limit though. Tiny transaction fees are likely to get rid of a lot of garbage, and channels-based transactions enabled by a soft fork can get a bunch more orders of magnitude. That's plenty for now. Approaches which provide additional scaling are interesting and good to study but not thi
<bramc>
ngs to implement in the short term.
<bsm117532>
bramc: I never said anything about short term. But if the perfect remains the enemy of the good for the long term, we'll end up competing in the marketplace among them. I'd rather that the community agree that better was better and absorb it, than force a marketplace decision. Anyway, not something anyone needs to worry about for a while.
dEBRUYNE has joined #bitcoin-wizards
nabu has quit [Ping timeout: 245 seconds]
RoboTeddy has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
CubicEarth has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
dEBRUYNE_ has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 256 seconds]
CubicEarth has quit [Remote host closed the connection]
Taurohtar has quit [Quit: Leaving]
benten has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
atgreen_ has quit [Ping timeout: 256 seconds]
atgreen_ has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 250 seconds]
RoboTedd_ has joined #bitcoin-wizards
dEBRUYNE_ has quit [Read error: Connection reset by peer]
dEBRUYNE_ has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 250 seconds]
RoboTedd_ has quit [Ping timeout: 256 seconds]
sparetire_ has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
damethos has quit [Ping timeout: 256 seconds]
dasource has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
rusty has quit [Ping timeout: 272 seconds]
licnep has joined #bitcoin-wizards
zmachine has quit [Ping timeout: 256 seconds]
zmachine has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
dEBRUYNE_ has quit [Ping timeout: 256 seconds]
frankenmint has quit [Remote host closed the connection]
bit2017 has quit [Ping timeout: 272 seconds]
bramc has quit [Quit: This computer has gone to sleep]
<maaku>
huh, reddit is blocked in indonesia
<maaku>
this could be a very productive place to be
GAit has joined #bitcoin-wizards
<phantomcircuit>
maaku, ha
DJCoding has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
jcorgan has quit [Ping timeout: 245 seconds]
ThomasV has quit [Ping timeout: 272 seconds]
Terry4 has quit [Quit: Terry4]
benten has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
beanlein has joined #bitcoin-wizards
dEBRUYNE_ has joined #bitcoin-wizards
GAit has quit [Read error: Connection reset by peer]
GAit has joined #bitcoin-wizards
JackH_ has joined #bitcoin-wizards
JackH has quit [Ping timeout: 272 seconds]
corb has joined #bitcoin-wizards
JackH_ has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 256 seconds]
chmod755 has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
c-cex-finch has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
Londe2 has quit [Quit: Londe2]
Quanttek has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
gocrazy has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
licnep has quit [Quit: Connection closed for inactivity]
DJmauler has joined #bitcoin-wizards
dstadulis has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
gocrazy has quit [Remote host closed the connection]
nickeem has joined #bitcoin-wizards
gocrazy has joined #bitcoin-wizards
dstadulis has quit [Read error: Connection reset by peer]
RoboTeddy has quit [Read error: Connection reset by peer]
RoboTeddy has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
gielbier has quit [Ping timeout: 240 seconds]
mrkent has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
matsjj has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
damethos has quit [Client Quit]
bendavenport has quit [Quit: bendavenport]
SgtStroopwafel has quit [Read error: Connection reset by peer]
adam3us1 has joined #bitcoin-wizards
bendavenport has joined #bitcoin-wizards
SgtStroopwafel has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 272 seconds]
Luke-Jr has quit [Excess Flood]
erasmosp_ has quit [Remote host closed the connection]
Luke-Jr has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
matsjj has quit [Remote host closed the connection]
eudoxia has joined #bitcoin-wizards
MoALTz has quit [Read error: Connection reset by peer]
matsjj has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
MoALTz has joined #bitcoin-wizards
lmatteis has quit [Quit: Connection closed for inactivity]
matsjj has quit [Ping timeout: 272 seconds]
grizzly_ has joined #bitcoin-wizards
jcorgan|away is now known as jcorgan
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
polyclef has joined #bitcoin-wizards
fkhan has quit [Ping timeout: 240 seconds]
tripleslash has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
hashtag has joined #bitcoin-wizards
zooko has quit [Ping timeout: 250 seconds]
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
tripleslash_a has joined #bitcoin-wizards
tripleslash has quit [Ping timeout: 256 seconds]
PaulCapestany has quit [Quit: .]
RoboTeddy has quit [Remote host closed the connection]
RoboTeddy has joined #bitcoin-wizards
PaulCapestany has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
bendavenport has quit [Quit: bendavenport]
ThomasV has quit [Ping timeout: 240 seconds]
zooko has joined #bitcoin-wizards
bendavenport has joined #bitcoin-wizards
CubicEar_ has joined #bitcoin-wizards
CubicEarth has quit [Ping timeout: 250 seconds]
NewLiberty has quit [Ping timeout: 250 seconds]
liteIRC_ has joined #bitcoin-wizards
licnep has joined #bitcoin-wizards
tripleslash_a has quit [Ping timeout: 256 seconds]
zooko has quit [Ping timeout: 240 seconds]
liteIRC_ is now known as zooko
erasmospunk has joined #bitcoin-wizards
liteIRC_ has joined #bitcoin-wizards
corb has quit [Ping timeout: 240 seconds]
zooko has quit [Ping timeout: 250 seconds]
liteIRC_ has quit [Read error: Connection reset by peer]
zooko has joined #bitcoin-wizards
liteIRC_ has joined #bitcoin-wizards
zooko has quit [Read error: Connection reset by peer]
liteIRC_ is now known as zooko
gocrazy has quit [Ping timeout: 256 seconds]
polyclef has quit [Quit: polyclef]
polyclef has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
c0rw|zZz is now known as c0rw1n
erasmospunk has quit [Remote host closed the connection]
zooko has quit [Read error: Connection reset by peer]
zooko has joined #bitcoin-wizards
liteIRC_ has joined #bitcoin-wizards
zooko has quit [Read error: Connection reset by peer]
liteIRC_ is now known as zooko
liteIRC_ has joined #bitcoin-wizards
gocrazy has joined #bitcoin-wizards
liteIRC__ has joined #bitcoin-wizards
mrkent has quit []
liteIRC_ has quit [Read error: Connection reset by peer]
zooko has quit [Ping timeout: 264 seconds]
zooko has joined #bitcoin-wizards
liteIRC_ has joined #bitcoin-wizards
zooko has quit [Read error: Connection reset by peer]
liteIRC_ is now known as zooko
liteIRC__ has quit [Ping timeout: 240 seconds]
fkhan has quit [Ping timeout: 240 seconds]
jtimon has quit [Ping timeout: 240 seconds]
liteIRC_ has joined #bitcoin-wizards
polyclef has quit [Quit: polyclef]
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
zooko has quit [Ping timeout: 272 seconds]
liteIRC_ is now known as zooko
ThomasV has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
liteIRC_ has joined #bitcoin-wizards
gielbier has joined #bitcoin-wizards
lmatteis has joined #bitcoin-wizards
zooko has quit [Ping timeout: 250 seconds]
liteIRC_ is now known as zooko
gielbier has quit [Ping timeout: 272 seconds]
TBI has joined #bitcoin-wizards
c-cex-finch has quit [Quit: Connection closed for inactivity]
TBI_ has quit [Ping timeout: 240 seconds]
CubicEar_ has quit [Remote host closed the connection]
mrkent has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
bildramer has quit [Read error: Connection reset by peer]
<jonasschnelli>
Had a wired thought. Could an attacker misuses transaction that are just above the mempool eviction fee limit for communication between nodes? Keep a tx in limbo?
bildramer has joined #bitcoin-wizards
<jonasschnelli>
And could I evict a tx with RBF from the mempool?
<phantomcircuit>
jonasschnelli, huh?
<instagibbs>
not sure what first Q means, 2nd, sure. High enough feerate
ThomasV has quit [Ping timeout: 250 seconds]
<instagibbs>
larger/higher feerate txn
<adlai>
jonasschnelli: if you're willing to suffer the risk of donating a low mining fee occasionally, yes, you can abuse tx relay for broadcast
<jonasschnelli>
Yes. A miner could mine the tx intentionally even if it's not economical.
<jonasschnelli>
But could I attack a mempool by endlessly RBF a transaction that will be very likely not mined?
tromp has joined #bitcoin-wizards
<adlai>
not endlessly, if you require that the replacement be more expensive than the original
<morcos>
jonasschnelli: both RBF and mempool eviction were designed to prevent this problem which we've been calling "free relay"
<morcos>
the idea is that every byte transmitted on the network should have always had at least minRelayFee per byte paid for it by some tx that got mined
tromp has quit [Ping timeout: 240 seconds]
<jonasschnelli>
morcos: okay. But would it not be possible to use tx eviction as a way to "free relay" my inputs again?
<morcos>
thats what the mempool minfee is for
<morcos>
if your tx got evicted with fee rate X
<morcos>
then we know any new txs have to pay at least X + minrelayrate
<morcos>
so its at worse equivalent to you paying minrelayrate for your new tx (and X for the old one)
bramc has quit [Quit: This computer has gone to sleep]
<phantomcircuit>
jonasschnelli, you're required to increase the fee rate as well as the gross amount of fees paid by at least the dust limit
<morcos>
phantomcircuit: min relay not dust
<jonasschnelli>
Ah. So, the mempool keeps track of evicted tx and know later that my new to needs X+minrelayfee?
<phantomcircuit>
morcos, "some non zero amount" :)
smk has quit [Ping timeout: 252 seconds]
<jonasschnelli>
s/to/tx (sry phone typing)
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
<morcos>
jonasschnelli: correct. it applies it to all new txs so it might not be your tx that pays for the evicted tx, but someone will, and you can' tkeep doing it b/c teh rate stays high
<morcos>
it exponentially decays down so there is actually some limited amount of free relay allowed, but its pretty small
<jonasschnelli>
Ah. I see. Thanks. All clear now.
<morcos>
i can't remember what we though reasonable, but on the order of block transmission rates, so 1MB per 10 mins.
<morcos>
the missing piece is that the min relay rate is still hard coded and may eventually become too small relative to tx fees to be effective
<morcos>
i was going to send an email to the mailing list explaining all that and how that needs to float in the future, but thats right when i got fed up with the mailing list
<morcos>
i should revisit it now
digitalmagus has joined #bitcoin-wizards
hashtag_ has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 240 seconds]
Erik_dc has quit [Remote host closed the connection]
gocrazy has quit [Remote host closed the connection]
Burrito has quit [Quit: Leaving]
oldbrew has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
adam3us1 has quit [Quit: Leaving.]
nubbins` has quit [Quit: Quit]
NewLiberty has quit [Ping timeout: 272 seconds]
tachys has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 250 seconds]
<dgenr8>
so, the txes that come after a flood have to pay for all the txes that were evicted by the flood. i don't see how that's going to stop the next flood.
se3000 has quit [Quit: se3000]
DougieBot5000 has quit [Quit: Leaving]
<kanzure>
zooko: do you know of any papers that explore impacts on fungibility of AML (anti-money laundering) regulation? most of this is obvious to us but i'm curious to see academic exploration of this.
bramc has joined #bitcoin-wizards
<adlai>
the arc/dike combination of minimum relay fees and minimum eviction costs (and capacity limits!) should keep the orc flood from drowning out the SNR
matsjj has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
matsjj has quit [Remote host closed the connection]