549000+ entries in 0.308s
mircea_popescu: now, which btc is spent
through
this process is not established by you.
jurov: yes, hence
the various horrible database
turds
mircea_popescu: jurov let's
take
the following case : on march 15th, 1jurovaddress gets 1 btc. on march 20th, 1jurovaddress gets 1 btc.
ben_vulpes: so
they actually
troll
through
the whole blockchain
jurov: to check
the signatures
jurov: everyone who wants
to check
the withdraawal is valid, needs
to gether
them all
too
jurov: that's fine,
that's up
to wallet
jurov: now you do withdrawal, you need
to gather and sign all of
them despite it's
the same 1Fx address
jurov: maybe last
try: let's have deposits
to mpex sprinkled in various blocks,
they are unspent outputs
mircea_popescu: there's a degenerate case where you gift it
to miners, but otherwise...
jurov: ofc when it is fully spend,
then you won't have
to do anymore
jurov: if you need
to keep
track in which block it is,
then it does have identity
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.
kakobrekla: if
transaction bloodline is bs, why are we against bc shelling/pruning
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: i
think we mgiht be. will have
to re-re-read
this sometime
that's not saturday night in between cabaret and strip club.
jurov: okay,
then we're on
the same page
mircea_popescu: jurov not more
than in
the sense of knowing which blocks
they were in
jurov: for
that you want
to have
the outputs indexed somewhere
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
jurov: can it be done without doing
the individual signatures?
ben_vulpes: all
that must be done is check
that a
tx input comes from a previous block.
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.
jurov: so
to verify if you mus pull
the scraps out
mircea_popescu: there's no such
thing as "veryinfing a
transaction
that was already included"
jurov: because any new
transaction explicitly names each idividual scrap
mircea_popescu: again : all you can verify, both
the most and
the least you can verify, are BLOCKS.
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.
decimation: so
to be clear - before block 3 is verified, 1testaddress1 sends 20 btc
to 1testaddress2, and 1testaddress2 sends 20 btc
to 1testaddress3? Is
that
the issue?
mircea_popescu: they do not.
transactions once included are no longer a
thing.
jurov: no i'm
trying
to explain
transactions maintain
their identity in blocks
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.
kakobrekla: seems
txn are logically created on 1. < afaik you can do it on 3 and just sign on 1
mircea_popescu: you can't have
the 3rd higher in
the
tree
than
the 2nd
jurov: but as 0conf
transaction can be checked against other 0conf
transactions (remmeber satoshidice?)
decimation: before block 3 is published, 1testaddress2 sends
to 1testaddress3 (both 0 verify)?
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.
jurov: but against individual outputs
that it spends.
assbot: Logged on 25-01-2015 00:53:08; mircea_popescu: let me model
this for a moment.
jurov: you singlehandedly rejected
the wiki link so you know better?
jurov: mircea_popescu: pls closer describe your idea of checking
the
transaction. maybe
there lies
the problem
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.
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.
ben_vulpes: if i'm reading correctly, you propose moving
transaction creation *out* of bitcoind.
ben_vulpes: which is
the
transaction creation process.
jurov: you must exactly name all
these 10 inputs!
jurov: thwen wehn you want
to spend it
jurov: you can send 10
times something
to an address
ben_vulpes: if i can interrupt, i'm coming at
this problem from an entirely different angle.
jurov: because addresses aren't
the atomic units
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 ?
jurov: and if you don't have
tx index,
that means getting whole blocks
jurov: you need
to find and extract
the specific inputs used and check
the public keys
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.
jurov: but i'm
talking about 0conf
transactions
jurov: if it's laready mined,
then someone else verified it
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
jurov: that's what i'm asking, if you don't care it won't check relayed
transactions?
jurov: how else you 'll be cerain it's
the same utxo
that baked in
the block?
ben_vulpes: jurov: a
transaction in a block contains
the public key iirc
jurov: having whole block wont help you, you need
the utxo public key
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.
ben_vulpes: i guess
this implies maintaining an index of
txn hashes -> block hashes for lookup and validity checking
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.
jurov: you said it's
the user's job
to
ben_vulpes: so
then
the
thing *does* need
to retrieve arbitrary
transactions.
mircea_popescu: by looking at
their inputs, an
the inputs for
those inputs, all
the way
to
the valid coinbases involved.