What do you think about this solution?
In my case, after a transaction from segwit addresses I ended up with my entire balance on one legacy address.
So, what if before each spending, I check the balance of the wallet (in my case only one address) and calculate the change amount before payment is made.
So, for example: if my balance is 0.55 and I need to send 0.25 to somebody, the change will be 0.30 (minus fee).
Now, I can easily include in sendmany a new (or existing) segwit address I generate and make sure the fee is deducted only from the new segwit address. This way, I will end up with 0.30 minus the sending fee in a new segwit address. And next time, when I send out funds, I always do this, so I will always end up with my balance on one segwit address.
Is there anything wrong with my assumption?
In my case, after a transaction from segwit addresses I ended up with my entire balance on one legacy address.
So, what if before each spending, I check the balance of the wallet (in my case only one address) and calculate the change amount before payment is made.
So, for example: if my balance is 0.55 and I need to send 0.25 to somebody, the change will be 0.30 (minus fee).
Now, I can easily include in sendmany a new (or existing) segwit address I generate and make sure the fee is deducted only from the new segwit address. This way, I will end up with 0.30 minus the sending fee in a new segwit address. And next time, when I send out funds, I always do this, so I will always end up with my balance on one segwit address.
Is there anything wrong with my assumption?
How do you specify what address in sendmany will be used as a miner's fee?
Code:
sendmany{address:amount,...} [minconf=1] [comment]
The point of sendmany was to allow several recipients (to send to different addresses at once from a single input) but I dont see where it lets you specify what address is going to be used as a fee.
I would be sure to know what im doing before doing anything of this nature.
sendmany has the option to select which receiving address will pay the fee. So, if I treat my change / segwit address as one of the recipients and specify that the fee is deducted only from this new change / segwit address than this address will receive everything back (my starting balance on original segwit account minus all payments need to be made) minus the fee.
https://chainquery.com/bitcoin-api/sendmany
Parameter #1—from account
Parameter #2—the addresses and amounts to pay
Parameter #3—minimum confirmations
Parameter #4—a comment
Parameter #5-subtractfeefromamount is missing from the bitcoin RPC GitHub Issue #6500
Result—a TXID of the sent transaction
But where are you choosing what address you want to use to recieve the change of the address? You may be able to choose paramater 5 (which is not substractfeefromamount but subtractfeefrom followed with the address):
Code:
5. subtractfeefrom (array, optional) A json array with addresses.
The fee will be equally deducted from the amount of each selected address.
Those recipients will receive less bitcoins than you enter in their corresponding amount field.
If no addresses are specified here, the sender pays the fee.
[
"address" (string) Subtract fee from this address
,...
]
But I still don't see any command that lets you specify what address you want to receive the change at?
To a new segwit address I create. So, it needs more steps:
1. Check your balance ($balance).
2. Calculate the real amount you need to send to different receivers ($amounttosend).
3. Calculate how much is the rest ($rest = $balance - $amounttosend).
4. Create a new segwit address (bitcoin-cli addwitnessaddress 1....) $segwitchangeaddress
5. Create the sendmany command with all the addresses and amounts where you need to send + add another recipient ($segwitchangeaddress) with the $rest as amount and select to pay the fees only by this address.
This way, you always spend ALL your output but you can make sure that the change / rest is coming back to a segwit address, not a legacy address. Does that make sense?
Im not sure if your method would work. You should ask achow first in my opinion. Here's a guy that was trying to do something similar:
https://bitcointalksearch.org/topic/p2sh-p2wpkh-segwit-change-addresses-in-bitcoin-core-how-2107760
And here gmaxwell said that you shouldn't mix BTC addresses and segwit addresses within the same wallet:
I think the idea so far is to add a segwit account to segwit enabled wallets. The segwit account then has segwit addresses (p2sh at first). The user is free to choose between his segwit account and non-segwit account and whether he wants to transfer his funds to the segwit account. When he uses the segwit account, he uses segwit change addresses. So every user can decide for himself if/when he wants to update to segwit (of course, only after it gets activated).
That sounds like foolish wallet construction, IMO. Don't do that. A wallet should use segwit (in which case all newly generated addresses should be segwit) or it shouldn't (in which case none of it is).
As far as bare P2WPKH outputs, indeed-- those could be used for change, but they're more identifiable which is pretty ugly.
Honestly I would wait until 0.16 to deal with segwit. I think they will allow you to manage several different wallets at once, so you can have a legacy wallet and a segwit wallet and change address will automatically be segwit in the segwit wallet or something along the lines.
Im too paranoid to use segwit until I have it isolated in another wallet and there's proper GUI support.
Hopefully achow is checking this thread and he will give his opinion.
Regarding the risks, are there any risks mixing legacy and segwit addresses on the same wallet using bitcoin core?
Im not sure if there are any risks, but from what I've understood from reading developers here and on the Bitcoin Core slack, they are designing the GUI on 0.16 (or 0.15.2, not sure what will be the first version with full segwit support) is that the wallets will be separated. At least with the GUI, you will not be allowed to create segwit addresses outside of a "non segwit wallet". This separation must be a technical reason for this that I don't know (and I would like to know btw).
