Bitcoin Forum
June 04, 2024, 02:14:31 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 [94] 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 ... 189 »
1861  Economy / Economics / Re: investment mode of btc is best or currency mode??? on: November 19, 2017, 04:49:48 PM
A trend has been started that bitcoin is now used only for raising income by buying and selling it but we are ignoring its most important fact that it was created to be used as currency and if it can be used as the currency it would really help community to enjoy its eases and regions who are accepting btc must have to start it as currency this will automatically boost user no's as well a prices,

The price of something goes up if it's desired, and has a certain set of properties that make it a good long term holding.

Bitcoin first needs to be a store of value, a currency is the next step after that, and thus far we are still in the store of value process. We need to defeat gold as store of value. Daily usage of BTC will come with lightning networks. We don't need to do anything other than keep developing the technology and people will freely choose to use it as a currency, until then it's just digital gold.
1862  Bitcoin / Development & Technical Discussion / Re: Will LN be able to retrieve stuck addresses? on: November 19, 2017, 04:05:26 PM

It's not stuck, you can still spend it.

How? if the fee becomes consistently higher than the amount held in the address.


In LN, you need to create a funding transaction which sends the money you want to put into the channel into a special 2-of-2 multisig address. From there, you can do microtransactions with the money you deposited.


I got the idea, but what happens when you can't afford the first on-chain transaction? If the idea is "banking the unbanked" as Andreas Antonopoulos goes around saying, how can some poor person in good knows where, afford that first on-chain transaction? Let's say average on-chain transaction reaches $50-100 in the future and you want to bank the unbanked in africa or who knows where else. Im not sure if they will have that $50-100 entry fee (+ the amount you want to use for microtransactions) lying around.
1863  Bitcoin / Development & Technical Discussion / Re: Will LN be able to retrieve stuck addresses? on: November 18, 2017, 07:57:49 PM
Will LN allow me to move these funds?
No, it will not. LN requires you to make an on chain transaction to be able to begin using LN, so if you don't/can't make an onchain transaction with those coins, then you cannot use LN.

Well, this is a problem then. What happens with all that money? it just gets stuck forever?

Also in what sense do you need to make an on-chain transaction? You mean that I would need to make for example 1 BTC transaction, then I could make microtransactions from that 1 BTC?

Where would this 1 BTC be sitting at if it needs to be moved? where does it needs to be moved? is it safe there?
1864  Bitcoin / Development & Technical Discussion / Will LN be able to retrieve stuck addresses? on: November 18, 2017, 06:56:16 PM
What I mean is, all these addresses that contain small amounts of BTC, not worth really moving anymore due the fees going up, will be able to be used again?

For example, when I was a noob many years ago, someone sent me a tiny amount of satoshis which back then you could use and move around. Right now that small amount turned into 5 bucks, which I could use to for example pay an extra couple of days of VPN service. Problem is, the current fees make it not worth it. These satoshis are in a wallet that doesn't have any other addresses, so I couldn't join them with bigger amounts. Also it's on legacy format address so I can't really use segwit (and I would like to use even lower fees than segwit for such a small amount)

Will LN allow me to move these funds?
1865  Alternate cryptocurrencies / Service Discussion (Altcoins) / Re: How to see BCH amount on Bitcoin.com wallet on: November 18, 2017, 05:32:41 PM
Hey, i just got in to cryptocurrency. I bought some BCH and sent it to my Bitcoin.com wallet. I know it is in my wallet, but i can not see it. It only shows me how much BTC i have. How can i make my BCH visible?

I wouldn't use Bitcoin.com's wallet, or read any of their news at all. That's Roger Ver's propaganda website. Get Electrum for BTC (and Electroncash for BCH, I think).

Having said that, are you sure you bought BTC and not BCH? Thanks to the BCash idiots, a lot of noobs are sending BCH in BTC addresses, or BTC in BCH addresses, because the address format looks exactly the same.

You need to go to blockchain.info or any similar site and post your tx id to get further help.
1866  Bitcoin / Bitcoin Technical Support / Re: Track Bitcoin address on: November 18, 2017, 05:03:17 PM
Just to be clear, don't import any sort of information into a web wallet of any kind, not even master public addresses, recommending these kind of practices is simply not safe and I've read it around here before.

If I really wanted to do this the right thing, I would learn how to use Armory as a watch only wallet. This is the best suited wallet to do that, that I know of.
Why not? No one can easily derive the Master Private Key from your Master Public Key easily. Especially without having at least one of the child private key exposed, which you obviously shouldn't have done in the first place. Your privacy can be compromised but that doesn't fall under the category of being "unsafe".


Download Electrum and you can import your MPK or addresses.

Well call me paranoid if you want, but I don't see that as a safe practice. In general, the idea of seeds, or anything that can generate more addresses through a single hash, is a total mistake. Exposing your private keys to move funds from wallet to wallet is a mistake as well, just transact your coins from wallet A to wallet B. It may be too extreme of a view but that's me.
1867  Bitcoin / Bitcoin Technical Support / Re: Track Bitcoin address on: November 18, 2017, 12:54:53 AM
Just to be clear, don't import any sort of information into a web wallet of any kind, not even master public addresses, recommending these kind of practices is simply not safe and I've read it around here before.

If I really wanted to do this the right thing, I would learn how to use Armory as a watch only wallet. This is the best suited wallet to do that, that I know of.
1868  Bitcoin / Bitcoin Technical Support / Re: Track Bitcoin address on: November 17, 2017, 07:31:55 PM
i want to know if it possible to track address (want to see balance amount only ) .

i use this site https://bitref.com/

it is good but only track 1 address and give wrong information (it is small change when use it with my old transaction)

also not work with HD wallet (that change address and give you more than 1 address )

in short words i have public address and want to check balance amount on that wallet how can do this .



You can check any address you want in any block explorer such as https://www.blockchain.info or https://www.blocktrail.com/BTC

But if you want to keep track of a series of addresses, you can use Armory:

https://www.youtube.com/watch?v=8q1nvgcyYkM

There's probably other ways. Just google "watch only wallet" and research.
1869  Bitcoin / Bitcoin Technical Support / Re: Exodus to BTC core wallet on: November 17, 2017, 06:53:55 PM
Well I've been storing my btc on exodus wallet but I recently found out that I can't adjust transfer fee. I have to pay transfer fee that is set by exodus and sometimes it's really high. So now I decided that maybe it would be best if I store my coins on official bitcoin wallet as there I can adjust fee.

Now my question is... since I control my keys on exodus, does anyone know how I can use does exported keys and import them into bitcoin core wallet?

Thanks for all answers.

Are you using Exodus on Linux or a Windows machine?

Generally it's a bad idea to export private keys. They are encrypted and never shown for a reason, but if you are on a Windows machine I would never do that.. you have to assume some loser is hacking you if you are using Windows, so simply send your coins to your bitcoin wallet.dat in a transaction and not export and import anything.

If you are using Windows, start considering using Linux. Make a new partition and install Bitcoin Core there.
1870  Economy / Speculation / Re: American Investors Plan to “HODL” Bitcoin Until Price Hits $196,000 on: November 17, 2017, 05:49:26 PM
I find these type of predictions rather humorous. If you actually find the news and read the article, the prediction was up to the cents of a dollar, which is funny. What kind of algorithmic mathetmatical model did he use to arrive to such a precise prediction?

But in any case, im sure $200,000 will be hit within the next decade, as bitcoin becomes the de-facto world currency reserve. USD is a scam, and gold's supply is unknown. Nothing can beat BTC as a global unit of account.
1871  Bitcoin / Bitcoin Technical Support / Re: Block size 1 MB on: November 17, 2017, 04:12:25 PM
can small block size problem (only 1 MB) destroy bitcoin ? , bitcoin will edit it ? or this is normal problem Huh

It will not destroy bitcoin, but it will destroy use cases for bitcoin, at least when it comes to on-chain transactions. Once fees are $10 on average, you can't pretend to sell a lot of articles that are on that $1 to $10 range, because the fee costs more than the product you want to sell.

The tradeoff to scale on-chain is that you inevitably reduce decentralization of the network since the nodes are heavier to run.

Lightning Network type solutions have been a proposal to avoid that, or just using other altcoins for small transactions, and leaving BTC as "digital gold".
1872  Bitcoin / Bitcoin Technical Support / Re: Allocating chainstate files into an SSD on: November 17, 2017, 12:27:15 AM
I do not consider SSD as safe when it comes to storing sensitive data (such as your wallet.dat) since in the event that you needed to wipe it out, you couldn't, that I know off. In classic HDD drives, you could delete it easily.

There's also the problem of space obviously, since SSD's are way more expensive.

So my idea was to try to make Bitcoin Core run faster by allocating chainstate files in an SSD, then store wallet.dat and blockchain files in an external HDD.

I was wondering if anyone knows how to do this in Linux. (im not sure how fast it will be with this method, but I heard that the important files to have in the SSD are the chainstate files, so could save a lot of money by not having to store block files inside SSD drives).

You can't easily do this and anyway you did it could potentially cause lag and more database corruption.
It is worthwhile getting a good size ssd if you want to go that way to store everything on it (copying your wallet.dat to other places to try to save it should the ssd need formatting).

Why would it add lag?

As far as I know, chainstate files are the files that get accessed the most by Bitcoin Core. blocks folder files aren't accessed that often. So if this is true then you would be making it a lot faster if the files that get accessed the most are sitting on an SSD.

Im not sure if it's worth investing on a bigger SSD, when im just going to be using it so sync the blockchain. Sure I could re-use it a couple years from now to store data in the future but I dont want to invest unnecessary money.

I mean the blocks and chainstate directory are designed to be in the same parent data directory and unless you can do something fancy with the code or the partition architecture of how everything runs, you could get it working normally. However if not, then it'd either require files to trick Bitcoin Core into putting the chainstate in a different place.

Thus, you'll have to stick to one drive IMO. Either an ssd or HDD for both directories. A hard drive is still quite fast though.  Although that's external for you so it will be slower than an internal one.

Well that is unfortunate if true. I think I read achow saying that (that it would be faster if you put the chainstate files on an SSD).

Why would an external HDD be slower? If it runs at 7200 rpm like most modern HDD, it should be as fast? or maybe it's due the fact that it's not SATA but USB?

I just was looking forward buying one of these Libreboot t400 laptops, I saw some people talking about them as a safe way to run a node away from spyware (see them at minifree dot org)

What do you think? I would pick the 8 GB 1TB HDD configuration. Assuming the blocksize stays at 1MB it would last me for a long time until I need to pick a bigger HDD.
1873  Bitcoin / Bitcoin Technical Support / Re: Allocating chainstate files into an SSD on: November 16, 2017, 07:28:36 PM
I do not consider SSD as safe when it comes to storing sensitive data (such as your wallet.dat) since in the event that you needed to wipe it out, you couldn't, that I know off. In classic HDD drives, you could delete it easily.

There's also the problem of space obviously, since SSD's are way more expensive.

So my idea was to try to make Bitcoin Core run faster by allocating chainstate files in an SSD, then store wallet.dat and blockchain files in an external HDD.

I was wondering if anyone knows how to do this in Linux. (im not sure how fast it will be with this method, but I heard that the important files to have in the SSD are the chainstate files, so could save a lot of money by not having to store block files inside SSD drives).

You can't easily do this and anyway you did it could potentially cause lag and more database corruption.
It is worthwhile getting a good size ssd if you want to go that way to store everything on it (copying your wallet.dat to other places to try to save it should the ssd need formatting).

Why would it add lag?

As far as I know, chainstate files are the files that get accessed the most by Bitcoin Core. blocks folder files aren't accessed that often. So if this is true then you would be making it a lot faster if the files that get accessed the most are sitting on an SSD.

Im not sure if it's worth investing on a bigger SSD, when im just going to be using it so sync the blockchain. Sure I could re-use it a couple years from now to store data in the future but I dont want to invest unnecessary money.
1874  Bitcoin / Bitcoin Technical Support / Allocating chainstate files into an SSD on: November 16, 2017, 05:49:46 PM
I do not consider SSD as safe when it comes to storing sensitive data (such as your wallet.dat) since in the event that you needed to wipe it out, you couldn't, that I know off. In classic HDD drives, you could delete it easily.

There's also the problem of space obviously, since SSD's are way more expensive.

So my idea was to try to make Bitcoin Core run faster by allocating chainstate files in an SSD, then store wallet.dat and blockchain files in an external HDD.

I was wondering if anyone knows how to do this in Linux. (im not sure how fast it will be with this method, but I heard that the important files to have in the SSD are the chainstate files, so could save a lot of money by not having to store block files inside SSD drives).
1875  Bitcoin / Development & Technical Discussion / Re: Paranoid about key generation on Raspberry Pi 3 on: November 16, 2017, 05:00:33 PM


So if what you used contained your wallet data at any point in time, wipe them, but kept them... just in case.


It did not contain wallet data as such. It contained mnemonic seed displayed on an offline Linux machine within vetted Javascript pages inside Chromium webbrowser. The question is: poses such a thing a potential security threat?

If an USB is plugged in a machine that is connected to the internet, it is safe to be considered compromised. Call me paranoid, but there is no such thing as enough paranoia when it comes to bitcoin, got to stay safe.

I wouldn't be using seeds for offline storage. Maybe Armory is the best solution for offline storage, since you keep the private keys separate like on a wallet.dat file (I think).

The point is to not have all of your money on a single seed that would give access to an attacker to all of your money. So don't use Electrum to manage offline cold storage for example, since it uses a seed.
1876  Bitcoin / Development & Technical Discussion / Re: Paranoid about key generation on Raspberry Pi 3 on: November 15, 2017, 07:07:47 PM
I am not familiar with Linux. That is the reason I am asking the question.

I used the following process to derive my private keys and use them for bitcoin cold storage.

1. Ordered Raspberry Pi, MicroSD card and USB disk exclusively for this purpose.
2. Copied NOOBS from raspberrypi.org onto microSD card on a windows machine.
3. Checked hash of NOOBS with MD5 and Checksum utility.
4. Saved bitaddress.org, keybase.io/warp wallet and iancoleman BIP 39 pages on the USB disk.
5. Started RaspberryPi.
6. Installed Raspbian from NOOBS microSD card. Raspberry Pi was never online or connected to any other device except Sony TV via HDMI cable.
7. Opened Chromium in incognito mode and opened the pages under 4)
8. Created first private key on bitaddress.org
9. Plugged that private key into warp wallet and created another private key
10. Plugged that private key into BIP39 as the seed for 24-word mnemonic.
11. Typed in password as the 25th seed.
12. Wrote that down.
13. Checked public addresses via QR code generator and mobile phone on google to verify that they are unknown entities in online space.
14. Plugged wiped Trezor into windows machine and used secure seed recovery.
15. Transfered bitcoins to that address.

Questions that I have are:
WHAT SHOULD I DO WITH MICROSD CARD AND USB STICK?

Please state reasons for choosing one of the options.

Options:

1. Burn 'em. It is not worth risking your BTC for 20 bucks of disposables.

2. Wipe both. If so how?

3. You can use both because the process that you described does in no way, shape or form leave a trace that a malicious party could use to restore your master private key or seed?

I would like to LEARN what happens with such drives under Linux distribution and also recycle them in order to repeat the same process for another altcoin or a smaller BTC amount that I can use as semi-cold storage.

Thanks

MicroSD, USB, and anything of similar nature (including SSD hard drives) aren't a good thing if you have on mind completely erasing the data therein. With an HDD you can completely erase data with secure-delete (or secure erase, not sure what the name was).

So if what you used contained your wallet data at any point in time, wipe them, but kept them... just in case.

In order to move a transaction from a cold storage into an online machine, you could use a QR scanner. Convert the raw transaction data into QR code, read it into your node and you can then broadcast it into the network. This way you don't leave data anywhere. The QR code could be contained in the RAM temporarily as far as I know, but that should be it.
1877  Bitcoin / Bitcoin Technical Support / Re: SegWit change address becomes legacy??? on: November 15, 2017, 06:51:32 PM
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?

How do you specify what address in sendmany will be used as a miner's fee?

Code:
sendmany 	<fromaccount> {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://bitcointalk.org/index.php?topic=2107760.0

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).
1878  Bitcoin / Bitcoin Technical Support / Re: SegWit change address becomes legacy??? on: November 15, 2017, 05:43:25 PM
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?

How do you specify what address in sendmany will be used as a miner's fee?

Code:
sendmany 	<fromaccount> {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://bitcointalk.org/index.php?topic=2107760.0

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.
1879  Bitcoin / Bitcoin Technical Support / Re: SegWit change address becomes legacy??? on: November 15, 2017, 05:13:26 PM
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?

How do you specify what address in sendmany will be used as a miner's fee?

Code:
sendmany 	<fromaccount> {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?
1880  Bitcoin / Bitcoin Technical Support / Re: SegWit change address becomes legacy??? on: November 15, 2017, 04:31:03 PM
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?

How do you specify what address in sendmany will be used as a miner's fee?

Code:
sendmany 	<fromaccount> {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.
Pages: « 1 ... 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 [94] 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 ... 189 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!