Yeah well, that's the part I'm not getting at all  The hash of the transaction is AFAIK the hash of all data contained in the transaction, including the input sigs. It's like a snail biting its own tail. Or are the sigs somehow signing a version of the TX with the sigs omitted or left blank? I must confessed to being a bit confused. The hash is a hash of the transaction with some modifications. Those modifications are: the input scripts areblanked out (replaced with 0x00), the input that is currently being signed is given an input script of the output script the transaction refers to, and the sighash code is appended to the end. Then that is hashed and that hash is signed. The signature produced is then placed into its corresponding input's scriptsig. This link might help: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx |
|
|
|
Is there a chance for newbie to join a signature campaign?  No. No signature campaigns accept newbies. If you rank up a little, you could join YoBit, but I would highly recommend that you don't. YoBit has a low reputation and participants in their campaign are known to be spammers. By joining that campaign, you mark yourself as someone who may be spamming and thus increase the likelihood of a ban. If you choose to join a signature campaign, please post with good quality. Read all of the stickies in every section you want to post in to learn the rules of that section. You should also read the stickies in Meta because those apply to the entire forum. If you break any of the rules, your post will be deleted and you be banned. To post with good quality, do not simply just repeat what others have said in the thread before you. Read the thread before you post; what you want to say may have already been said. The OP may have moved on from the original topic and the topic of the thread may have turned to something else. Always think before you post. If you are posting just to boost your post count, don't post. If you have no idea what the thread is about, don't post. If you are posting in a thread with pages and pages and pages of replies, don't post if you don't want to read the whole thing. If you do as I said above, the likelihood of getting your posts deleted and being banned decreases. |
|
|
|
OK, didn't realize the signature of each input was somehow
bound to the TX itself. I wonder how that works. Gotta read
up on this.
The signature is the signature of the hash of the transaction. The hash is computed on the fly and if the signature does not validate to the specified public key with the hash as the input, then the signature, and thus transaction, is invalid. Cool. And will the satoshi client be able to do this (as in : spend from
an unconfirmed TX with large fees) ?
It is a little complicated. I think that (I'm not quite sure) if you enable coin control you should be able to select unconfirmed inputs to spend from. Otherwise you will have to use the RPC console to craft a transaction by hand with the raw transaction RPCs and broadcast that. |
|
|
|
Ok last question:
If it failed to reindex the blocks the first time on my computer will it fail again or could it possibly work on the same computer?
It could still work. If it fails multiple times, it probably won't work though. Also do viruses, programs etc. make the hardware slower?
Yes. Anything that uses RAM and CPU will slow down the reindex and be slowed down by the reindex. It is best to just not run any other resource intensive programs while reindexing. Also, you should add the Bitcoin data directory to your antivirus exclusion list. Antivirus software have been known to corrupt the blockchain and cause reindexs and other issues. |
|
|
|
How long is reindexing supposed to take if you just installed bitcoin?
As I said earlier, it depends on your computer. For my computer, it takes about 4 hours to reindex & is there a way to open this bitcoin wallet on a different computer, do the reindexing, then continue using my current computer?
The wallet is different from the reindex. You could start up another computer, have it fully sync the blockchain, and then copy over all of the blockchain data (but not the wallet) to your computer. The wallet is not necessary for reindexs and syncing. |
|
|
|
Did everything I could to try and upload it but it wouldn't paste anywhere.
By pastebin I meant go to http://pastebin.com/ and put the debug log there. Then share the link. Is there anything I can do to speed this process up?
Short of getting better hardware, no, there is no way to speed it up. It's going so slow & if it is a debug issue how do I solve it?
It is not a debug issue. The debug.log usually tells use where the issue is. The issue is usally hardware failure when Bitcoin Core is constantly reindexing. The only way to solve a hardware problem is to get new hardware. |
|
|
|
I cant fit it all in here. its huge & looks like 500 lines of this:
Put it all into a pastebin and post the link. 99% of the debug.log is useless here. However the errors are hidden among them and that is what we are looking for. In order to find them though, we need to see the whole thing, not just what 99% of the log file is full of. |
|
|
|
a86935b5eb31c0536a1a224ad1f1e7ae0fe height=332698 log2_work=81.642321 tx=53022045 date=2014-12-03 13:24:53 progress=0.422426 cache=30.1MiB(7209tx)
We need more than just one line. Please post the entire debug.log file. There is no sensitive information stored in that file. |
|
|
|
|
Bitcoin Core will always start from where it left off if it stopped. By restarting the reindexing process, this means that something failed and caused corruption that forced it to have to restart reindexing. This is likely to be hardware failure. Can you provide the debug.log? You can get it by going to Help > Debug window and clicking the Open button underneath "Debug log file".
The time it takes to reindex is entirely dependent on your hardware. A faster CPU, more RAM, and SSD will reindex faster.
|
|
|
|
Hello,
I have a question that I think is becoming more and more relevant in these
days of systematically full blocks and where getting transactions confirmed
is increasingly becoming a total crapshoot.
Say someone sends me bitcoins. I discover this because coins are sent to
an addie I control and therefore my wallet latches on to it and displays it
in my transaction ledger.
However, upon close examination of the transaction, it becomes clear that
the cheapskate who sent it included way too little fees and the TX will take
ages to confirm, if ever.
At that point, if it's essential enough for me to get the funds that were sent,
I would not mind actually paying the fees *myself* to lubricate the confirmation
of this TX.
Three questions:
- is this theoretically even possible ? Can I somehow dissect the already broadcasted TX
to reassemble it into a larger one with addt'l inputs (say an input from an addie *I*
control) so as to pay higher fees ? And once that is done, broadcast this newly
constructed TX, which would hopefully get prioritized before the old one and make
it a double spend.
- if possible, is there a tool / wallet out there that would let me do this, or, barring that,
is there a way to pull it off via the satoshi client RPC interface.
- also, if possible, in the scenario where:
- old TX is stuck
- I construct new, higher prio version
- I broadcast new version
- old TX gets included in a block, making the new one a double spend
then what happens to the "extra" input I added ? Can that signed input somehow
be reclaimed by someone ?
Any wisdom on the topic is welcome
What you are proposing is entirely impossible. It is not possible to "dissect and reassemble" an already broadcasted transaction without having the private keys that spend the inputs. You cannot add inputs or outputs to the transaction because the signatures for each input ensure that the transaction has not been modified in any way. Otherwise anyone would be able to steal other people's Bitcoin. The solution to your problem is called Child Pays For Parent (CPFP). A CPFP transaction is a transaction that has some inputs that spend from unconfirmed transactions. It may also have other inputs from confirmed transactions. The idea is that that transaction will have a significantly higher fee than a normal transaction. This high fee would cover the fee of the unconfirmed transaction and the CPFP transaction itself, hence the Child Pays For Parent. Then, any miner with CPFP enabled will pick up the CPFP transaction and the unconfirmed one and confirm them both at the same time. |
|
|
|
Really Great Post !! much detailed.
Anyway... i dont uderstand how to upgrade if i use Armory Wallet... it should do it for his own but when i click on the upgrade nothing happens.
Armory no longer does the updates as the announcements server which provided those updates is no longer working. Rather you should go to the download for Bitcoin Core on bitcoin.org and download and install Bitcoin Core. Then you should also update Armory and download the latest version from https://github.com/goatpig/BitcoinArmory/releases and install that. |
|
|
|
I'm going to have to reinstall Linux tomorrow, and I'm going to do a clean install of 16.04 LTS (was running 14LTS)...saw your note here, and wanted to ask if you could be more specific/expansive on "using -salvagewallet arg." I was able to reconstitute my 0.11.1 wallet on Win10 using the backup wallet.dat file from the data drive (I don't store my data files on a system drive).
I'm also figuring to update the Core Client to 0.12.1 from 0.11.1, and so I'm trying to get my troubleshooting resources together before trying it. I've seen info that says there are problems with older data files (ie, 0.11.1) being used by 0.12.1? I've got a backup Win10 drive I use in the meantime.
Thanks for your input.
There are usually no problems with older files that are not also experienced by older software. The upgrade is usually smooth and goes without issue. Thanks, kid...I needed that.  If you think I am spamming, I am not. I have worked with Bitcoin Core for a long time and in my experience, the upgrade is always smooth. What usually happens when something goes wrong is usually due to either hardware failure or the user being stupid. It has nothing to do with the software itself as the Core Developers are very careful to ensure that the software is backwards compatible and they do stringent testing to ensure that everything works as it should. I personally have never experienced any such issues with Bitcoin Core or with upgrading the software, and I have done so on multiple operating systems and across OS upgrades. |
|
|
|
I'm going to have to reinstall Linux tomorrow, and I'm going to do a clean install of 16.04 LTS (was running 14LTS)...saw your note here, and wanted to ask if you could be more specific/expansive on "using -salvagewallet arg." I was able to reconstitute my 0.11.1 wallet on Win10 using the backup wallet.dat file from the data drive (I don't store my data files on a system drive).
I'm also figuring to update the Core Client to 0.12.1 from 0.11.1, and so I'm trying to get my troubleshooting resources together before trying it. I've seen info that says there are problems with older data files (ie, 0.11.1) being used by 0.12.1? I've got a backup Win10 drive I use in the meantime.
Thanks for your input.
There are usually no problems with older files that are not also experienced by older software. The upgrade is usually smooth and goes without issue. |
|
|
|
|
Usually it is due to a very low fee or that some inputs the transaction depends on are also not yet confirmed. Another is that it could be producing a dust output. The amount transferred usually does not matter (it does in the case of dust outputs, but even transactions with dust outputs will still be confirmed after a slight delay), the actual size in bytes of the transaction does.
If you post the transaction id, we may be able to help you.
|
|
|
|
My user agent /Satoshi:0.12.1/
Is this normal?
yes that is normal. Satoshi is the name in the user string for Bitcoin Core. |
|
|
|
i registred on the forum earlier today and i had one post but i cannot find it  did i do anything wrong ?  It was probably a useless intro post (that I probably reported) which are against forum rules. There is no need to introduce yourself. Also, you should change the subject of this thread because you clearly are not just saying hello. |
|
|
|
I've seen a lot of members spam this forum with signature campaigns.
I have seen you post a lot of spam. I was posting original content, but never reached the essay that most sig campaigners demand.
So you just posted the bare minimum for the low quality yobit campaign in order to get paid. A lot of your posts are spammy, one-liners, and in the typical spam-attracting threads which the mods should really lock. there should be a fair and balanced team keeping these spammers off the forum.
Yeah, they're called the mods. The mods have a huge job to do with cleaning up all of the spam produced by sig spammers. Maybe you should help them and not spam and report spammers. Ypbit accused me indirectly of spamming the forum.
You were spamming the forum. It is good that you got banned. Maybe your post quality will go up.
What does the main body of your post have to do with the subject? If you are proposing to ban sig campaigns, check out all of the other threads about the exact same thing. Use the search function to find them. |
|
|
|
I have User A who generates BIP32 Master Public and Private Keys. It shares the Master Public Key with User B.
Using the Master Public Key User B generates Address of A and Issues bitcoins from Address of B to Address of A.
Will the transaction be received in wallet of User A, if User A knows the index used by User B. ?
The main idea is that User A don't want to share its receiving address with User B. Instead of that User A must find out itself from the Master Public Key.
Yes. User A will see the transaction appear in his wallet. |
|
|
|
i have my wallet encrypted on my pc..
i just changed this password.. i was wondering if i have to reback it up or if the backup i have, which is secure, is still ok with the old password.
Your question is not clear. If you backup your current wallet, then the backup would have the new password. If you want to restore an old backup created before you changed the password, then it will use the old password. i was just wondering if there was something in the system that would make my old backup not work if i changed the password. The old backup will still work, you will just need to use your old password and any addresses generated after changing your password will not be in your old backup. |
|
|
|
|
Show Posts
