Transactions announcements to other peers are already delayed for bandwidth reduction (because announcing may at once takes asymptotically about one forth the bandwidth: since ip+tcp+bitcoin have overheads similar to the size of one announcement and the delays usually prevents the same transaction from being announced both ways across a single link) and privacy reasons. The delays are currently a poisson process with an expected delay of
5 seconds between a node transmitting to all inbound connecting peers. Outbound connections each see 2 second expected delay.
As a result reconciliation based relay doesn't increase delays (in fact, with our current WIP parametrization, it decreases average delays somewhat).
I share Carlton Banks' concern. Your tone in past messages as well as the this one is rude and somewhat irritating particularly when coupled with (otherwise innocent) ignorance of Bitcoin 101 topics like how transaction relay works. The fact that your message went a day here without getting a reply even though you were unaware of the existing batching which any of thousands of people could have pointed out to you demonstrates one of the negative consequences of taking such a tone instead of asking a polite and professional question... If you actually care about learning you should refrain from that sort of behaviour. If you're not actually interested in that, you should discontinue posting in this sub-forum because that isn't welcome here. People with actually useful answers aren't going to choose to spend their time hanging out somewhere to get insulted by newbies or people who just haven't done their homework.
done without a hard fork because it doesn't change the incentives
A number of hostile posters on bitcointalk and reddit seem to be using the word hardfork in a more or less random way. A hardfork is not a general term for an idea the speaker thinks is a bad idea
. A hardfork is a change in consensus rules which is irreconcilably incompatible with prior consensus rules e.g. accepting a block containing spends that previous software would reject as invalid. Transaction relay is entirely outside of consensus and as a result no possible change to it would be a hardfork (or a softfork, for that matter). The existing Bitcoin protocol and software even has a mode which disables transaction relay entirely (blocksonly) and it is fully consensus compatible with other nodes (and saves a metric boatload of bandwidth).
selfish and resource optimization behavior especially against small nodes
All of the computational work in reconciliation is performed by the party that initiates the reconciliation. So a third party cannot cause you to expend more resources than you want to expend on it. We've been doing protocol design assuming the need to support rpi3 nodes without an undue burden; which was part of the reason minisketch was required since prior bandwidth efficient reconciliation code was far too slow for limited hardware like that. rpi3 is more or less the bottom end for running a full node-- already that target takes 20+ days to synchronize the chain. Slower could still be used, but it would presumably reconcile less often.
The theoretical propagation time of data across the network is actually the upper bound on network throughput.
Not at all, Bitcoin is already a batch system-- blocks show up at random times and commit to a chunk of transactions, whatever is missed and still valid goes into a subsistent block. Both because blocks are relatively infrequent and because the mining process itself has seconds of latency (e.g. from batching new block templates to mining devices to avoid creating extreme loads on block template servers) the existing delays have little effect on the transaction handling delays.
More fundamentally, the connection you believe exists between tx propagation time and network throughput just doesn't exist: It could take an hour to propagate transactions and the resulting network throughput would be unchanged because the network doesn't stop and wait while the transactions are being propagated. If it did, it would add an hour until you saw a confirmation, but the number of confirmed transactions per hour would not be changed.
Imagine you had an infinite number of dump trucks to use in hauling gravel from one city to another, 24 hours a day 365 days a year. Each truck carries 1 ton of payload and every 5 minutes a full truck leaves. During week you will carry 2016 tons of gravel between the cities. It does not matter if the cities are 1 hour apart or 5 hours apart: Changing latency does not change throughput for non-serialized operations.
In Bitcoin the latency is relevant-- not because of throughput reasons, but because of things like people caring about their transactions being confirmed sooner rather than later. So long as the TX propagation delays are very small compared to the block finding interval they don't matter much in terms of the user's experience, so it's fine to trade off some small latency for other considerations like reduced bandwidth or increased privacy-- which is something Bitcoin currently does and has always done since the very first version (though the details of the trade-off have changed over time).
There are other minor considerations that make tx propagation delays matter some, but they're all of a sort where they don't matter much so long as they're significantly less than other delays (like block template updating delays).
