With a random string of 25 characters, it is incredibly unlikely that you will be able to brute force your wallet. In fact, it is basically impossible. Unfortunately your Bitcoin is now lost.
I do believe it was only numbers and lowercase letters. Does that make it any more likely? Still extremely unlikely given the length of the password. |
|
|
|
|
With a random string of 25 characters, it is incredibly unlikely that you will be able to brute force your wallet. In fact, it is basically impossible. Unfortunately your Bitcoin is now lost.
|
|
|
|
If was to download this new release would I need to download the entire bootstrap again?
No. Upgrading to a new version of Bitcoin Core does not require redownloading the entire blockchain. Also, you don't need the bootstrap, that method is outdated now and will take longer than just letting it sync. How many gigs is it as of right now?
Last time I checked it was counted off to the nearest over 100 gigs.
The blockchain is currently ~110 GB. However you don't need to store all of it if you enable pruning. Pruning will reduce the size on the disk to only a few gigs. |
|
|
|
Ran this for 16 hours and had a two issues.
Did not shut down cleanly (popped up windows error message).
What was the error? Anything in the debug.log? When I started .13.1 immediately after, I noticed it was 2 hours behind even though I had 8 connections before shutting down .14.
IIRC it will rewind the blockchain a bit on the next start if the shut down was unclean so that any errors in the blockchain and the databases can be caught and fixed. |
|
|
|
|
They removed the scrollbar.. I hate it when sites do that. Now I can't quickly scroll half way down a massive list of transactions.
Where did the giant scrolling list of unconfirmed transactions go? That was always super useful for getting a random transaction for examples.
And that list of links to other useful stuff like recent double spends? Why did they remove all of that?
All in all, they have reduced the functionality of their site and this change is overall worse.
|
|
|
|
Here, in Meta. I have moved your thread for you. To recover your account, follow the instructions here: https://bitcointalk.org/index.php?topic=497545.0It is also useful to post the name of the account so that people can give it negative trust until it is recovered. |
|
|
|
Thanks for your reply!
On the multiple outputs:
As far as I understand is that in case of multiple outputs any of the addresses can spend the coins (but only 1 can do it naturally).
They are multisig outputs, not multiple outputs. What you just said is incorrect. They have the exact same requirements as a normal p2sh multisig address for spending. WIth the example transaction that you linked, 1 out of the 2 public keys in a bare multisig output need to sign the spending transaction in order to spend. If that were in the traditional 2-of-3 multisig format, then there would still need to be two signatures which correspond to two different public keys specified in the output. But when it is empty what should I do with it? I do I interpret OP_RETURN/non-standard? Should I ignore it? Are they bounced/invalidated transactions? or especially interesting?
Look at the other data in the output. It will say what type the output is. Generally anything that is not pubkey, pubkeyhash, or scripthash should be shown as non-standard. If it is an OP_RETURN output, the type is nulldata and you can get the data after the OP_RETURN and display that. Usually those can be interpreted as strings, but they can really be any arbitrary data. Also another question: I always hear about IP address being registered with transactions and all (like it is on blockchain.info) but is this information actually stored inside the blockchain? And if yes how can I can find it. Doesn's seem to be inside 'getrawtransaction'?
No. IP addresses are not part of anything to do with blocks or transactions. They would ruin privacy and there is no use for an IP address. The IP addresses you see in block explorers are simply the IP address of the node that relayed the transaction to the block explorer's node. Those IPs are not the IP address of the node that sent the transaction. |
|
|
|
You keep saying things that aren't true.
If your wallet balance was a result of 500 payments of 0.001 BTC, then your wallet balance would be:
500 X 0.001 = 0.5 BTC
The picture you linked to shows a wallet with a balance of 0.05337027
I suspect that you either have less unspent outputs than you think you do, or the average value of the unspent outputs is closer to 0.0001 BTC than 0.001 BTC.
Of those two possibilities, I suspect that the average output value is more like 0.0001 BTC.
His second image shows that he's getting outputs of 0.0001 BTC. Accepting payments of 0.0001 BTC was a VERY bad idea on your part.
Each of those outputs are going to add about 148 bytes to any transaction you try to send.
At the current cost of about 0.00000180 BTC per byte, that means that each of those 0.0001 BTC payments will cost you about 0.00026640 BTC to spend.
The inputs are actually 180 bytes because he is using Armory (and probably an old version of Armory) which still uses uncompressed keys (technical debt due to lack of development for a while. Compressed keys will be supported soon TM) According to http://bitcoinfees.21.co/ the current recommended fee is actually 0.00000140 BTC/byte so each additional input will cost 0.00025200 BTC, still more than the value of each output. |
|
|
|
Probably the transaction I pasted was one of the smaller ones I tried (my bad). Here is the output of a full amount transaction calculation:  Basically I'm not able to make it. The client is not even attempting to make an actual transaction as it finds it not feasible at all. Again, what version of Armory are you using? The reason the transaction is not being made is because it calculates the fee to be too large for the amount of your transaction so that transaction would be invalid. IIRC if you are using the "Expert" usermode, you can force it to use the smaller fee. Also, it doesn't say the fee is 1 BTC but rather 0.1. It also looks like you are attempting to spend all of the Bitcoin from your a-ads payments, and that appears to be in the thousands of inputs to consume, so your transaction is going to be very very large. You should change your a-ads payout threshold to be a lot higher to avoid this problem. |
|
|
|
Now my question is: Is this the only way to get the 'input address' of a transaction or
That is the only way you are guaranteed to get the right address. can I find the address also by somehow decoding the scriptSig?
You can try, but this may not necessarily work. Most transactions' scriptsigs will either be for a p2pkh or a p2sh multisig output. For p2pkh, there is a signature and then the pubkey. You can convert the pubkey to an address. For p2sh multisig, there are multiple signatures followed by the redeemscript. You can take the redeemscript and convert that to an address. However there is no easy way to do this in Bitcoin Core (that I know of). Same question is obviously for the input amount and to what output it contributes.
The only way to get the amounts is to lookup the referenced transaction and figure it out from there. Also I see: "addresses": ["1Q8xxbdUAJPAEo3vmf5RXcTi2efijYKuVu"] as being an array, is this ever empty or has more then 1 value? If so why and when does this happen (perhaps a transaction ID that I can follow?)
It can be empty if the output is non-standard or OP_RETURN. I think it will return multiple addresses for bare multisig outputs too. |
|
|
|
For the transaction that you posted, did Armory suggest that you use a transaction fee that is over 1 BTC? If it did, that's probably a bug. What version of Armory are you using? Maybe you need to drop some inputs, does Armory has coincontrol?
If you enable Expert mode, you can access coin control and select the inputs that you want to use. |
|
|
|
what is the "share" folder and how is stored the mempool file indicated in the debug.log ?
Can you ask that again with less broken English? There is no "share" folder. Nice. I'm assuming the fee bumping is utilizing RBF to accomplish this and just providing an interface to make the process easy for users?
Yes, that uses opt-in RBF. Your transactions will need to be created with RBF opted in though. AFAIK there is no GUI feature to bump the fee yet, you have to use the debug console. Nice to see the preciousblock feature. I assume you submit your block and then send the preciousblock message?
Yes. The node needs to know about the block before it can be marked as "precious" |
|
|
|
The official Armory website is https://btcarmory.com/ and does not have any support link, so you were probably using the old website, https://www.bitcoinarmory.com/ (it's a long story as to why there are two website, I don't want to explain it). Did you also install Bitcoin Core? If so, run it in manual mode by going to File > Settings and uncheck the box to allow Armoy run Bitcoin COre in the background. If you did not install Bitcoin Core, you have to do that because Armory relies on it. The "official support" is the Armory subforum here: https://bitcointalk.org/index.php?board=97.0. I am moving this thread there. |
|
|
|
|
What Z value? There is no value in a Bitcoin transaction or in ECDSA signatures that is called "Z".
|
|
|
|
|
Developing your own wallet can in fact be very dangerous to your Bitcoin. You must understand the ins and outs of the entire Bitcoin protocol, down to the byte level. Screw something up, and you could lose all of your Bitcoin or be vulnerable to an attack. If your wallet is closed source, then you won't get any review from experts who can tell you whether there are serious bugs in your code. Furthermore, security through obscurity both doesn't matter here and is rarely any security at all.
|
|
|
|
|
Unfortunately Bitcoin transactions are irreversible. There isn't really anything that you can do to get your Bitcoin back. You could attempt to contact Paypal and explain that the Bitcoin was sent and that the buyer had scammed you. You can prove that you sent the Bitcoin; you have the address that the buyer sent you and the transaction id of the transaction itself. If your wallet allows you to sign transactions (i.e. its a desktop wallet) then you can prove that you were the person who sent the Bitcoin. Of course, this requires that the people at Paypal know about Bitcoin and how it works, so this may not work.
|
|
|
|
So the private key (string of letters) is the bitcoin, and it can be in any denomination?
No. First of all, the private key is not actually a string of letters. Rather it is a large 256 bit integer represented as a string of numbers. Represented in decimal it would be ~78 digits long. Secondly, there is no such object as a Bitcoin. Bitcoin actually uses transaction outputs. Outputs have a value associated with them; that value is the Bitcoin. The private key is what allows you to spend the value from the output. Of course, it is much more complicated than that. |
|
|
|
Did you mean to write "shouldn't"? (feel free to delete this if yes)
If the block contained a segwit transaction in segwit format, then it should reject the block. If the block contained a segwit transaction in legacy format, then it shouldn't reject the block and accept it. |
|
|
|
What about nodes running 13.2? If a miner included a SegWit transaction in a block today, would a 13.2 node accept or reject the block?
It should accept the block as it will still recognize that the segwit rules have not activated yet. |
|
|
|
Are they non-standard, or invalid (until if/when SegWit is activated)?
IIRC, amaclin had claimed to get BC.I to display a SegWit transaction that was "from" an address whose private key he did not control/have possession of.
They are non-standard because old nodes will still accept segwit transactions if they are included in a block. |
|
|
|
|
Show Posts
