|
I absolutely fucking despise people that use these forums to promote their shitty blogs. I give Sergio a pass on that because he has done a bunch of good work, but I still refuse to click his links. Does anyone want to copy the text of this article here?
|
|
|
|
I have 2 questions though:
1. Is it possible to verify for an external person that the transaction is a multi-signature transaction?
2. How do I get the sciptpubkey and the reedem key?
1. No. The can see that coins were sent to a P2SH address, which is the hash of a script, but they can't see what that script is until revealed. It could be multisig, it could be pay-to-address, it could be something strange. Of course, if you want people to see that it was multisig, you can publish the script through some other means, and people will be able to see that it really does hash to the P2SH address shown. 2. You create them. Or, if someone else is managing the address, they create them and then maybe give them to you. |
|
|
|
|
I just realized that if I need to tell you to use armory, you probably have no idea how armory works.
Armory uses EC math to generate two parallel streams of keys. Your insecure computer can create new addresses and give them out to orders while an offline computer generates matching private keys. The offline computer generates the real secret and calculates seed values to be given to the online computer. You only need to back up the initial secret once. If the online computer is penetrated, all the attacker learns is the sequence of addresses, never the keys needed to spend money sent to those addresses.
|
|
|
|
|
You should seriously consider using armory instead of rolling your own system. It does what you are trying to do, and it does it better.
|
|
|
|
I transferred all my *coin clients, including their databases, from Debian Linux to FreeBSD. They were all properly shut down. None of them would work until I removed the databases and started from scratch. Should the database files be transferable between different operating systems?
I have no idea. It would depend on how the database library is written. The blockchain files themselves are platform-agnostic: values are written in a screwy byte order and each client is responsible for converting that order to their internal format. If I had to guess, I'd expect the database files to be similar, and thus be compatible between operating systems, and maybe even between CPUs. But I don't really know. When you say they were shut down properly, do you mean the databases were detached too? Do the altcoins even support that correctly? |
|
|
|
|
No method springs to mind.
Then again, PGP doesn't really verify keys much. You can sign your pubkey using your privkey, but that just proves that there really is a privkey corresponding to that pubkey. It doesn't tell anyone anything about the composition of that privkey.
On the other hand, if your nonce range is small enough, everyone would be able to just brute force it. But that isn't likely to be useful, unless you want people to verify your key by reconstructing the whole thing.
|
|
|
|
|
It is possible to copy the blockchain around. At least it was pre-0.8. I don't see any reason why you wouldn't be able to after leveldb, I just haven't tried it yet.
You just need to make sure that you get the entire chain and index in one shot. In the BDB days, that meant doing a shutdown-with-detach, then copying all of the block files with the index.
|
|
|
|
In P2SH, there are two scripts. The first script is a stub that makes other nodes recognize it as a P2SH script, and it includes the hash of the second script. The second script can be anything, and it isn't revealed until the transaction is redeemed. The hash of the revealed script must match the hash embedded in the stub.
Multisig is just a special script that has an instruction that verifies that at least M-of-N signatures are present. This script can be in a normal transaction, or it can be in a P2SH transaction.
The stock client understands multisig via P2SH. There are commands to create P2SH multisig addresses, and the client will understand them correctly. If the client knows the P2SH address in question, and knows enough of the keys to redeem it, then the transaction will show up in listunspent, and the value will be calculated in your wallet balance, etc.
Thank for this good explanation, however I don't understand a thing in the last paragraph: if the client knows the P2SH address, it knows the hash of the script but doesn't know the script itself, so isn't able to determine if it has enough of the keys to redeem it, therefore it can't appear in listunspent etc. Now, is this correct or am I overseeing something? Knowing the script is what I mean by knowing the address. The node doesn't try every key it has against every transaction it sees to see if it can redeem it, it cheats. It stores something called the scriptPubKey and uses that to look up secrets. The secrets are usually private keys, but in this case, it is the redemption script. |
|
|
|
Mining of transactions aren't a problem, and EMC continues to mine dust outputs. However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client. That's my issue/beef with this. The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.
The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.
Or, you could just set your -minrelaytxfee option to something lower than the default. Much easier than "modifying the reference client". |
|
|
|
Accounts get created automatically when you use them. either adds an address (key) to "account", or it creates "account" with a new address. setaccount "address" "account" associates an existing address with either a new or old account. The empty string is the default account. When performing an action that operates on an account, but you don't want it for any specific account, use the empty string. "*" is all accounts, you use it when fetching information. The quotation marks are not part of the account name, but how to handle them depends on how you are making the RPC calls. |
|
|
|
How to pass parameter to function 'getnewaddress' ? Just pass the parameters in the getnewaddress() call. $json = $bitcoin->getnewaddress("Account_Name");
|
|
|
|
|
In P2SH, there are two scripts. The first script is a stub that makes other nodes recognize it as a P2SH script, and it includes the hash of the second script. The second script can be anything, and it isn't revealed until the transaction is redeemed. The hash of the revealed script must match the hash embedded in the stub.
Multisig is just a special script that has an instruction that verifies that at least M-of-N signatures are present. This script can be in a normal transaction, or it can be in a P2SH transaction.
The stock client understands multisig via P2SH. There are commands to create P2SH multisig addresses, and the client will understand them correctly. If the client knows the P2SH address in question, and knows enough of the keys to redeem it, then the transaction will show up in listunspent, and the value will be calculated in your wallet balance, etc.
|
|
|
|
|
You can usually use either "*" or an empty string in calls that need an account name.
|
|
|
|
I also have two orders that don't show up in the store, both from February 3rd.
Did you opened a ticket? Two tickets. |
|
|
|
|
I also have two orders that don't show up in the store, both from February 3rd.
|
|
|
|
Keep in mind that neither server is really hidden from the other.
Would you mind explaining this a bit more? How would an attacker find the origin of a message sent from server B? Each server needs to know how to reach the other. Using tor, you can restrict what each side knows and harden that part, but you can't eliminate it entirely. For example, if A and B only know each other by tor hidden service keys, then if an attacker gets into A, he will learn how to send messages to B, but he won't learn how to port scan, or whatever else he'd like. Like Mike, I was thinking about a trust relationship between A and B. If you don't need that, then yes, tor is excellent. Running any sort of bitcoin service is like sticking a big sign on your server that says "Free money here!". Even if you don't actually keep your wallet on that server, you will get more attention. If you aren't sure of your security, or don't want the hassle, or both, then tor is a huge advantage in that you then really only need to harden one TCP port, while the rest of your server can fade into the billions of other random boxes on the internet. As I'm currently imagining it, server A actually doesn't ever need to initiate communication with server B. I'm not sure about the specifics of how Tor operates, but wouldn't this mean that an attacker couldn't find server B, even if server A is compromised? If A doesn't know how to contact B, then yes, B can remain hidden. |
|
|
|
Keep in mind that neither server is really hidden from the other.
Would you mind explaining this a bit more? How would an attacker find the origin of a message sent from server B? Each server needs to know how to reach the other. Using tor, you can restrict what each side knows and harden that part, but you can't eliminate it entirely. For example, if A and B only know each other by tor hidden service keys, then if an attacker gets into A, he will learn how to send messages to B, but he won't learn how to port scan, or whatever else he'd like. Like Mike, I was thinking about a trust relationship between A and B. If you don't need that, then yes, tor is excellent. Running any sort of bitcoin service is like sticking a big sign on your server that says "Free money here!". Even if you don't actually keep your wallet on that server, you will get more attention. If you aren't sure of your security, or don't want the hassle, or both, then tor is a huge advantage in that you then really only need to harden one TCP port, while the rest of your server can fade into the billions of other random boxes on the internet. |
|
|
|
|
ASICs don't appear to change the scale dynamics, in the long run.
In the beginning, it made sense for the first few ASIC producers to run their devices internally. That world seems to be passing into history, rather than growing.
|
|
|
|
|
I'm planning to run some services over TOR like this.
Keep in mind that neither server is really hidden from the other.
|
|
|
|
This addresses the race condition for finding blocks, but not forks due to bugs (like in March).
From what I am seeing miners should be able to spend their proceeds in 6 blocks not 100, so there must be justification for the 100 block wait on mining.
In the event of a fork, all of the non-conflicting transactions will eventually get into a block, regardless of which fork. Except for the generate transactions, and transactions that spend them, etc. 100 appears to have been picked as a large round number that would prevent orphan transactions even in the event of a very major split. Lowering it would cause a hard fork, but raising it would merely require that miners upgrade. |
|
|
|
|
Show Posts
