Aah, I see! Thanks for the clarification!
edit: So Armory doesn't like a pruned bitcoin-core? I need the whole blockchain each time Armory starts up?
edit2: Restoring 91 GB bitcoin-core stuff.. *sigh*
Ente
Nope, pruning won't work. It reads the block files directly and it still needs the entire blockchain which a pruned node cannot provide. |
|
|
|
All releases are signed. All future tags will be signed.
Sounds great! Just to be clear, a "release" is like a major version, right? Is 0.94.0 a release then, and is it signed already? I'd like to step up to 0.94, for the much reduced database size.. Ente A release is any version that has a tag and published binaries. The binaries for 0.94 and 0.94.1 are hashed and those hashes are placed into a file and signed. That has happened with all releases. The tags are also signed, but goatpig didn't do that for 0.94 or 0.94.1. Future releases will have signed tags. |
|
|
|
So both v0.94.0 and v0.94.1 are not signed?
That way I have to trust that noone manipulated data in the repo circumventing the regular, visibly logged commit infrastructure?
Are/will any releases be signed?
For me, this repo is so much of a target that the risk of unsigned releases is too high for me..
Ente
All releases are signed. All future tags will be signed. |
|
|
|
If you are using MultiBit HD, it is not possible to create the wallet files easily by hand. You can't import keys into MultiBit HD. If you are using MultiBit Classic, then make a text file with the following format for each key, one on each line: The <timestamp> is the ISO 8601 timestamp including the century. It should look something like 2016-10-06T21:03:15Z. That timestamp is in UTC and is used as the starting point to start scanning for your transactions. Save that file as a .key file and then you can import it to MultiBit Classic. |
|
|
|
Ok.. How about this command? ./configure --enable-glibc-back-compat --prefix=`pwd`/depends/x86_64-pc-linux-gnu LDFLAGS="-static-libstdc++" |
|
|
|
My .NET application with my test bitcoin server.
Server as in bitcoind? How are you connecting? |
|
|
|
Im sorry "Where <address> is the address of you want the private key of. Then you can take that private key and sweep it into your new wallet."
That has me totally lost.
You have Bitcoins sent to an address in your wallet. That address is the address you enter for that argument. The dumpprivkey command will output the private key to that address. You have to take that private key and enter it into another wallet in order to spend the Bitcoin associated with that key. |
|
|
|
I suspect it had something to do with his promotion.
Nope. I was promoted two weeks after my name was changed. |
|
|
|
|
AFAICT, no JS here. If you can't tell that the forum doesn't use JS, how do you even plan on getting a security bounty?
|
|
|
|
In my algorithm, I give different signatures for the same message, because I'm using the same function to sign transaction.
How it should be?
That's ok. I'm not sure why Core returns the same signature. I think it may just be cached by the software, I need to look into a bit more. It seems to be cached. This seems to be implied by this comment in the signing stuff: Furthermore, it is guaranteed that identical signatures (including their
recoverability) will have identical representation, so they can be
memcmp'ed. |
|
|
|
You can export the private key and sweep the Bitcoin into your wallet. In Bitcoin Core, go to Help > Debug Window and then the Console tab. Then type Where <address> is the address of you want the private key of. Then you can take that private key and sweep it into your new wallet. |
|
|
|
Lets say that the current difficulty is X, being behind by N blocks (a total PoW of X*N), the attacker artificially sets (perhaps by messing with timestamps) the difficulty to X*N+d (with the smallest possible d), and continues raising the difficulty, to ensure that if a block is mined, it will surpass the main chain. As time goes on, the total main chain PoW=Sum(fork->leaf)[X] increases, and the attacker keeps increasing the set difficulty to Sum(fork->leaf)[X]+d to surpass the network with one block. If intuition does not fail me, this attack would almost certainly succeed.
The attacker would have to be able to mine a lot of blocks. The difficulty only changes every 2016 blocks. Furthermore, the time used for calculating the two week period is actually the median of the last 11 blocks. So such an attack would require the attacker to be able to mine a lot of blocks within the retarget period. Furthermore, the time of the previous block does not affect the time of the next block, so the attacker would actually need to control the hash power of most of the network in order to shift the timestamps enough to affect the difficulty. |
|
|
|
I have just one more question - do I have to have Bitcoin Core Wallet up and running in order to receive BTCs? Or once I start it up - will it sync and then I receive any BTC at the time while wallet was not up and running?
No, you do not need Bitcoin Core running in order to receive Bitcoin. The Bitcoin isn't "sent" to your wallet. The transaction is published and your wallet will get that transaction when it syncs the blockchain if that transaction is confirmed. |
|
|
|
|
Screenshot please.
There should be three balances, Available, Pending, and Total. Which ones show the wrong value.
What likely happened is that the change of your unconfirmed transactions is still unconfirmed. Because those change outputs are unconfirmed, the wallet will not list them as available for spending.
|
|
|
|
If I sign the same message several times, the bitcoin-qt returns the same signature.
It does not use a random seed for signing, such as signing transactions?
No, message signing is different from transaction signing. Message signing has three parts: (1) Address (with privatekey), (2) Message, and (3) Signature. When signing a message, you are providing proof that the message comes from that bitcoin address (and thus you have control over that privatekey). If you change the address you are signing from, your signature will change. There is no random seed in basic message signing, since that would defeat others ability to verify it. The same signing algorithm is used because really it is all just signing bytes of data. If I sign two transactions with the same seed, I expose my private key.
The same thing happens with the message signature?
Yes, that can happen. But that will not happen here because the signatures are identical. You only expose the private key if the R values are the same but the S values are different. In this case, because the signatures are identical, then both R and S are identical so it doesn't matter. |
|
|
|
|
Spending unconfirmed inputs is not allowed by Bitcoin Core unless you use the raw transaction RPCs. spendzeroconfchange only allows you to spend unconfirmed change outputs.
|
|
|
|
|
I'm having a hard time following what you are talking about. Can you provide an example?
In order to increase the difficulty, an attacker would need to be able to find blocks at a rate faster than a block every ten minutes. Thus they would need even more power than the network has at that time.
|
|
|
|
Try this configure command instead ./configure --prefix=`pwd`/depends/x86_64-pc-linux-gnu LDFLAGS="-static-libstdc++" |
|
|
|
Wow. What a troll. It looks like that is Bitcoin Unlimited. The full user agent string is /I like big BLOCKS and I cannot lie, you other miners can't deny, that when an itty bitty block gets put on top, it makes me want to cry [Bitcoin Unlimited] :0.12.1(EB20; AD72)/ You can look it up on Bitnodes: https://bitnodes.21.co/nodes/136.243.61.34-8333/ |
|
|
|
Who determines the fee? I dont see anywhere to put a fee when I want to send bitcoins to someone. Is it the wallet software or who?
Typically the wallet software does it for you. However, in most wallets, you can set it yourself. |
|
|
|
|
Show Posts
