It's something I've been wanting to do over the last few days, I've currently got a single 1-of-1 recovery sheet of paper taped together (I.E. Tamper evident) sitting under my monitor. Not all that secure. I'm just wondering what you people do as I need some ideas.

1. What format of paper wallets do you have (I.E. Single sheet? Fragmented? If fragmented, what parameters?)
2. Where do you store the sheet(s)?

That's really it, thanks.

Is there anyway I can point armory at some brand new wallets (Some watch only, one local) and have it generate a multisig wallet on top of it? So I can just use it like a normal wallet and when I create a new address, it automatically generates one new wallet for the normal wallets and makes a multisig address out of that?

I really like the wallet mechanics in Armory, the lockbox feature seems to be made purely for holding funds you rarely touch, there's no real quick way (That I can see) to keep generating new addresses easily for day-to-day transactions.

Is this possible? I don't want to use tor for everything else as there's no real private data being transferred 99.99% of the time (Just everyone else's data), what I want is for bitcoind to act as two different clients, one on tor (That literally only sends transactions) and one on the clearnet that does all the generic stuff like forwarding blocks and transactions, saving blocks, etc...

For reference, this does mean I want this to occur when I send a transaction:-
1. Send transaction via Tor
2. Wait for transaction to reach you via clearnet (Due to the fact it's propagated to everyone)
3. Forward the transaction anyway via clearnet as if you don't (And instead say "I already knew of this"), someone looking at your traffic would be able to determine that you could be the one that sent it.

I'd prefer not to run two copies of bitcoind, I know it's probably possible doing that, but, that's a large overhead.

Post below, or, send me a PM. Got quite a few copies available, not posting a specific number because I'll forget to update it. BTC-E prices.

EDIT:- Selling this (click me!) for $7.50, fully giftable inventory copy.

Is it like bitcoin-qt where only the size of keypool is backed up? Or, is it like Armory where an infinite amount of future addresses are backed up? If it's the former, how do I increase the keypool size (To something like 10,000 addresses or something)?

I don't really want to use this wallet, have my phone crash, then realize I only backed up the first ten addresses or something stupid like that, and, lose my money.

Somewhat confused, first time installing Armory on this new version, it claims it's "Downloading via Armory CDN", yet, also claims it's downloading via a torrent from 29 peers. Which is it? A CDN or torrent? I wouldn't really call a torrent a "Armory's" CDN.

Second of all, who is seeding this torrent? Am I seeding this torrent? I didn't ask to seed this torrent.

Third, where is this torrent? Can I have a copy? I can't seem to find it:-

Code:

[user@Desktop ~]$ find /opt/armory-git/BitTornado -iname '*.torrent'
[user@Desktop ~]$

I couldn't find it either by searching the source for "Magnet". I was able to find 'bootstrap.dat.torrent' in announcemap.txt which googling it pointed me to this bitcointalk thread, but, that's a little too large of a jump to make without any sort of confirmation.

For both a transaction entering, and, leaving a multisig address, along with the address itself, what information do people who are **NOT** part of the address themselves see (I.E. Someone random on the network, such as a miner, or simply a full-node)?

Do they know the public key/hashed public key (I.E. address) of the participating clients?
Do they know how many clients there are (N in M-of-N)?
Do they know how many clients are needed to sign a key (M in M-of-N)?

And, another question:-
If I know two pub keys (I.E. pubA & pubB), can I determine if an address/transaction on the network includes those two pub keys in a 2-of-3? And how resource wasteful would that be (Checking to see if an address/transaction included my two pub keys)? So, imagine I was part of a service, I gave them my two pubkeys, and, they randomly generated their pubkey (from one of their private keys), then send $amount BTC to the address they generated without telling me the third key, would I be able to determine what address they sent to and be able to cash out my money? Or am I clueless without that third key (And thus even though I should be able to cash out the money (Due to me owning enough privatekeys), I can't because I don't know the TXID)?

Sorry, slightly confused about multisig.

Note:- Please give each answer a three-part answer, for both:-
1. Address on its own (I.E. address that has never had a transaction in/out)
2. Address with a singular TXIN
3. Address with a singular TXIN and singular TXOUT

EDIT:- Also, small little question at the end, is there anything random about a multisig address generation? I.E. if I had the three pubkeys and ran createmultisig ten times, would I always get the same address, assuming I used the same pubkeys & M-of-N?

As I like to pay using specific inputs, and, I only know those specific inputs by their comments, seeing this isn't all that useful:-


Selling $78 PayPal to who Mr. Coin Control!?! I don't want to spend the funds I bought off my real life friend to pay a known gambling/porn/other/not/so/socially/accepted site! I understand it's doing that to save space, but, really?



Look at all that wasted space that could be used for telling me the comment.

EDIT:- For reference, my commenting convention is:-

Code:

[Buying/Selling] [Product (Such as $50, "Google.com domain name", or, ฿5)] [Payment, such as Credit Card, Bitcoins, PayPal, etc...] [to/from] [alias (SiteIMetThemOnUID=TheirProfileUID] for [What I paid/got, opposite side of the trade as the second argument]

EDIT2:- Actually, while I'm at requesting stuff, a search feature would be nice too, so, I could filter the addresses to just ones that include "Bitcointalk", or, say I traded with "Satoshi" multiple times, I could search for "Satoshi" and find all the "Satoshi" transactions (That have "Satoshi" in the comments).

Actually, I just realized, I should probably actually just code it into Armory myself and then submit a push request, eh? Although, looking at your github history, you don't seem to accept many pull requests.

I use Armory to comment all of my transactions, and, honestly, without it (I.E. if it got corrupted) I'd be fucked, I'd have no idea what was for what (And thus cause privacy, and other, issues for myself).

Due to my concern, I wish to be able to backup and restore my transaction and address comments, I understand I can use the "Export transactions" option to export my transactions, which, includes my notes, but, there's no way to reimport them (Either on another computer, or, in the case of a reinstall/corruption of Armory/operating system, the same computer). So, basically my post is for a feature request to be able to import and export of comments (And preferably also a CLI option to do this, so I can script a dump every week or something).

Yes, I realize that the specifications are public (Click me), and, I could implement something to parse them myself (Which, I probably will do a bit later), but, I still will only be extracting the transactions, importing them back in will probably require me to actually learn the qwerks of the wallet format.

EDIT:- Also, what'd be really cool, but, probably require a bit more work than really is required, is that users could run their own open source server just for their computers, and, whenever you mark a transaction's comment, it's synced with the server. Whenever another one of your computers hops on, it can grab all the transaction comments from there, so, where ever you are (Assuming you're using Armory), you could work out what is for what.

Address is 160 bits, public key is 256 bits (Compressed public keys are 33 bytes[...]. The older uncompressed keys are 65 bytes (Source)), correct? This means there's obvious duplication.

Now, question is:-
If someone receives money on address A, then uses keypair B to spend the money on address A, then receives some more money to address A, can keypair C (Assuming RIPEMD-160 of the public key hashed to the same thing) then spend the money on address A, even though keypair B has already been 'registered' in the blockchain? Is there any validation? Or, is it simply "looks good, let's go"?

Obviously, this isn't a threat as the chances are insanely low, but, just wondering.

Transaction:-
https://blockchain.info/tx/324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e

Raw transaction:-
https://blockexplorer.com/rawtx/324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e

Why I think there's an issue:-

Code:

"lock_time": 1392854400,
"sequence": 0

Instead of:-

Code:

"lock_time": 0,
"sequence": 0xFFFFFFFF

I tried 'rescanning databases' to no avail.

https://en.bitcoin.it/wiki/Protocol_specification#tx

Field size:- 1+

How on earth do I actually mark it as greater than one? I tried just throwing another byte in there, but, that results in errors, I have this commented transaction so far:-

Code:

01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000 //boring transaction stuff
07 //0x07 bytes script
4c //0x4c states "next byte defines how many bytes I should push to the stack"
03 //0x03 bytes
8f7a3c //Those 0x03 bytes, 0x8f, 0x7a, and, 0x3c
76 //OP_DUP
88 //OP_EQUALVERIFY
00000000 //More boring transaction stuff (locktime)

Which, results in:-

Code:

{
    "hash": "5e4a2e55b8c21d491749d1009f568192e211fa931e78af343675fedf2371041d",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 0,
    "size": 68,
    "in": [
        {
            "prev_out": {
                "hash": "99fa789df2a0aef57e705f66f3185f30ba71e544b246661c74c9f6ec22a86546",
                "n": 1
            },
            "scriptSig": "OP_FALSE",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00490000",
            "scriptPubKey": "8f7a3c OP_DUP OP_EQUALVERIFY"
        }
    ]
}

However, like I said, I can't for the life of me work out how to increase the scriptPubKey to > 0xFF, imagine I have this:-

Code:

01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000 //boring transaction stuff
0301 //(0x07 + 0xff - 0x03) bytes script, 0x0103, bytes reversed to 0x0301.
4c //0x4c states "next byte defines how many bytes I should push to the stack"
ff //0xff bytes
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa //Those 0xff bytes, a bunch of 0xAA
76 //OP_DUP
88 //OP_EQUALVERIFY
00000000 //More boring transaction stuff (locktime)

Results in:-

Code:

{
    "hash": "a530ba3415952af7ed24f297fea7570219f401046fb50ac01d4c773bd2101bd0",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 2863311530,
    "size": 64,
    "in": [
        {
            "prev_out": {
                "hash": "99fa789df2a0aef57e705f66f3185f30ba71e544b246661c74c9f6ec22a86546",
                "n": 1
            },
            "scriptSig": "OP_FALSE",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00490000",
            "scriptPubKey": "4c "
        }
    ]
}

If I don't switch the bytes around for byte script length:-

Code:

01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000 //boring transaction stuff
0103 //(0x07 + 0xff - 0x03) bytes script, 0x0103, bytes reversed to 0x0301.
4c //0x4c states "next byte defines how many bytes I should push to the stack"
ff //0xff bytes
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa //Those 0xff bytes, a bunch of 0xAA
76 //OP_DUP
88 //OP_EQUALVERIFY
00000000 //More boring transaction stuff (locktime)

Equals:-

Code:

{
    "hash": "68ceb346c7711a74f31b8a285014ee08a58050480f69c5ee97cc75e803cf1c2e",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 2863333196,
    "size": 62,
    "in": [
        {
            "prev_out": {
                "hash": "99fa789df2a0aef57e705f66f3185f30ba71e544b246661c74c9f6ec22a86546",
                "n": 1
            },
            "scriptSig": "OP_FALSE",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00490000",
            "scriptPubKey": ""
        }
    ]
}

Any help on making scripts > 0xFF? All I'm currently getting is it overflowing into lockTime.

Imagine anti-virus A detects "0xAABBCCDEEFF" as a virus, okay? I submit a transaction which has the script, simply:-

Code:

0xAABBCCDDEEFF OP_DUP OP_EQUALVERIFY

At this point, basically, you're sending "0xAABBCCDDEEFF" to the mempool, duplicating it (OP_DUP), testing if 0xAABBCCDDEEFF and itself (OP_DUP) are the same, if so, the transaction is valid.

So, now it's a valid transaction, it'll be mined, and, it'll be put into the blockchain, this is where issues occur, suddenly, everybody who is running that anti-virus suddenly gets a warning, and, their antivirus starts quarantining the blockchain!

What's to stop this from occurring? It may cost an attacker a mBTC or so to actually pay for a transaction with a virus binary attached to it (As it'll probably be a few tens of KB), but, until the anti-virus vendor manually marks the blockchain as not a virus, surely it'll show up in a scan-time scan (And maybe even runtime, as, Bitcoin-QT will have "0xAABBCCDDEEFF" in memory).

1) Why do miners not like to fill blocks up to the absolute cap? Is there more work for them to do if they have lots of transactions in the block? I notice lots of blocks are only about 150KB large, when the protocol allows up to 500KB/1MB (Not sure, it's one of the two), while, there are lots of unconfirmed transactions in the mempool. Why not just include those? Even if they have super low transactions fees and/or low priority. I completely understand why a miner would ignore them if the block was filled up (And thus order by "How much profit can I get?"), but, that's not the case currently.


2) Am I correct in thinking, in theory, with the current "standard" settings (Obviously miners can change this), it only takes 58 confirmations on a 0.01 transaction for it to have a high enough priority to be free? That seems inaccurate, but, I can't work out what's wrong with my calculations.

Sorry for the newbie question, but, we all have to learn, eh?

When I rerun -reindex, I notice I do the first 100k blocks in about five minutes, then the next 100k in about an hour, then when I get to about 250k it goes at a few ten blocks per minute. Why do block get harder to verify the further through it gets? Is it not simply hashing them, verifying the hash, and, going to the next one? I understand why generating the blocks would get harder, but, not verifying them. Isn't that the whole point of a non-deterministic polynomial function?

Can someone explain to me what verifying a block actually entails? What the difference is between the 'checklevels' in bitcoin-qt/d?

Inputting the output of "decoderawtransaction" into "createrawtransaction" results in an error, I want to make a small change to a transaction before I sign it manually (Add a "lock_time", I want to see how it works), but, I can't seem to be able to do it.

Here's my hex string:-

Code:

0100000001f699454faacb036aab2411e38ea00f5db9ffa7e831432c8945e8f0e21c7f26620000000000ffffffff0228397100000000001976a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac40420f00000000001976a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac00000000010000000137268479bae60a643efbc656957b3e18d328d373af03db164633a1c63eb3fa38010000008b483045022100da354c1d60683b69656bb9c8e5d1f0c39a1c2c7d06ee0058b8f1dd4f455e41a50220063268fbf586095994a0b5cb2c1369a4a2bd365b83dd262baf992d1f81cfeac901410431676a8a5bd9629598daf9bd8249d4d6ce8298dbf26bb5d9cd7e3092d3c12be051c8bce0a4ecf6ec219e6b99259c5256641a7c00d18e2c48e728f4fdc0705438ffffffff02687b8000000000001976a914e6e58a7f6393bd51adaf6865ada8ca151ecd30b588ac46fe620d000000001976a914079c4a24d14153c77aa71a3ca451afd60fcc119388ac00000000

decodes into:-

Code:


{
	"txid": "2150f5a18448b5cafe5f0a41d8c61606178d52fca52a8e53f486a288dd433caa",
	"version": 1,
	"locktime": 0,
	"vin": [{
		"txid": "62267f1ce2f0e845892c4331e8a7ffb95d0fa08ee31124ab6a03cbaa4f4599f6",
		"vout": 0,
		"scriptSig": {
			"asm": "",
			"hex": ""
		},
		"sequence": 4294967295
	}],
	"vout": [{
		"value": 0.07420200,
		"n": 0,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 b0c8172cbdc5ef9962574fbf945d7d39b4f27387 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1H7jdJ9bfkoj45pnwrXyJ7xxCeJx3Mmfx6"
			]
		}
	}, {
		"value": 0.01000000,
		"n": 1,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 c37e2eb773d2314f92dc078f0c3a8277accc65f5 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa"
			]
		}
	}]
}

Piping that back in as:-

Code:


{
	"txid": "2150f5a18448b5cafe5f0a41d8c61606178d52fca52a8e53f486a288dd433caa",
	"version": 1,
	"locktime": 284300,
	"vin": [{
		"txid": "62267f1ce2f0e845892c4331e8a7ffb95d0fa08ee31124ab6a03cbaa4f4599f6",
		"vout": 0,
		"scriptSig": {
			"asm": "",
			"hex": ""
		},
		"sequence": 4294967295
	}],
	"vout": [{
		"value": 0.07420200,
		"n": 0,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 b0c8172cbdc5ef9962574fbf945d7d39b4f27387 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1H7jdJ9bfkoj45pnwrXyJ7xxCeJx3Mmfx6"
			]
		}
	}, {
		"value": 0.01000000,
		"n": 1,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 c37e2eb773d2314f92dc078f0c3a8277accc65f5 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa"
			]
		}
	}]
}

Results in "Error: Error parsing JSON:{txid" or "Error: Error parsing JSON:{", depending on if I copy it formatted or all on one line. The format of createrawtransaction (createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}) is obviously different to the output of decoderawtransaction, so, what's the best way of doing this?

Long story short, I added two nodes I 100% trust to relay my bitcoin traffic for me (They're both on 24/7), like so:-


But, now Armory gets stuck at 0 blocks, it manages to sync up from however many blocks it was back by (E.G., if it I was 55 blocks behind, it syncs to 0, then hangs):-


Launching Bitcoin-QT manually works fine:-


And help with why Armory refuses to go onto step 2?

EDIT:- Reason why I want to relay my traffic is I've noticed that my legitimate IP address seems to be attached to all of my transactions on blockchain.info, I could firewall blockchain.info, but, then I'm sure there's other companies that also log data like that. I'd prefer just to relay it through someone who I'm sure isn't publicly logging me. I know I could relay it through tor (or any other sock proxy), but, I care less about my anonymity (I.E. that everything that goes through those two nodes is me) than I do about people just not having my IP.

Thought of a way to do it, removed.

Code:

You cannot delete your own topics in this board.

Please note this is super early alpha, lots of features are missing from this bot, and, it may be buggy. If anyone reports any bugs in this bot, It'd be greatly appreciated.

Anyway, 100% automated, all gifts can be paid for and collected without any interaction from me.

How to use it:-

• Add the bot here
  
• Message it 'help', it shall explain the rest.

Current price list (Prices are subject to changes at any time):-

• Call of Duty: Ghosts - $25
• Rust - $15 (I recommend activation right after purchase, developers seem to be messing with the gift's properties at the moment (adding and removing region locks))
• Counter-Strike: Complete - $12
• Counter-Strike: Global Offensive - $7.50
• Counter-Strike: Source - $6
• Counter-Strike: Source + Garry's Mod - $8
• Garry's Mod - $4
• Left 4 Dead 2 - $10
• Payday 1 - $6
• Civilization V - $6
• Portal 2 - $7.50 No longer sold.
  
• The Cave - $7.50 No longer sold.
  
• Natural Selection 2 - $10
• Costume Quest - $5
• Gnomoria - $5
• Eldritch - $5
• Interstellar Marines - $5
• Insurgency - $10

Todo:-

• Price list from bot, currently the only way to know the price is to actually want to buy the game
• Cancel trades, currently after saying 'buy $item' you can't order another item for 5 minutes
• Be able to make a cart, so you don't have to buy games one-at-a-time
• Revamp code to be more secure, and, require less resources
• Fix up permissions on VPS

Changelog:-

Code:

2014/02/22 - Added Ghosts
2014/02/13 - Updated 'help' menu to remove ugly thread formatting, I do warn you though, if you message the bot 'help', it somewhat spams you (lots of messages to explain how to use it!)
2014/02/10 - Moved server to one with a larger HDD for the blockchain
2014/02/09 - Fixed bug with bitcoind that disabled the ability of my bot to function.
2014/02/09 - Updated bot to get the live price of BTC after the crash, before it was at a constant $800/BTC. Price is off BTC-E.
2014/02/05 - Fixed constant restarting bug.
2014/02/01 - Cleaned up VPS's HDD to allow bitcoind to continue running (Ran out of space)
2014/01/29 - Changed required confirmations from six (6) to two (2).
2014/01/08 - Added a bunch of new games (CS:S & GMOD, Portal 2, The Cave, Natural Selection 2), also restocked two old games (CS:GO and Rust)
2014/01/08 - First, 100% automated, sale went through. Although, I did wake up to three PMs from the user with "It doesn't work", "It stole my money", then, finally, "Oh, wait, no, I got my game. Thanks!"
2014/01/07 - Added temporary error handler for when steamcommunity cookie's expire
2014/01/07 - Sold first game (Albeit, with a little help from me)
2014/01/07 - Added Counter-Strike: Global Offensive to game roster and assigned a price for it in the Database
2014/01/06 - Fixed a bug where under certain circumstances it would refuse an item URL.

Vouches:-

[spoiler][/spoiler]

Vouch for Automatic Coding. Just bought CS:GO from him went smooth and quick. Legit Member.

It works!

Thanks and +rep

Just purchased Rust. Works fine.

Thanks very much for this bot. I'll be using it again for sure

Proof:

Received now after two confirmations as promised!

Fluid method, Massive vouch!

Happy customer

Log from bitcoind:-

Code:

2013-12-25 20:17:10 runCommand error: system(/home/bitcoin/block.sh 0000000000000001add7cf0bbc4520992f0c9f4346391273f27a93513a806a27) returned -1
2013-12-25 20:24:11 runCommand error: system(/home/bitcoin/block.sh 000000000000000136b5f4be351bd98d799a71c649a502c209e99a284650f2b3) returned -1
2013-12-25 20:32:24 runCommand error: system(/home/bitcoin/block.sh 00000000000000022f1d81992f0ca2b1bd658075a61103155a63201e208e5583) returned -1
2013-12-25 20:40:50 runCommand error: system(/home/bitcoin/block.sh 0000000000000002217553b052adbf99474d83aea9b1333e5035868ddbc13bd1) returned -1
2013-12-25 20:51:24 runCommand error: system(/home/bitcoin/block.sh 000000000000000011071fde5c66d3c5c50b88795665bd51858b1a4aada4d27b) returned -1
2013-12-25 20:51:51 runCommand error: system(/home/bitcoin/block.sh 0000000000000003064199f07fbc4fcadc7894403983525f77e2b447289eb9d6) returned -1
2013-12-25 20:54:32 runCommand error: system(/home/bitcoin/block.sh 000000000000000202e23278efb3fea7c261ee7186de389e1594285f54bbf85c) returned -1
2013-12-25 20:59:44 runCommand error: system(/home/bitcoin/block.sh 000000000000000349b3b84fedc6be1a7ebd20f27377d08f2fda2f1036e83af1) returned -1
2013-12-25 21:05:37 runCommand error: system(/home/bitcoin/block.sh "0000000000000002591fda47c52e3f816031328bdbfeb9f68d67eebb9968baa8") returned -1
2013-12-25 21:05:38 runCommand error: system(/home/bitcoin/block.sh "0000000000000002e14e03f1162885d74e1d39c9016401e537c9a62c2558d158") returned -1
2013-12-25 21:14:39 runCommand error: system(/home/bitcoin/block.sh "000000000000000374a7b6359cc993d3638c72c14d8c7529fef7e6e7e545bffb") returned -1
2013-12-25 21:27:20 runCommand error: system("/home/bitcoin/block.sh 00000000000000034091377f6269b6ac3efaecb5e84f9d7358a851a08241a3dd") returned -1
2013-12-25 21:43:21 runCommand error: system("/home/bitcoin/block.sh 00000000000000002df90422830562c3435520d69a1d51689acbb1253ba5ae3e") returned -1
2013-12-25 22:00:58 runCommand error: system("/home/bitcoin/block.sh 0000000000000000e54087f1dbb7c0d2c5bf29cd20906ad458417ea977e03b4e") returned -1
2013-12-25 22:16:59 runCommand error: system("/home/bitcoin/block.sh 0000000000000003521d838126ca43cb8ac4dd6f4f5f5e290b8efbb6e11fd2c9") returned -1

As you can see, I've tried lots of configurations. Here's me running the command myself:-

Code:

[bitcoin@steam .bitcoin]$ /home/bitcoin/block.sh "000000000000000374a7b6359cc993d3638c72c14d8c7529fef7e6e7e545bffb"
[bitcoin@steam .bitcoin]$

As you can see, works fine:-

Code:

[bitcoin@steam ~]$ cat block.log
000000000000000374a7b6359cc993d3638c72c14d8c7529fef7e6e7e545bffb

The block.sh:-

Code:

[bitcoin@steam ~]$ cat block.sh
echo "$@" >> /home/bitcoin/block.log

Any help? I can't work out why it refuses to run.

EDIT:- Nor this:-

Code:

2013-12-25 22:53:32 runCommand error: system("/usr/bin/bash" "/home/bitcoin/block.sh" "00000000000000025efa4d291485de8c34136c3d0d6b2cfd487514b4f81c27c5") returned -1