Topic: [TEST RELEASE] Cryptonite binary for linux (NEW: Qt and Windows builds) - page 23. (Read 19296 times)

today its not enough, but i am working very hard on that

too much or not enough rum? 

lol don't mind the n00b who can't be bothered to read the OP. . . I'm gonna go sulk in the corner now

use ./cryptonited -testnet

You must run all commands with -testnet. Main net is not enabled.

ok FINALLY got this bugger to at least try to run and now I have new issues. This is a copy from my terminal from trying to get the daemon started. What should I try next?

New release is up MD5 77adf711622ab51ae5403173e2ade324  Support for signing multisignature transactions has been added. Not exactly for the faint of heart but it does/should work. Also note that the next release will be adding a new rules to transactions. It will no longer be possible to send identical transactions (same amount, same sender, same destination and same msg) within the same block. This is to fix a malleability problem in multisignature tx. Most likely some blocks like this exist in the chain so it will probably end up forking around height 1440.

How to do it:

./cryptonited -testnet createmultisig 1 [\"mkNXTfTfNZv9LxuAhAbYpyQcNcZpgyTP3M\",\"mjGTLqJS2m5DtFUYSYxNwg9BNkj9uuHLC4\"]
{
    "address" : "mj6MjsCNGk7HdvJWdJgwsFsHzd7vUWAo9P"
}

Where the 1 is how many signatures are required to spend from the address. Can be any number > 0. Then there is an array of addresses corresponding to "authorized" senders. This command produces an address. Anybody can send to this immediately.

Spending the multisig is more difficult. First you must create a raw unsigned transaction where the input is the the multisig address. Outputs can go anywhere, different multisig addresses, whatever.

./cryptonited -testnet createrawtransaction "{ \"mj6MjsCNGk7HdvJWdJgwsFsHzd7vUWAo9P\":\"2.00100000ep\" }", "{ \"mjGTLqJS2m5DtFUYSYxNwg9BNkj9uuHLC4\":\"1.00000000ep\" , \"mkNXTfTfNZv9LxuAhAbYpyQcNcZpgyTP3M\":\"1.00000000ep\" }"

This returns a really nice hex string of the transaction. Like:

01000000012739acce5019c9a47a15b3b7a225eba9e8605a2fa048ed0b00000000000200e1f5050 0000000292282fe5bb40fc92d45d4091ec975e6318ba62600e1f5050000000035409211d7abd7ec 5e75497a46453ce256e47e0a000000000000000000

Then to prepare the transaction for signing you would run:

./cryptonited -testnet setuprawtransaction "01000000012739acce5019c9a47a15b3b7a225eba9e8605a2fa048ed0b00000000000200e1f5050 0000000292282fe5bb40fc92d45d4091ec975e6318ba62600e1f5050000000035409211d7abd7ec 5e75497a46453ce256e47e0a000000000000000000" "{\"0\":[1,[\"mkNXTfTfNZv9LxuAhAbYpyQcNcZpgyTP3M\",\"mjGTLqJS2m5DtFUYSYxNwg9BNkj9uuHLC4\"]]}"

This command also requires a description of the multisig address. Both authorized users and the number 1 again signifies the number required to send. Then it will generate:

01000000012739acce5019c9a47a15b3b7a225eba9e8605a2fa048ed0b00000000290035409211d 7abd7ec5e75497a46453ce256e47e0a292282fe5bb40fc92d45d4091ec975e6318ba6260200e1f5 0500000000292282fe5bb40fc92d45d4091ec975e6318ba62600e1f5050000000035409211d7abd 7ec5e75497a46453ce256e47e0a000000000000000000

Life is easier from now on. Signers don't need to know the multisig construction anymore because it has been encoded in the transaction. So you pass the hex around to people with the keys to actually sign the thing and run

./cryptonited -testnet signrawtransaction 01000000012739acce5019c9a47a15b3b7a225eba9e8605a2fa048ed0b00000000290035409211d 7abd7ec5e75497a46453ce256e47e0a292282fe5bb40fc92d45d4091ec975e6318ba6260200e1f5 0500000000292282fe5bb40fc92d45d4091ec975e6318ba62600e1f5050000000035409211d7abd 7ec5e75497a46453ce256e47e0a000000000000000000 "{\"0\":\"1\"}"

Here the last JSON object simply describes that the first input of the transaction is a 1 required multisig. It will then spit out something like:

{
    "hex" : "01000000012739acce5019c9a47a15b3b7a225eba9e8605a2fa048ed0b00000000560105b5a0581 197f36e2d44311e6b242db0142334f784a30b75ce5922443ec43f3dcda0e10d58571ee3515e5792 af04fc106c56510812a0780f6261b6f2539f66c8d6292282fe5bb40fc92d45d4091ec975e6318ba 6260200e1f50500000000292282fe5bb40fc92d45d4091ec975e6318ba62600e1f5050000000035 409211d7abd7ec5e75497a46453ce256e47e0a000000000000000000",
    "complete" : true
}


If complete is true, then the multisig transactions have been sufficiently signed for submission. If not, this hex must be given to the next user for further signing.

I think when you do a wallet dump/import it starts using a new address for mining. But at least now we know everything is working properly and you understand the internals of it a bit better now.

listaddressgroupings shows:

[
    [
        [
            "n4A14pgYCpYxpMSRN6UrVVM4zqCGtNX254",
            "0.00000000ep",
            ""
        ],
        [
            "n4AooGm5c5swoGnQptQrZdGyMgFdJQm7MZ",
            "10000.00000000ep",
            ""
        ],
        [
            "myoq946jrvuBCcHwzYV1cQV68Bdw1cVbjd",
            "6058796.41974716ep",
            "mrvegas"
        ],
        [
            "mhHLDJ2EG4ms3KtKsudEmaX8VTbLSt3ioh",
            "3168655.53856189ep",
            ""
        ],
        [
            "mt9sRVQe5yqpZoJEx9BVSgaRBhqot9MosX",
            "962181.23207365ep",
            ""
        ]
    ]
]

I thought that i only had 3 address and they were all under mrvegas.

I didn't know I had mhHLD and mt9s. To many addresses

What you have are multiple accounts, you appear to have the default one and one called "mrvegas", and each of those accounts probably holds several addresses with different balances. I believe that using sendtoaddress just picks addresses randomly from all your accounts. You should be able to see a list of addresses in all your accounts and their balances with the following command:

./cryptonited -testnet listaddressgroupings

my head is spinning lol, sorry if i confused you guys but i wasn't sure what was happening, i thought it would send from my main wallet if i didn't specify which wallet to use and the listbalances was throwing me off

That's because myoq obviously wasn't selected as the sending address, so the balance of that single address didn't change.

There's a lot of weird things happening here. First you must realize there can be several addresses associated with a wallet account. So for example, i have:

./cryptonited -testnet getaddressesbyaccount ""
[
    "mkNXTfTfNZv9LxuAhAbYpyQcNcZpgyTP3M",
    "mjGTLqJS2m5DtFUYSYxNwg9BNkj9uuHLC4",
    "mvGdVGdFDxg79RoiE8Yt5vL3Mb15n63St9",
    "mpJmL8TeKiSfKjnJ6csPuva6q9sdPtVJYM",
    "mzH8eUnXnJTSVEgnFVf7GU2cCbJucGoji7",
    "mmmkMYrqzqVmsALKfsdjSHDGWJW9VKtUhw"
]

You seem to have several named accounts so this situation is even more complex. The balance shown by getinfo is a summation of all addresses for which keys are known, so to get reasonable correlation you would have to do listbalances on every single address. Also these RPC commands report different notions of balance. Getinfo returns a balance created by taking any confirmed deposits/withdrawals and then subtracting any outstanding withdrawal transactions it sees. Listbalances on the otherhand, only works on transactions that are actually in the block chain. Outstanding transactions sitting in memory pool do not effect this balance.

Also keep in mind that when doing a sendtoaddress, it is not possible to specify the addresses used for the origin of the funds. It is not even possible to specify the named account used as inputs although sendfrom pretends to take such an argument. This I think needs to be fixed but it is actually a left over present from bitcoin's awesome code. This can lead to very strange things, especially when sending to yourself as tx inputs and outputs could end up being the same address, which is actually an invalid transaction. Even if you get lucky and the code creates a valid transaction, get info balance can get very weird. Now it sees unconfirmed withdrawals, which get applied immediately, but the deposit won't take effect until mined. So sending to yourself seems to temporarily reduce net worth.

yep, n4A0 looks good now but look at my above post where i sent you 1000000, my balance didn't change, it is still the same before and after i sent you the coins

Ok well using sendtoaddress will randomly select some of your addresses to send coins from, so it's highly likely n4Ao was emptied, because I can see you've made a large number of transactions in the last hour.

Yes it's now showing a balance of 10000 for me. Looks like everything is working smoothly. If you run listbalances again on n4Ao you should get the same thing.

pretty sure, i will send 10000.00000000ep to there again and then i won't do anything with my client

my balance:
[
    {
        "address" : "myoq946jrvuBCcHwzYV1cQV68Bdw1cVbjd",
        "ours" : true,
        "account" : "mrvegas",
        "balance" : "6058796.41974716ep"
    }
]

sent:

./cryptonited -testnet sendtoaddress mpM2UCQV6PmW9gGDaZY1oMFas1ceEWTSVH "1000000.00000000ep"

{
        "account" : "",
        "address" : "mpM2UCQV6PmW9gGDaZY1oMFas1ceEWTSVH",
        "category" : "send",
        "amount" : "1000000.00001000ep",
        "fee" : "0.00001000ep",
        "confirmations" : 4,
        "blockhash" : "00000335ed694e3958e72af076edd817815b1c897d4ce6a6795fd850e6e4fb15",
        "blocktime" : 1402372732,
        "txid" : "c6900d7dccb757e37f8104816bca6de0fc7b553912780f95d94699383ae3fe5e",
        "time" : 1402372663,
        "timereceived" : 1402372663,
        "lockheight" : 1679,
        "msg" : ""
    },


balance shows:
[
    {
        "address" : "myoq946jrvuBCcHwzYV1cQV68Bdw1cVbjd",
        "ours" : true,
        "account" : "mrvegas",
        "balance" : "6058796.41974716ep"
    }
]

Are you 100% sure you didn't empty out n4Ao?

Ok well one issue here is that getbalance doesn't take an address as an argument, so you're using that wrong and that's probably causing a lot of the confusion. But why exactly n4Ao evaporated is still unclear...

Yeah something changed a few minutes ago, me and catia were showing a balance of 2100 for n4Ao but now we're getting 0 like you. One good thing is that it appears we are all in sync now and showing the same thing.