< LucasMZanella_>
The only attack I can think of is someone 'mining' a transaction until its txid has the same first digits as another. However there's a minimum number of digits that we can choose that would guarantee a million year of brute forcing
< goatpig>
not with segwit
< sipa>
LucasMZanella_: you'd need at least 128 bits
< LucasMZanella_>
What is different with segwit?
< sipa>
otherwise the security of referencing old transactions would be below that of the digital signatures
< goatpig>
the outpoint is taking the wtxid instead of the txid
< sipa>
so you can probabbly save 16 bytes per txin
< goatpig>
the wtxid has no sig in it
< LucasMZanella_>
128 bits is already good, isn't it?
< goatpig>
therefor it's easy to "mine" a collision
< sipa>
goatpig: no, txid
< goatpig>
hmm am i getting confused here?
< sipa>
yes
< sipa>
wtxid = inclides witness, txid = no witness
< goatpig>
oh ok
< goatpig>
well anyways
< sipa>
it's also irrelevant in this discussion
< goatpig>
sw refers to outpoints by the unmalleable id
< goatpig>
well it's entirely easier to produce collision the txid than the wtxid
< goatpig>
but sure, that's orhtogonal
< sipa>
LucasMZanella_: yes, perhaps. it's not worth the effort to change it though
< goatpig>
you could construct attacks where you force tons of unnecessary hashing per tx
< sipa>
no
< sipa>
hmm, nevermind
< sipa>
you need collision resistance
< sipa>
goatpig: you're right
< goatpig>
yeah which has you increase the size of your hash "shortcuts" and kills the size benefit anyways
< sipa>
LucasMZanella_: disregard what i said; you really need 256-bit hashes in transactions
< goatpig>
while increasing the cost size of low input tx
< LucasMZanella_>
How much hashes we need to get a sha256 output to begin with 7 chosen digits?
< goatpig>
look at miners
< sipa>
LucasMZanella_: for a collision attack you only need half
< LucasMZanella_>
Half of what?
< sipa>
the attacker may be the one doing the reference, which can refer to a transaction that he did a grinsing on before publishing
< goatpig>
birthday attack
< goatpig>
well basically you'd mine lots of tx with the starting 7 bytes in the txid
< goatpig>
then create one tx spending like 1000 inputs
< goatpig>
however many you get
< goatpig>
and use the the first input as your collided hash
< goatpig>
forcing tons of hashing for no reason
< sipa>
goatpig: it's far worse
< goatpig>
then to reproduce the attack
< sipa>
you can create a consensus failure
< goatpig>
ive thought of that but cant come with an example of that attack on the top of my head
< sipa>
by creating two transactions with the same starting bits
< sipa>
and then spending it
< sipa>
making sure one is valid and the other is invalid
< goatpig>
you mean while unconfirmed?
< sipa>
hmm, but the chain provides an ordering of course
< goatpig>
his proposal is to basically attach a merkle root in there
< goatpig>
with the "shortcuts"
< goatpig>
i tihnk that's enough to remain deterministic, therefor avoid consensus failures
< goatpig>
but it's easily attackable
< sipa>
fair, it's doable in a way that does not cause consensus failure
< goatpig>
but there's also the cost of increasing the size of low input tx
< goatpig>
i guess you could "modulate" this, have tx version that uses this proposal to cut on large tx
< goatpig>
but even then, taht does not reduce the attack vector
< sipa>
it's also a terrible hard fork
< goatpig>
couldnt you softfork that ala segwit?
< sipa>
(as in: not just miners and nodes, but every piece of software will fail without modification)
< sipa>
no
< LucasMZanella_>
Could be a soft one
< goatpig>
i guess you can't pull the segwit trick twice
< sipa>
segwit didn't remove any existing structures
< sipa>
it just added an optional new ones
< sipa>
truncating txids is not something that fits into that
< goatpig>
no but (correct me if im wrong) to a not update node, the marker and flag of a segwit tx makes the tx body invisible to the node
< sipa>
you can't remove the txids without breaking things
< LucasMZanella_>
Transactions could maintain the structure, but the txid being referenced would be the merkle root. And the 7 digits each would be added inside script
< sipa>
goatpig: that's just serialization
< goatpig>
at any rate i wouldnt want that kind of change done without a hf
< sipa>
i'm not even talking about that
< goatpig>
sipa: if you can make the content of the tx invisible to older nodes, you can shove anything you want in there basically
< sipa>
then you don't have any transactions left
< sipa>
sure, you can move everything to an extension block
< sipa>
that's always possible
< sipa>
but that doesn't share anything anymore with existing nodes
< sipa>
they wouldn't even see the transactions of the new system anymore
< LucasMZanella_>
Yeah, the old nodes would invalidate the transaction because txid is nonsense
< goatpig>
sipa: a bit too aggressive i guess =D
< sipa>
LucasMZanella_: what is the objective?
< goatpig>
optimize block space usage im guessing
< sipa>
if it's just bandwidth/storage, a new serialization for transaction could be constructed that does what you're saying (and more)
< sipa>
but without actually modifying the transactions
< sipa>
only changing how they're stored
< sipa>
which means that the full txids still count towards the weight limit
< LucasMZanella_>
Objective of what? The idea was to be able to spend from lots of txs without having to add one signature + one txid for each. My idea would reduce txid usage in transactions, and schnoor would reduce signature usage
< sipa>
but still reclaim disk space and bandwidth
< sipa>
in a completely optional and compatible way
< goatpig>
in taht spirit, could there be an alley to use block height + tx# instead of hash for old, buried outputs in the future?
< sipa>
monero uses a pretty extreme version of what you're suggesting iirc; they refer to previous outputs just using the position in the chain when they were created
< sipa>
goatpig: requires a nasty index, unfortunately
< sipa>
but yes
< goatpig>
sipa: index for what purpose? ordering tx per block height? i mean you konw that height won't change if we're talkign blocks with 100k+ confs
< LucasMZanella_>
If you use new addresses everytime someone is going to send you something, then moving a large quantity of your funds is going to take a lot of txids and signatures. Schnoor already condenses signs, my idea was to condense txids
< LucasMZanella_>
I thought this could be done with a soft fork but now I don't know anymore. I guess old nodes would always miss transactions
< LucasMZanella_>
as you said :)
< goatpig>
LucasMZanella_: you'd have to make the tx body invisible to old nodes
< goatpig>
that's too extreme
< LucasMZanella_>
I thought as using an entire txid and add the merkle root + other txids inside the script, but old nodes would not accept txids inside the script
< LucasMZanella_>
I guess it can only be done with a hardfork by changing the transaction format version
< goatpig>
whichever way you do it, you are introducing computational overhead that is exploitable
< LucasMZanella_>
Yes, but we could make the required n digits vary according to the block difficulty
< LucasMZanella_>
If a person is able to exploit the n digits then he would be able to mine 51% or something like that
< goatpig>
sure but you to consider that it would then proportionally increase the size of tx with less inputs
< goatpig>
cause you are always carrying at least 32 bytes worth of merkle + compressed ids
< LucasMZanella_>
Why it would increase?
< goatpig>
in your current proposal
< goatpig>
a single input tx is already larger
< goatpig>
cause it needs a merkle + 7bytes for 1 compressed id
< LucasMZanella_>
The merkle root would substitute the txid at all in the new transaction format
< LucasMZanella_>
If there is only one input, the merkle root would match the txid being referenced
< goatpig>
you need an id per output + the merkle
< goatpig>
yes but as soon as you hit over 128bits compressed ids
< goatpig>
now 2 inputs tx are larger than the legacy outpoints
< LucasMZanella_>
Can't follow your thinking, I'm confused
< goatpig>
you need the merkle root per tx
< goatpig>
+ 1 id per input
< goatpig>
if your ids are 129bits
< goatpig>
your 2 input tx is now 258bits of outpoints + 256bit of merkle
< goatpig>
currently a 2 inputs is 256x2 bits of outpoints
< goatpig>
not including the outpoint id in there cause it's constant accross models
< LucasMZanella_>
Then for that case the person could use the old transaction format
< goatpig>
now you have discussion of whether that's desirable at all
< goatpig>
having 2 models that overlap
< LucasMZanella_>
Wouldn't the model be inneficient just for 2 inputs?
< goatpig>
it would be inneficient generally for low input tx
< goatpig>
but there's a debate to be had
< LucasMZanella_>
I don't think there's a problem in using 2 different transaction formats
< goatpig>
of how desirable such a massive change (hf and all) is when you compare the complexity to implement and operate vs the benefit
< goatpig>
i have not thought about whether that is a problem or not
< goatpig>
but i'd rather err on the side of caution and not introduce complexity
< LucasMZanella_>
Yes, but if we're going to ever hard fork for some other reason, this could be included
< LucasMZanella_>
I agree with you, but the benefits are huge. Coinjoin, being able to still use one address per transaction, and less fees (the greatest problem)
< goatpig>
if it can demonstrated that it is safe
< goatpig>
and fees arent a problem that needs to be addressed at consensus level
< goatpig>
if they are a problem at all (i dont believe they are)