188700+ entries in 1.34s
ben_vulpes: they're already cut loose. can't get into b-
a mircea_popescu: these guys "delisted" at
a 25% buyback that they didn't really honor
pete_dushenski: mircea_popescu: i've met mitch callahan
a couple times irl
mircea_popescu: CAVirtex, Canada’s largest and oldest Bitcoin online exchange, is facing
a potential class action lawsuit to the tune of $884,880 CAD. The alleged losses were incurred by the lawsuit-bringers after the company offered 10% of its shares for sale on the cryptocurrency-based asset exchange, Havelock Investments then stopped listing the stock by the end of 2013.
ben_vulpes: the one who did
a runner with
a Havelock "raise"
ben_vulpes: perhaps
a lonely registered participant?
ben_vulpes: i discovered recently that "baby" carrots aren't so much "lathed" as they are knocked around in
a conical abrasive vessel
mircea_popescu:
a codebase that's written by
a monkey is more liable to attact "do-ocracy" monkeys than one written by
a sane person.
mircea_popescu: you can, if you wish, implement
a function that returns "equibranches" on
a tree.
mircea_popescu: ben_vulpes no asciilifeform put it in proper terms. it's
a tree.
ben_vulpes: then this implies
a requirement that
a bitcoind-node know about and be able to return data about the various chains of which it knows.
mircea_popescu: like sending you to hunt for snipes so yo ucan't be
a huner)
mircea_popescu: (another bit of braindamage th epower rangers forced upon the world, other than "historical transaction validity" as
a thing, is "block as aheight"
ben_vulpes: f'r instance, the thing should cough up on the command line,
a block if given
a hash
ben_vulpes: - return
a block corresponding to
a given hash
ben_vulpes: too bad i'm too bad of
a scammer to pull it off
mircea_popescu: i suppose it is
a testament to my scholarship that i can actually get away with outsourcing the actual readsing ?
assbot: Why Dogecoin is
a scam, why the people pushing it are assholes, why Business Insider is
a contemptible piece of shit, why anyone who ever worked for it will be dancing in the street for nickels and why Kevin Rose is
a fuckwit. Plus other considerations. pe Trilema - Un blog de Mircea Popescu. ... (
http://bit.ly/1uKxtRQ )
mats: i was hoping you'd have
a better idea tbh.
mats: perhaps. do you see meaningful expansions ? << how about the production of communications to include voice, where there is
a written record of it? e.g. transcript of wiretap log
decimation: at the present time, it seems to me that bitcoin derivatives do not serve
a real market need
mircea_popescu: buttonwood_> There has to be
a better way to do otc trades tho. << nope. isn't, for provable reason. isn't happening in practice, either.
mircea_popescu: <mats> multi sig and escrow are essentially bad patches to
a broken trust model << mats is like the oracle on the topic now!
mats: i figured i'd give it
a shot before proceeding, i've put at least 400 hours in already and i believe there may not be quite
a lot of useful data at the end if i continue this way
Pierre_Rochard: ^ exactly, the difference between
a computer oracle and
a human arbitrator approaches nil over time
ben_vulpes: buttonwood_: ^^ that bet right there is
a good example of best-in-class contracts.
ben_vulpes: there was an options exchange for
a while, buttonwood_.
mats: 21:15:50 <+mats> multi sig and escrow are essentially bad patches to
a broken trust model << in the way you mean to use it, that is
ben_vulpes: you're clearly in
a good position to be talking about how business should be done around here.
mats: offloading due diligence and trying to use technology as
a crutch to paper over deficiencies in your business relationship sounds suspiciously like the old world way of doing things
mats: multi sig and escrow are essentially bad patches to
a broken trust model
mats: look, you can't offload the complex business of trust to anything but
a human.
mats: all extant projects purporting to be 'smart contract technology' is
a scam. like ethereum.
mats: its not
a real thing, buttonwood_.
decimation: there's
a semi-anonymous column there by the same name?
mircea_popescu: what's being verified is
a) control of the address in question and b) bitcoin feeding it included in
a block.
mircea_popescu:
A. Here's proof i control address X, and here's
a payment of 500 btc to it *included in block Y*
mircea_popescu: but once in
a block, all you can have is
a confirmed block.
mircea_popescu: the reason ytou know block 5 is
a valid block IS that they were valid outputs, or was at the time, but this is
a separate topic.
mircea_popescu: but the reason you know they're valid outputs is that block 5 is
a valid block.
jurov: and no miner ever has
a say in which ones
jurov: makes
a withdrawal out of them
ben_vulpes: much like if you want
a > 1m transaction that's your problem
ben_vulpes: but you're saying that if i cook up
a transaction that has 1march29th as an input, the miners should actually rewrite that to use 1march15th as an input?
jurov: well mircea, then make
a spec. many people unsuccessfully tried various mixing proposals that were supposed to do what you propose
mircea_popescu: <mircea_popescu> jurov i thought we were discussing bitcoin as
a spec, rather than bitcoin as
a hack. <<
mircea_popescu: there's
a degenerate case where you gift it to miners, but otherwise...
mircea_popescu: if this isn't proof that
a transaction once included loses its identity i have no idea what would.
mircea_popescu: kakobrekla let me put it another way : the miner output of
a block is actually defined by the code as "everything left over once you substract the sum output from the sum input"
ben_vulpes: do bitcoind-node and bitcoind-wallet share
a db?
mircea_popescu: in general, we';re not against anything power rangers CLAIM to want to do. it's just that
a) thjey never actually do it and b) always break other things 'attempting'
decimation: so, if one 'submits'
a chain of 1000 transactions, attached to only one tx output, one can imagine that they might not verify all in the same block, depending on the mempool logic
mircea_popescu: ben_vulpes all that needs to be done is verify that
a tx input matches
a previously included output, and that the block was valid.
ben_vulpes: ah ah but check that
a transaction is in
a block
ben_vulpes: all that must be done is check that
a tx input comes from
a previous block.
mircea_popescu: there's no such thing as "veryinfing
a transaction that was already included"
jurov: you seem to imagine they got poured into the blocks as scraps of gold into
a solid brick
mircea_popescu: they are only
a thing while in mempool. but once they're in the block, they melt away.
mircea_popescu: they do not. transactions once included are no longer
a thing.
mircea_popescu: jurov so basdically you're talking of
a degenerate case of my model, which sure, as
a convenience can be implemented by my model as well.
mircea_popescu: well... you can't have any btc to spend if you don;t have any btc to spend. that specifically means,
a derivaiton of
a coinbase, in
a block.
assbot: Logged on 25-01-2015 00:53:08; mircea_popescu: let me model this for
a moment.
mircea_popescu: the bitcoind node keeps
a db, the bitcoind wallet selects what it wants and does what it pleases.
ben_vulpes: the bitcoind *node* doesn't give
a whit about transaction creation
ben_vulpes: you're proposing
a new "wallet" that knows how to create transactions.
ben_vulpes: i guess
a step backwards is in order first
mircea_popescu: well the block 3 tx i named as "proposed" is
a 0 conf.
mircea_popescu: we see in block 3
a tx that proposes to take 10 btc from 1testaddress1 to 1 testaddress2. you propose we can't verify what ?
mircea_popescu: in block 2,
a tx takes 20 btc from 1block1coinbase to 1testaddress1 ; 50 btc > 1block2coinbase
ben_vulpes: jurov:
a transaction in
a block contains the public key iirc