The feeling I get by watching the growth of the tangle, and by looking at my transactions unconfirmed for many days now, is that the majority of transactions never gets confirmed or entangled. This is corroborated by this issue on IRI. I don't know the dev team views on this issue, but it looks very different from the picture we get from reading the whitepaper, and seems to be scaring users on Reddit and on the forums.
I believe the issue of ever expanding unconfirmed tips can be mitigated if there was an API call to "follow" a tip returned by getTransactionsToApprove(): if any of your tips gets confirmed by some other valid transaction while you are still performing your PoW, you are notified with its transaction hash, so you can update your trunk_transaction_hash or branch_transaction_hash mid PoW. The time it takes to perform PoW on CPU is not irrelevant, thus much power is wasted when multiple clients try to confirm the same transaction, and by the time they are done and publish the transaction, they are already left behind by the bulk of higher computational power branch of the tangle (powered by GPU, maybe?), having less chance of being selected by the Monte Carlo algorithm (if I understood correctly how tip selection works). By following the tip, the slow hasher is able to keep his chances of being selected high, while improving the security of the new tip, too, alongside the originally selected tip.
I understand that, ideally, such API call would have to be asynchronous, which doesn't fit well the stateless Request->Response model of a HTTP REST API. You can't "register" your request to follow a tip, then wait for an asynchronous response from the server. Nonetheless, it can be implemented via some kind of HTTP push technique, like long polling or pushlet.
The feeling I get by watching the growth of the tangle, and by looking at my transactions unconfirmed for many days now, is that the majority of transactions never gets confirmed or entangled. This is corroborated by this issue on IRI. I don't know the dev team views on this issue, but it looks very different from the picture we get from reading the whitepaper, and seems to be scaring users on Reddit and on the forums.
I believe the issue of ever expanding unconfirmed tips can be mitigated if there was an API call to "follow" a tip returned by
getTransactionsToApprove(): if any of your tips gets confirmed by some other valid transaction while you are still performing your PoW, you are notified with its transaction hash, so you can update yourtrunk_transaction_hashorbranch_transaction_hashmid PoW. The time it takes to perform PoW on CPU is not irrelevant, thus much power is wasted when multiple clients try to confirm the same transaction, and by the time they are done and publish the transaction, they are already left behind by the bulk of higher computational power branch of the tangle (powered by GPU, maybe?), having less chance of being selected by the Monte Carlo algorithm (if I understood correctly how tip selection works). By following the tip, the slow hasher is able to keep his chances of being selected high, while improving the security of the new tip, too, alongside the originally selected tip.I understand that, ideally, such API call would have to be asynchronous, which doesn't fit well the stateless Request->Response model of a HTTP REST API. You can't "register" your request to follow a tip, then wait for an asynchronous response from the server. Nonetheless, it can be implemented via some kind of HTTP push technique, like long polling or pushlet.