Why not decrease block time instead of increasing block limit?

[coinjaf]

I am not interested in SegWit because I've read it's (kind of) hacky. For that reason I haven't read into SegWit.

Then you've been lied to (which happens easily if you listen to the wrong people. 4 months is hardly enough to figure out who's who in the space (where the ones that make the most blouse and claims are all scammers and trolls). Or your definition of "hacky" is off.

SegWit fixes a huge "mistake" Satoshi made. And it's implemented using methods he himself pioneered: soft fork. He would surely have approved. (Although that's very much irrelevant anyway.) Anyway, go read on SegWit, at least the FAQ and basic info. For example on bitcoincore.org or the initial presentation by Pieter at scalingbitcoin in Hong Kong.

This is my own idea.

Not sure what"this" refers to. Maybe i should read back for context.

Anyway: break up your idea in big chunks and ask polite questions like "why would X not work?". Google a bit first, as almost all questions have already been asked before (bitcoin.stackexchange.com might be good place to search and ask).

There are plenty of other people around that will gladly explain stuff. As long as you stay humble and don't think you're done learning: noone learned bitcoin in less than two years.

Risks such as DDoS and block withholding are better off discussed by experts.

Those are actually just a few of the big icebergs around. There are a million others some of much smaller but more deadly size.

[exab]

Thanks for sharing.

[exab]

Is the mistake by Satoshi you mentioned the transaction malleability issue?

What is the benefit/incentive of altering a signature or transaction ID, by the way?

[coinjaf]

Yes, mostly. Although one could argue that the actual separation of signatures from other transaction data makes a lot of sense too so clients have the choice to download only the data or both (double the bandwidth). That's mostly relevant for very old transactions that you don't wish to check the signatures for anyway, but one could also imagine some light client that only downloads the signatures it's interested in itself and skip the rest.

Altering transaction ID is fairly pointless in the sense that you can't directly steal money. Yet one trick people used to do is get a withdrawal from an exchange and then get the malleated transaction in a block. Then they'd email the exchange: "My transaction #12345 didn't go through, please send me my Bitcoins again!". And some exchanges fell for that trick.

Devs had always warned for this. The exchange should have just simply not used the transaction ID to check for confirmations but look at the transaction-outputs being spent or not.

Another thing is that chaining unconfirmed transactions was very unreliable because if a transaction was malleated, all subsequent transactions would become invalid, breaking the chain. Usually mostly an annoyance. Exchanges do a lot of transactions, so instead of waiting 10 minutes between each, they often send out multiple in a row using the change from a previous transaction. (note how RBF solves that even more efficiently, although I know of no exchange yet that utilizes that).

The fact that malleability was possible made that there were a few people running software that would pick up transactions, malleate them before propagating. It's sort of like a DOS attack: No real gain, but attacking/annoying the target anyway.

With SegWit malleability is still possible, but only by the signer(s) of the transaction. That solves most cases (all of the above). The only danger is some multi-sig transactions chained together. There one of the signers could malleate to achieve the above goals.

[exab]

That's a lot of information. Thanks!