906800+ entries in 0.698s
mircea_popescu: right, what io'm sauying is,
this is a working prototype
mircea_popescu: i still need
to see someone argue convincingly
that goxlag is bad for bitcoin.
mircea_popescu: for
that matter,
they don't
trust
themselves enough
to believe
their eyes. if respected people don't say
there's a problem,
there's no problem.
mircea_popescu: zero impact, for
that matter.
the lemmings aren't in
this channel.
they will never know
today happened
gribble: BTCUSD
ticker | Best bid: 117.53004, Best ask: 117.94999, Bid-ask spread: 0.41995, Last
trade: 117.53002, 24 hour volume: 26422.96173181, 24 hour low: 114.50020, 24 hour high: 118.88000, 24 hour vwap: 117.07249
mircea_popescu: much like cornering markets appears possible
to do in static representations of reality.
mircea_popescu: it apperars possible
to do, but only in static representations of reality
mircea_popescu: asciilifeform
the reasoning is
that basically bitcoin is a sort of morphism on
the fiat world, and i am pretty convinced by now
that
the 51% attack is
the local equivalent of
the market cornering problem.
mircea_popescu: i
think actual 51% past
this point is an impossibility
mircea_popescu: asciilifeform
the world is made of probabilities not certainties.
mircea_popescu: ThickAsThieves pretty much everyone is having
trouble with
the 8.2 duality.
mircea_popescu: i mean it looked fucking weird as all hell for a coupla hours
there, but...
mircea_popescu: ThickAsThieves nah
there was a 1hr+ pause just as
the new bitcoind changed signature rules making it look like a multifork
mircea_popescu: anyway, i'm putting it off
to string of extremely unlikely coincidences.
mircea_popescu: ThickAsThieves read up
the history, we've had some excitement.
benkay: her mircea do you have a link on hand
to your piece commenting on monetary sterilization"
ezdiy: optimator: i
think some json api for pools would be in order
ezdiy: but
the ones you found in your mempool are already verified, because you do
that whenever
they arrive in your mempool
optimator: sure - 300 ms
to getblock, compare, and recalc
ezdiy: and just 1:1 compare with your mempool, if possible -
the general case is lots of
those will be same
ezdiy: you get new block, and look at inputs of all
transactions in
there
optimator: plus you'd have
to get
the new block because you don't know what
txs were included in it
ezdiy: carefully pruning
the outdated utxos must be written from scratch :(
ezdiy: because simple flush-and-redo is much simpler
to implement
optimator: ezdiy: yeah, maybe. I
think you are coming at it from
the bitcoind level and I'm coming at it from
the json-rpc level
ezdiy: optimator:
the
trick is, when new block arrives, you just remove
txes which are in it from your mempool (no verify needed, no seeks needed) and recompute merkle
ezdiy: not
to mention slow ecdsa verify
ezdiy: or much more if youre clever
to push lots of utxos which will seek all
through 6gb
optimator: ezdiy: yes, in bitcoind. It's can be 300 ms
to get
the new
tx list
ezdiy: so people dont invent crazy hacks
to prevent stales
ezdiy: optimator:
this is probably something
to be fixed in bitcoind,
though :(
ezdiy: optimator: yes,
thats how it works and why slush pushes empty merkle for
the mean
time
ezdiy: but you *dont* have
to
to verify sigs again
optimator: imagine a queue
that you are pushing new
txs on. You keep building it up, but when a new block is found
the queueu is emptied
ezdiy: you, you have
to re-verify
txes which use same utxos as
the
txes in newly arrived block
optimator: it doesn't work
that way.
The block height is incorporated into
the hash function. So you can know what
to push unless you know
the block you are working on
ezdiy: thats just being lazy,
to
the detriment of users
ezdiy: optimator: no,
the merkle root should be updated continuously by slush
optimator: i see it as rewarding
them for
their work on
the network
ezdiy: it profits only
the miners, not users
ezdiy: but
the underlying idea is only greed
optimator: we'll it's beyond a long shot - within seconds new work is pushed with
transactions. Otherwise
the miners would be working on work for a block
that had already been solved
ezdiy: i'm surprised
theres no bloody murder scream from users about 1-tx blocks
ezdiy: optimator: not most optimal solution
then,
though :/
optimator: and on
the off chance someone solves it everyone is rewarded
optimator: ezdiy: when a new block is found
the pool code pushes work out with no
txs. it does
this while it builds
the new merkle root.
that way
the miners have work immediately
ezdiy: means his bitcoind must have been somehow convinced
there were no
txes *at all*
ezdiy: but slush is signed in coinbase if you click at
txid
ezdiy: block with no
transactions
mircea_popescu: tjhat just shows how dysfunctional
the entire p2p model is.
ezdiy: in
that sense, pools are useful
they shield individual miners from direct attacks
ezdiy: (btw, p2pool is suspected
to have high stale rate because you can
tie individual miners/hashpower
to certain ips)
ezdiy: of course it's false sense of security, just ddos all
the pools commonly used lol
ezdiy: most miners have it setup
to switch pools when one is down
ezdiy: short ddoses go unnoticed often
though
ezdiy: yeah,
that'd confirm my speculation
ezdiy: (i highly doubt its was just an innocent coincidence, as
the chances are <1% of block gap occuring so conveniently)
ezdiy: whatya do
to create price wave
to ride it? :)
ezdiy: jurov: until its accepted in
the block by 0.8.1 miner
jurov: and people who use 0.8.2 from git see
the
tx rejected
ezdiy: look at blockchain info,
there was *over a hour* gap between blocks
jurov: yes blockhain.info shows
these
two most recent
ezdiy: mircea_popescu: yeah,
there was a hour-or-so gap