253700+ entries in 0.106s
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.
mircea_popescu: the bitcoind node makes sure it did what it pleased within bounds, and off it goes.
mircea_popescu: the bitcoind node keeps a db, the bitcoind wallet selects what it wants and does what it pleases.
mircea_popescu: <kakobrekla> first runs on airgap, second on my server in dc and third on my desktop << seems txn are logically created on 1.
mircea_popescu: if you know that block 2 is verified, and you know that 1testadress1 is the 1testaddress1, what more do you need to check ?
mircea_popescu: so you see this 0 conf tx that's being proposed references an input in block 2. which you have and you verify and that's that.
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
mircea_popescu: jurov i thought we were discussing bitcoin as a spec, rather than bitcoin as a hack.
mircea_popescu: you can, for the sake of being silly, talk of "transactions included in valud blocks" but it really doens';t mean anythinmg. a block is a block.
mircea_popescu: there's no such thing as "a valid transaction". merely, a valid block.
mircea_popescu: maybe these other words work better : "transactions" is a useful notion when adding data to blocks. it is in no way useful, or even existent, when verifying anything. all you can verify, both the most and the least you can verify, are BLOCKS.
mircea_popescu: you can't have a valid txn in an otherwise invalid block.
mircea_popescu: ben_vulpes it needs to retrieve arbitrary blocks. why txn specifically ?
mircea_popescu doesn't understand why this is contentious and will re-read.
mircea_popescu: by looking at their inputs, an the inputs for those inputs, all the way to the valid coinbases involved.
mircea_popescu: if you check you check. if you don't check, then don't check.
mircea_popescu: and i don't give a shit how convenient it is. let userland cut down the correct implementation for the sake of convenience.
mircea_popescu: ben_vulpes once a transaction is proposed, the software has two options. 1) "oh , this looks like a tx involving inputs i remember were valid" and 2) "these are the inputs. check. these are their sources. check. these are their sources. check. this is the coinbase. check. ok."
mircea_popescu: <mircea_popescu> bitcoind should broadcast verifiable txn submitted to it. <<
mircea_popescu: like linux. i don't have to get a new version of lindows to get rid of fucking notepad
mircea_popescu: modular fucking design, so you doin't have to change the whole thing every time a part sucks [for your usecase]
mircea_popescu: bitcoind should broadcast verifiable txn submitted to it.