253600+ entries in 0.058s
mircea_popescu: best have ppl that spoeak the language tlel you what the paper says.
mircea_popescu: asciilifeform the reason, incidentally, i didn';t read it myself is i dun trust my rudimentary c understanding.
mircea_popescu: nah, ben_vulpes only scammed participant. neglected to send 2.x ended up sending 8.x
mircea_popescu: nah, just, i know what qs to ask of people. "go read it and i'll ask you things"
mircea_popescu: asciilifeform you're in teh list arentcha ? he asked me specifically to confirm. you're also confirmed!
mircea_popescu: i suppose it is a testament to my scholarship that i can actually get away with outsourcing the actual readsing ?
mircea_popescu: how about the production of communications to include voice << im not sure right off what that'd do.
mircea_popescu: <mats> mircea_popescu: are you interested in loosening the requirements? << perhaps. do you see meaningful expansions ?
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!
mircea_popescu: <buttonwood_> I've been really interested in applying the smart contract technology to bitcoin-otc. Are there currently any active smart contracts or oracles doing escrow trading on bitcoin irc ? << no. people do thje trust calculation by hand.
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: maybe the reason we've talked so long about this is because we're saying the same thing/
mircea_popescu: you can't have "these are the valid and these are the invalid txn of block 6"
mircea_popescu: but once in a block, all you can have is a confirmed block.
mircea_popescu: see ? that's the whole thing. that these two are separate.
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.
mircea_popescu: 1 btc from block 5, 1.5 btc also from block 5, 2 btc from block 6 -> 4.5 btc to 1derp
mircea_popescu: but if they are different outputs, included in variuous blocks... they're verifiable by those blocks... ?
mircea_popescu: <jurov> now you do withdrawal, you need to gather and sign all of them despite it's the same 1Fx address << it's whjat i took this to introduce.
mircea_popescu: jurov weren't you proposing that *somehow* there's ambiguous outputs as the entire point of what you were saying ?
mircea_popescu: <mircea_popescu> once you sign out of an output, it's out. < o.O
mircea_popescu: ben_vulpes nah. im just saying, if it's ambiguous, then it's ambiguous.
mircea_popescu: ben_vulpes is this "bitcoin as it should be" or "bitcoin as it is to be inferred from current codebase"
mircea_popescu: <mircea_popescu> jurov i thought we were discussing bitcoin as a spec, rather than bitcoin as a hack. <<
mircea_popescu: now, which btc is spent through this process is not established by you.
mircea_popescu: jurov let's take the following case : on march 15th, 1jurovaddress gets 1 btc. on march 20th, 1jurovaddress gets 1 btc.
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"
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'
mircea_popescu: note that the way proposed above allows one to still verify the whole damned chain from block 1 onwards.
mircea_popescu: i think we mgiht be. will have to re-re-read this sometime that's not saturday night in between cabaret and strip club.
mircea_popescu: jurov not more than in the sense of knowing which blocks they were in
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.
mircea_popescu: currently proposed transactions are verified on the basis of historically accepted blocks, not on tyhe basis of historically accepted transactions.
mircea_popescu: just because that's what you do now doesn't imply it's what you must do.
mircea_popescu: there's no such thing as "veryinfing a transaction that was already included"
mircea_popescu: again : all you can verify, both the most and the least you can verify, are BLOCKS.
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: "oh look, 3 is based on 2 which we just approved, include it too"
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: they can "prepare" your tx, but for my formalism, it ios "created" once 1.
mircea_popescu: you can't have the 3rd higher in the tree than the 2nd
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.
mircea_popescu: i don't follow. use the formalism in the model, that's why it's there.