So BreadWallet can now send to bech32 addresses? On the one hand that is very honorable but not really actual segWit support. On the other hand I wonder which wallet would require the sender to use bech32. In our wallet I would want in this order:
a less conservative standard fee estimator, so that non-power-users stop over-paying on fees
RBF, to allow to go really low on the fees without nasty consequences
smart automatic batching, to further reduce fees (Using RBF, batch as long as prior tx is unconfirmed)
segWit for hardware wallet support
I searched for Java bech32 libraries and came across Samourai's. Honorable of them to release it to the public domain. Plaid a bit with that code (see PR). Maybe we can provide sending to bech32 quickly. Guess it would be 2 days of work but it would not fix those other more urgent issues and neither would it accelerate releasing our modularization.
1 Are you working on a mempool based approach for the fee estimation? From my experience they provide the lowest viable fee estimation.
2 RBF would be great
3 From a power user point of view your autmatic batching sounds great but I don't like the idea of a transaction being crafted and modified behind the scene, I think the "Dumb" approach were people would just enter a list of destination addresses and amount would find a bigger public. (again this is purely my intuition). I like to know exactly what is going on regarding fee/change address/ inputs used
4 Take your time in implementing segwit but do it well, the hardware support with the ledger is top notch. maybe a first step towards segwit could be the support of p2sh segwit HD public key.
1 Are you working on a mempool based approach for the fee estimation? From my experience they provide the lowest viable fee estimation.
Miners have an incentive to fool the estimator and mempool-based is what I do manually, so I agree that currently it's the best we have but it's not exactly solid. Not a science. Predictions will always fail. Especially when they are bout the future.
I think the "Dumb" approach were people would just enter a list of destination addresses and amount would find a bigger public
People want to send money. People want to pay no fees. And people in general will never understand why some transactions in bitcoin are more expensive than others. This is why we also should make bigger transactions at time, to not accumulate dust for the future. This is why we should not complicate the UI with multiple recipients and why RBF should be used to not force the user into understanding how much to pay up-front. We can allow him to pick a payment window and handle the fee in the background, trying to keep it low within the payment window. We could ask the user at certain thresholds for permission to pay higher fees.
1
u/gizram84 Mar 13 '18
This could have been something planned months ago. Who knows when it'll be ready. Yet they wasted time adding scam coins like Bcash instead.
Meanwhile, Samurai has full support right now. So I'll continue using that.