327200+ entries in 0.21s
mircea_popescu: kakobrekla but it's not about me, per se, it's about
the
thing, such as it is.
kakobrekla: im afraid you wont go for
that because you dismiss
things with "notion
that $item is relevant
to
this discussion is shocking/ridiculous"
mircea_popescu: a lot of fingerprinting you can do by just listening. it's a large
topic,
this.
BingoBoingo: !up Luke-Jr May get an ack if "brick chicom miners" goes with it? Been hanging out with stroke victims recently and my brian is having sympathy deficits so I gotta defer
to
the peerage.
PeterL: or did we do
that and
that is why we had
to add
the high/low s
thing?
mircea_popescu: well, you have a large pile of stuff
to explain away
then. i'd be curious
to read
the alt
theory kakobrekla
PeterL: I guess you cold
test whether you are directly connected
to miners or bridged by prb nodes: send a
txn which prb does not like, see if it gets included in a block
kakobrekla: hence i dont agree with your interpretation of events (that bbet/you is
targeted here - in which case its game over)
mircea_popescu: things are what
they are, you make of
them what you will.
mircea_popescu: looky, not like you have
to accept or not accept anything.
mircea_popescu: kakobrekla "that is not a bridge" "please build me a bridge over here so i can see
this" "orly"
kakobrekla: who else is
then connected
to
the miners? do
tell?
mircea_popescu: kakobrekla not even. prb is more or less
the random noise.
kakobrekla: prb is what relayed your
txes
to
the miner gates.
mircea_popescu: punkman
the notion
that prb is relevant
to
this discussion is shocking/ridiculous, depending on your mood.
mircea_popescu: the advantage being, of course,
that i have a whole lot of canaries in all sorts of apparently unexpected places.
the drawbacks... heh, let's not
talk about
that, i'll just get angry.
mircea_popescu: you have
to understand
that
the direct correlate of "bitcoin protocol is nowhere" is
that i'm stuck sitting here wasting
tons of resources and various people's
time doing an endless array of stupid or plain weird shit
to see what happens
to
try and understand what's what.
☟︎ punkman: relevant: "Bitcoin Core will only allow replacement of
transactions which have any of
their inputs’ nSequence number set
to less
than 0xffffffff - 1." (in 0.12 release)
mircea_popescu: from experience,
the stuff
the chinese miners run would, at least most of
the
time. historically i
thought
this is just random variance between divergent implementations, but now i
think it's a single unit behaviour modulated somehow. also,
this is essentially what "Replace by fee" is all about, iirc.
punkman: mircea_popescu: which implementations would accept a replacement
tx with a fee, assuming
they still have
the 0fee
tx in mempool
mircea_popescu: punkman you mean which implementations would accept a
tx with a fee ? seeing how
they wouldn't see
the other one ? or what ?
kakobrekla: who here has control over approving
the comments ?
mircea_popescu: PeterL ask vessenes and
the merry friends/captains of industry/power rangers/etc
punkman: which implementations do you
think would accept
the subsequent higher-fee
transactions (putting aside
the fact
that you couldn't see
the first 0fee
tx in anyone's mempool)?
mircea_popescu: by and large, very broadly speaking, and insasmuch as a "bitcoin protocol" even exists at all - it says
that 0 fee
txn aren't relayed or included. now, how
this is implemented in practice... w/e.
PeterL: Where is
the protocol documented?
mircea_popescu: punkman iirc no, but
the plan was
to get
the pool sorted by per/kb
tx fee
mircea_popescu: asciilifeform looky,
this isn't how
this sort of discussion works, by giving counterexample.
punkman: so one
thing
that hasn't been mentioned, does
trb even replace
transactions when new one comes in with higher fee?
assbot: Logged on 02-03-2016 16:20:40; mircea_popescu:
the protocol is
that 0 fee
txn can't even be relayed.
PeterL: while I am saying
the iners are just going
to keep
the older
txn, regardless of fee
mircea_popescu: PeterL
this is not what was said! didja read
the qntra piece ?
mircea_popescu: the miners are running
their own shit, and it's centralized.
PeterL: you seem
to
think you can just send a new
txn with a higher fee and expect it
to get processed faster
mircea_popescu: kakobrekla and guess what -
trb gets blackholed now and again. prb never mattered.
kakobrekla: even different
trb build do different stuff.
kakobrekla: there isnt one.
trb behaves differently
than prb if nothing else.
PeterL: and
the miners in your scheme see
the higher fee and put
the second
txn in a block
mircea_popescu: kakobrekla or so we
thought. but it
turns out
that no,
there's exactly one, covered in a cloud of buzzing shit.
kakobrekla: and
this makes it,
to an extent, unpredictable.
mircea_popescu: PeterL
this is miserable "writing down". what are you, a consumer ? HOW do you doublespend.
PeterL: ok, I buy some egold from bob, send him 1 btc. He sees
the 0conf
txn,
transferes
the egold
to me,
then I doublespend
the inputs with a higher fee, sucks
to be him
mircea_popescu: but yes, because "the protocol" is not even written down, endless arguments of
this nature can be had. by and large...
mircea_popescu: write down what a party would need in order
to do
this.
kakobrekla: 0 fee
txn can't even be relayed. <
this is not
true
PeterL: what if it is just somebody
trying
to scam by getting a party
to accept a 0conf
txn, and
then double spending it?
PeterL: but is
the protocol
to keep older
txn or newer, does fee size matter?
mircea_popescu: because it's part of a set of mutually incompatible
txn, and some of
the others have better fees, for instance. if you're am iner, you want
the higher fee.
PeterL: why not hold onto a 0fee
txn until later?
mircea_popescu: it's certainly not a behaviour supported or even possible by any codebase so far published, if you
think code=protocol instead.
mircea_popescu: it is breaking
the protocol inasmuch as a protocol exists.
PeterL: maybe a mine who likes
to listen instead of
talk held onto
the first
transaction?
mircea_popescu: i didn'taskl anything of anyone. i listen
to a large cross-section of
the bitcoin relay network.
PeterL: you asked
the miners specifically?
PeterL: which is why none of
the other
txn
that followed it were included,
they were invalidated by
the first
txn which was in
the miners' mempool
mircea_popescu: that happens
to be, involuntarily i guess, and impredictably for
the attackingside, i guess, a passive
timing of
their capabilities.
PeterL: maybe it was
the miner who had been holding it who broadcast it?
mircea_popescu: PeterL
the operative part
there is,
txn was "broadcast" and
then "included in a block" within 20-odd minutes.
PeterL: if it had been
two days instead of
two hours after
the other
transaction, would you still have concluded miner collusion?
PeterL: I still dun see why you jump
to
the conclusion of miner holding blocks, maybe
they rebroadcast
the
transaction as
they moved it from "0fee waiting line"
to "now including
these
txen" when
they had held it long enough for
the wait
time
to increase its priority?
mircea_popescu: asciilifeform was it sourced from bitbet payouts ? i recall pete_dushenski saying
the same happened
to him, originally blamed it on multibit.
assbot: Logged on 01-03-2016 23:32:18; mircea_popescu: i personally
think
the only reason it's not mined yet is
that
there hasn't been a block.
PeterL: how do you know
they are delaying?
kakobrekla: 0 fee
txes are quite relayable,
tried not a week ago.
mircea_popescu: within "minutes", where "minutes" just neatly fits in
the cartel head-of-best-chain report delay.
mircea_popescu: and, ironically,
the substantial proof
that
there was nothing wrong with any of
them PER SE, was
that a
tx
that, as per
the protocol, should not even have been relayable made it into a fucking block
kakobrekla: and for
the next
tx will it again
take a week and not be done again ?
mircea_popescu: i am saying
that i spent OVER A WEEK making
transactions from
those inputs.
kakobrekla: so you are saying you are unable
to make any further
txes on bitcoin network at all?
mircea_popescu: and
to fix
this
then your advice is
to what, make An+1 ? because
then surely ? for how long ?
mircea_popescu: what do you do, make ANOTHER
tx
to go in
the An delayed-forever pile ?
PeterL: weren't you already
talking about setting up your own pool?
kakobrekla: or move
the inputs of
the first
tx beforehand and invalidate
the doublespend possibility
PeterL: you just need your own miner
to doublespend
the inputs
to cancel
the first
txn
PeterL: I am not
thoroughly convinced
PeterL: unless
this exposes some flaw in
the bitcoin system, and
the btc price crashes, and
then we are all fucked
PeterL: I mean, uh, hypothetically, if I was one of
the bettors ... uh.. nevermind
PeterL: I guess I can't complain
too much about
this bitbet blunder,
the "extra winnings" I got from
the bet was higher
than my proportion of
the loss as a bitbet shareholder (unless
this
tanks
the share price
too)
mircea_popescu: well for starters, deleting
this "must hardfork
to prove we can do it" nonsense and replace it with
the much more sensible "must brick miners
to prove we can do it", at
the very least.
mircea_popescu: you
think you're using
the bitcoin network, but in fact you're using
the chicoin network.