326600+ entries in 0.186s
sturles: It isn't
that complex.
The uxto set is updated as
the block is parsed.
The inputs of
the sibling will be in
the utxo set when it gets
to it. It only makes some optimizations somewhat harder.
mircea_popescu: no argument
there. but it is not ok merely because some idiots do it atm.
mircea_popescu: yeah, some noncompliant miners are currently doing
this, among many other insanities
they do.
mircea_popescu: there's no way
to write a sane specification for bitcoin
that avoids saying specifically "if input
tx is not found in a block,
tx is invalid"
sturles: I am not saying it is
the right way
to do it, just
that it is how it is.
sturles: Yes. It isn't verey complicated. Really. As long as A is found before B in
the blockchain,
the order is AB. Even if A and B are in
the same block.
sturles: It is in
the design. As long as
the order is correct (perent before child in
the block), it is accepted.
mircea_popescu: yeah, a miner might choose
to do all sorts of patently idiotic shit.
sturles: Well, you may call it a fetus. A miner can choose
to give birth
to both in
the same block.
mircea_popescu: this argument has some merit, but it's really contrary
to bitcoin.
sturles: We are not
talking about orphans here, since we have
the parent in
the mempool.
sturles: People spend unconfirmed outputs all
the
time. Bitcoin Core even does it by itself, if
the output was generated by yourself.
sturles: If a
transaction pays
too low fees
to get included, and you spend an output of
the
transaction with a high fee, a miner may want
to mine both.
mircea_popescu: fucking evil bs, child pays for parent, let's invent OTHER ways
to import meaningless state into bitcoin and fuck it all up
sturles: It knows about
the fee rate of
the children of unconfirmed
transactions.
sturles: I should change my key in #bitcoin-otc
to
the sturle@bitmynt.no key..
assbot: Logged on 03-03-2016 16:44:12; sturles: 0.12 does eviction based on fee/kB. When
the mempool is full, a large share (half?) of
the
transaction will get evicted and a minimum fee ratio
to get included will be set.
sturles: asciilifeform: getrawmempool
true reports for every
transaction: descendantcount, descendantsize and descendantfees, indicating
that it at least knows about it.
mircea_popescu: sturles
that's kind-of a problem
then, you can't voice here.
sturles: asciilifeform: Because it
takes some
time
to do it for large mempools, I suppose. I
think child fees are
taken into account as well, but not sure about
that.
mircea_popescu: so rather
than a preliminary it's actually
the
thing ?
mircea_popescu: i will have
the harem hum your nick during sex for a week in recognition.
mircea_popescu: i claim no ownership interest in
the notion. it's so outrageous a
tree somewhere in
the forest prolly said somethingat some point.
mircea_popescu: da fuck is with
these idiots. "oh,
there's fewer of
those" o ya ? guess what -
there's fewer of niggers and jews, also.
mircea_popescu: somehow,
the fact
that any system
trying
to "include everyone" necessarily excludes
the best and brightest is never a concern.
mircea_popescu: asciilifeform shush you, it's not supposed
to make algebra-2-sense. it's from
the statistics-and-citizensheep
textbook.
assbot: Logged on 03-03-2016 16:34:37; sturles: By default Bitcoin Core will evict
transactions which has been in
the mempool for more
than
three days. A bad idea, because
those will just come back from a node which had
the
transaction for less
than
three days, but since
transactions paying a fee lower
than
the -minrelayfee
threshold are
throttled most low and 0-fee
transactions will be kept out for most of
the
time. I'm sure
there are an infinite amou
assbot: Logged on 03-03-2016 16:46:21; mircea_popescu: i mean i just said, i'd
take 5k for cash right now.
assbot: Logged on 03-03-2016 16:44:42; mircea_popescu: yea, but none of
the elegance of a ring buffer
assbot: Logged on 03-03-2016 16:44:12; sturles: 0.12 does eviction based on fee/kB. When
the mempool is full, a large share (half?) of
the
transaction will get evicted and a minimum fee ratio
to get included will be set.
sturles: There is no priority included in
the calculations for mempool eviction in 0.12.
sturles: 0.12 does eviction based on fee/kB. When
the mempool is full, a large share (half?) of
the
transaction will get evicted and a minimum fee ratio
to get included will be set.
☟︎☟︎ mircea_popescu: anyway, if you're curious, what
trb is contemplating
to eventually do is a ring buffer with a per-kb fee only as
the criteria.
mircea_popescu: i don't recall when
this "3 day"
thing got introduced, but longer
than coupla years ago i
think.
sturles: Back in 2010
there was no eviction in place. Valid
transactions stayed in
the mempool until mined. Various eviction strategies have been
tried for
the last couple of years.
sturles: By default Bitcoin Core will evict
transactions which has been in
the mempool for more
than
three days. A bad idea, because
those will just come back from a node which had
the
transaction for less
than
three days, but since
transactions paying a fee lower
than
the -minrelayfee
threshold are
throttled most low and 0-fee
transactions will be kept out for most of
the
time. I'm sure
there are an infinite amount of
them..
☟︎