< medo> hi i want to be miner
< medo> ??
< Randolf> medo: You should ask in the #bitcoin channel then.
< medo> yes
< medo> can you help me to be a miner please
< medo> !!
< gribble> Error: "!" is not a valid command.
< medo> ?
< Randolf> medo: The topic you're raising is off-topic here. Please ask in the #bitcoin channel instead.
< goatpig> the multi byte op pushdata, are they big or little endian?
< achow101> goatpig: little endian
< goatpig> figured it out, thanks
< akash_> i am expert in giving suggestion how to stop frauds in bitcoin transaction
< ZiNC> Hi.
< ZiNC> Are there debug symbols available for download?
< Anant> help
< Anant> how to exchange bitcoin with other coins?
< Anant> earn exchange fees?
< sipa> Anant: #bitcoin
< LucasMZanella_> Why we must reference the entire txid on a transaction? Could somebody give a feedback on this idea of mine? https://bitcoin.stackexchange.com/questions/66464/why-we-must-reference-the-entire-txid-for-each-output-we-want-to-spend
< goatpig> you are introducing some serious complexity and attack vectors with that kind of approach
< bitcoin-git> [bitcoin] blockcash opened pull request #12022: test (master...master) https://github.com/bitcoin/bitcoin/pull/12022
< bitcoin-git> [bitcoin] sipa closed pull request #12022: test (master...master) https://github.com/bitcoin/bitcoin/pull/12022
< 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
< bitcoin-git> [bitcoin] janstary opened pull request #12023: update the OpenBSD build guide (master...openbsd) https://github.com/bitcoin/bitcoin/pull/12023
< 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)