sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
chjj has quit [Ping timeout: 255 seconds]
Aranjedeath has quit [Ping timeout: 246 seconds]
CheckDavid has quit [Quit: Connection closed for inactivity]
daszorz has quit [Read error: Connection reset by peer]
rmwb has quit [Ping timeout: 240 seconds]
JackH has joined #bitcoin-wizards
Jaamg has quit [Ping timeout: 268 seconds]
Jaamg has joined #bitcoin-wizards
daszorz has joined #bitcoin-wizards
jrayhawk has quit [Ping timeout: 268 seconds]
jrayhawk has joined #bitcoin-wizards
comboy_ has quit [Read error: Connection reset by peer]
Guyver2 has joined #bitcoin-wizards
comboy has joined #bitcoin-wizards
tiagotrs has joined #bitcoin-wizards
rmwb has joined #bitcoin-wizards
negatratoron has quit [Ping timeout: 246 seconds]
Aaronvan_ has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 255 seconds]
Aaronvan_ has quit []
rmwb has quit [Ping timeout: 255 seconds]
AaronvanW has joined #bitcoin-wizards
Aaronvan_ has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 240 seconds]
berndj has quit [Ping timeout: 255 seconds]
berndj has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 260 seconds]
itsme_ has joined #bitcoin-wizards
arubi has quit [Ping timeout: 248 seconds]
deusexbeer has quit [Remote host closed the connection]
deusexbeer has joined #bitcoin-wizards
arubi has joined #bitcoin-wizards
rmwb has joined #bitcoin-wizards
Aaronvan_ is now known as AaronvanW
Aaronvan_ has joined #bitcoin-wizards
Aaronvan_ is now known as AaronvanW_
AaronvanW has quit [Ping timeout: 268 seconds]
<stevenroose>
Can a coinbase transaction have multiple inputs?
<sipa>
no
<stevenroose>
sipa: just for my understanding, is there a reason why it couldn't have more than one? or is it just because the consensus enforced that from the start?
AaronvanW_ is now known as AaronvanW
<gmaxwell>
it could have been.
<sipa>
well, depending on what definition you use, they may have 0 inputs
<gmaxwell>
If it were up to me I would change it to allow inputs in any hardfork.
<sipa>
they have a coinbase input
<gmaxwell>
and allow them to spend other coinbase outputs without maturity limits.
<sipa>
stevenroose: do you mean supporting multiple dummy inputs (like the one now), or 1 dummy input and multiple normal ones?
<stevenroose>
1 coinbase input (like outpoint 0x00) and other normal ones
<sipa>
yes, i think that would have been reasonable
<stevenroose>
I'm sure it's been thought about, but an easy way to fight spam attacks is to delay fee payout to the next block (or some blocks) by a soft fork change that requires the fee amount to be spent to a dummy output that can only be spent in the next block's coinbase input f.e.
<stevenroose>
that could break some parts of the incentivation mechanism for fees though
<stevenroose>
f.e. if there is a race between a low-fee immediately spendable tx and a higher-fee tx locktimed in some blocks
<stevenroose>
if you don't claim the fee for yourself, it might be better to not include the immediately spendable one
BashCo_ has joined #bitcoin-wizards
<stevenroose>
could break lightning channel closing txs I think if a locktimed tx with a higher fee can reasonable win the race against an immediately spendable normal fee tx
<stevenroose>
anyways, thanks
BashCo has quit [Ping timeout: 260 seconds]
rmwb has quit [Ping timeout: 240 seconds]
tiagotrs has quit [Ping timeout: 268 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
CheckDavid has quit [Quit: Connection closed for inactivity]
<betawaffle>
hmm, gmaxwell, why drop the maturity limits?
<stevenroose>
betawaffle: because I guess the new outputs they create will have a fresh maturity limit which is longer..
<betawaffle>
oh, right
<stevenroose>
it would allow for schemes like I described where some coinbase outputs are only supposed to be spent by other coinbase txs
<sipa>
it effectively creates two classes of money; a general purpose one which is available everywhere, and an immature class which can only be spent and created by coinbases
<betawaffle>
hard, you beat me to tfhe...
<betawaffle>
s/hard/damn/
<sipa>
it enables things like pay forward schemes where not all the subsidy goes to the first miner
<stevenroose>
^^
<betawaffle>
how does a coinbase output get proved to an SPV client?
<betawaffle>
does it need the whole block?
<sipa>
what property of it gets proved
<betawaffle>
the value
<stevenroose>
the inclusion proof is exactly the same
<sipa>
betawaffle: you just show the tx
<sipa>
the amounts are in the outputs
<betawaffle>
ok, so SPV doesn't normally get a "value" proof, just an inclusion proof?
<sipa>
yes
<sipa>
spv clients don't have a utxo set
<sipa>
you can't prove unspentness
<betawaffle>
what would an attacker need to do to defraud an SPV wallet?
<sipa>
mine an invalid tx into a block
<stevenroose>
a value proof is hard. I mean for a normal tx you could also prove the existence of the inputs, which will have more work than the tx being proven, but without a proof that it's not spent before, it makes no sense
<betawaffle>
just one block, right?
<sipa>
yes
<stevenroose>
betawaffle: depends on the trust level of the SPV wallet, no?
<Chris_Stewart_5>
betawaffle: an example of sipa's attack is having two coinbase txs in a block
<betawaffle>
i can't figure out how people trust SPV
<stevenroose>
some SPV clients could also wait for a second block
<sipa>
betawaffle: s/SPV/miners/
<betawaffle>
:)
<sipa>
SPV is a process
<stevenroose>
if you provide inclusion proof in block plus 5 more blocks with sufficient work that chain from that block, you have a pretty decent proof
<sipa>
the trust it relies upon is that miners don't mine invalid blocks
adlai has quit [Ping timeout: 240 seconds]
<betawaffle>
for a miner to defraud an SPV wallet, would the wallet need to be pulling directly from the miner?
<betawaffle>
(or network of nodes the miner controls)
<sipa>
yes
<sipa>
though that's kinda trivial
<stevenroose>
or that it is economically unfeasable to create a fork of X blocks just to defraud you
adlai has joined #bitcoin-wizards
MaxSan has joined #bitcoin-wizards
<stevenroose>
sipa: are SPV clients traditionally aware of the longest chain?
<betawaffle>
sipa: for people who already trust miners (via SPV), would they not get more security from a pruned full node snapshot (from a trustworthy source)?
<sipa>
betawaffle: if they're fine with the resource costs of running a full node, sure
<betawaffle>
or would it still be hard for them to discover fraud in that snapshot?
<sipa>
betawaffle: and only going forward
<sipa>
you can't verify a utxo snapshot without seeing all of history that lead up to it
<sipa>
(in MW you can, though!)
<stevenroose>
if an SPV client is totally unaware of the longest chain, when the network is at block 100k and the client is receiving a transaction from an utxo in block 1000, the difficulty at that time could would allow a miner to cheaply create 1001' to 1006' where they double spend the utxo and send that as a proof
<betawaffle>
sure, but would it not be possible to eventually see discrepancies with future blocks?
<sipa>
betawaffle: no
<betawaffle>
you'd just fork off the network, right?
<sipa>
indeed
<sipa>
the UTXO set you have stored is fully trusted
<sipa>
if someome were to be able to give you an arbitrary snapshot, they can make you believe anything
<betawaffle>
is there any computation someone can do on the blockchain history to prove the validity of the UTXO set without the proof being larger than the blockchain history?
<sipa>
define validity
<stevenroose>
betawaffle: "without the prove being *larger* than the blockchain history", yes: the blockchain history ;)
<sipa>
if your question is "could this utxo set reasonably have been the result of some blockchain", the answer is yes
<betawaffle>
well, that a fully validating node wouldn't ever disagree with the proof
<kanzure>
"without the proof being larger than the blockchain history?" snarks
<sipa>
if your question is "is this utxo set the result of a specific blockchain which i have not seen?" obviously no
MaxSan has quit [Ping timeout: 240 seconds]
<betawaffle>
what if you have a trusted block header?
<sipa>
if your question is "is this utxo set the result of a blockchain history for which i know the headers"... yes, with moon math and infeasibly much computation
<sipa>
MW gives you UTXO correctness proofs that scale linearly with the utxo set size + tx count
<sipa>
but are smallee than the entirety of history
<kanzure>
"trusted block header" that's cheating.
<sipa>
kanzure: not at all
<sipa>
kanzure: the question is dumb without it wven
<betawaffle>
sorry for asking dumb questions :D
<sipa>
you can't expect me to prove to you that X is the UTXO set of a chain that you know nothing about
MaxSan has joined #bitcoin-wizards
<betawaffle>
of course not
<sipa>
or rather, that's trivial
<sipa>
check whethee the sum of the amounts does not exceed 21M
<sipa>
done.
<sipa>
your utxo set is valid, congrats
<sipa>
the question you want to ask whether it corresponds to a chain you already know about
<sipa>
which implies having a trusted header
<betawaffle>
yeah, that's what i meant to ask...
<betawaffle>
if you trust a given header, it's infeasible to create an alternate list of past headers, correct?
<sipa>
yes
<betawaffle>
so a trusted header can be turned into a trusted header history, obviously
<stevenroose>
by providing the whole history
<betawaffle>
yep
<stevenroose>
but that's exactly what a full node does, though. the trust of the header comes from the amount of work in that case
<betawaffle>
stevenroose: no, a full node actually validates from the start
<betawaffle>
it doesn't trust any header except i guess the genesis block
<stevenroose>
ok true, my mistake
<stevenroose>
that's what some full nodes do up to the latest checkpoint
<betawaffle>
but of course... if you trust a header, you don't *need* to validate the past transactions. you'd only need to do that if you don't trust the header :/
<sipa>
hmm
<sipa>
we're conflating two things
MaxSan has quit [Ping timeout: 240 seconds]
<sipa>
even a full node makes the assumptiom that it is able to *learn* about the best chain
<sipa>
you clearly cannot prove to someone what the best chain is, as it relies on unobservable information
<stevenroose>
true. hence, "trusted" header. which is normally not something you have
<sipa>
so i think the question should be: can a node ask for a UTXO set and compact correctness proof for it, corresponding to a known best block hash X
<sipa>
and i'm pretty sure the answer in bitcoin is no, except using moon math
<JackH>
only relying on the longest chain has a few negative sides to it
<betawaffle>
ok, so back to the UTXO set... would proof of inclusion for all unspent transactions prove that the utxo set is valid? (given a trusted header)
<sipa>
no
<betawaffle>
or would those proofs of inclusion be as large or larger than the blockchain
<betawaffle>
ok
<betawaffle>
what are the downsides to MW?
<sipa>
it's not compatible with bitcoin
<betawaffle>
(btw, please feel free to tell me to shut up if my questions are annoying you)
<andytoshi>
it also has much more exposure to EC math and does not support any explicit scripting (though this is seeming less like a disadvantage recently)
<andytoshi>
and it comes with CT, which has a size/verification cost
<sipa>
oh, yes
<sipa>
i tend to forget those :)
<sipa>
betawaffle: assume i give you an inclusion proof for every utxo's transaction
* betawaffle
assumes
<sipa>
betawaffle: you don't know anything about the signature validity of every tx that does not have an unspent output
laurentmt has joined #bitcoin-wizards
<sipa>
so even if it would prove that that is indeed the UTXO set corresponding to that chain, it does not prove that the chain is valid
<betawaffle>
correct
<betawaffle>
but if you do actually trust the header... would that not be enough to follow said chain?
<sipa>
if you actually do trust the header, you should want a utxo commitment :)
<betawaffle>
yeah, a utxo commitment would be nice, of course
<sipa>
one question is whether you should trust a utxo commitment without seeing history
<sipa>
because if you have seen history, you can just remember the utxo hash - no need for a commitment even
<betawaffle>
sipa: i'm just trying to understand if anything can be done to improve the safety of people running SPV wallets in times of a fork like this
laurentmt has quit [Client Quit]
<betawaffle>
people who just can't accept running a full-history-validating node
<betawaffle>
i'm not worried about *myself* because i run a full node, it isn't too expensive for me