[TEST RELEASE] Cryptonite binary for linux (NEW: Qt and Windows builds)

[mrvegad]

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.

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

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.

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

[1715534726]

1715534726

[1715534726]

1715534726

[1715534726]

1715534726

[1715534726]

1715534726

[catia]

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.

[bitfreak!]

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

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

[mrvegad]

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

[bitfreak!]

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

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

[mrvegad]

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

[bitfreak!]

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

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.

[catia]

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.

[billotronic]

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?

Code:

r00t@Hoverquarters ~/Downloads $ ./cryptonited --daemon
Cryptonite server starting
r00t@Hoverquarters ~/Downloads $ Failed check

r00t@Hoverquarters ~/Downloads $ ./cryptonited --daemon
Cryptonite server starting
r00t@Hoverquarters ~/Downloads $ : Error loading block database.

Do you want to rebuild the block database now?

r00t@Hoverquarters ~/Downloads $ ./cryptonited --daemon
Cryptonite server starting
r00t@Hoverquarters ~/Downloads $ cryptonited: trieview.cpp:23: TrieView::TrieView(): Assertion `fread(&m_bestBlock,1,32,filein)' failed.
Error: signal 6:
./cryptonited(_Z9backtracev+0x1f)[0xa6342a]
./cryptonited(_Z14HandleSIGABORTi+0x31)[0xa63489]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x7f920d237bb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f920b80ef77]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f920b8125e8]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fd43)[0x7f920b807d43]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fdf2)[0x7f920b807df2]
./cryptonited(_ZN8TrieViewC1Ev+0xee)[0xbf35d0]
./cryptonited(_Z8AppInit2RN5boost12thread_groupE+0x4478)[0xa6d905]
./cryptonited(_Z7AppInitiPPc+0xba2)[0xa4ac53]
./cryptonited(main+0x29)[0xa4b29d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f920b7f9de5]
./cryptonited[0xa49ded]
cryptonited: /usr/include/boost/thread/pthread/condition_variable_fwd.hpp:46: boost::condition_variable::~condition_variable(): Assertion `!pthread_mutex_destroy(&internal_mutex)' failed.
Error: signal 6:
./cryptonited(_Z9backtracev+0x1f)[0xa6342a]
./cryptonited(_Z14HandleSIGABORTi+0x31)[0xa63489]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x7f920d237bb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f920b80ef77]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f920b8125e8]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fd43)[0x7f920b807d43]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fdf2)[0x7f920b807df2]
./cryptonited(_ZN5boost18condition_variableD1Ev+0x3b)[0xa4e56f]
./cryptonited(_ZN11CCheckQueueI12CScriptCheckED1Ev+0x3e)[0xb49f7a]
/lib/x86_64-linux-gnu/libc.so.6(+0x3c071)[0x7f920b814071]
/lib/x86_64-linux-gnu/libc.so.6(+0x3c0f5)[0x7f920b8140f5]
./cryptonited[0xa63493]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x7f920d237bb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f920b80ef77]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f920b8125e8]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fd43)[0x7f920b807d43]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fdf2)[0x7f920b807df2]
./cryptonited(_ZN8TrieViewC1Ev+0xee)[0xbf35d0]
./cryptonited(_Z8AppInit2RN5boost12thread_groupE+0x4478)[0xa6d905]
./cryptonited(_Z7AppInitiPPc+0xba2)[0xa4ac53]

[catia]

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

[mrvegad]

use ./cryptonited -testnet

[billotronic]

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

[mrvegad]

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

too much or not enough rum? 

[billotronic]

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

[bitfreak!]

It looks like someone has created a script for sending out tx's, that's great but please hold off on sending a lot of tx's for the next hour as we're currently trying to solve some issues. We will also soon be releasing the build which will require all nodes to discard all blocks after about block 930.

[billotronic]

geesh I can't win! ha.

Let me know when I can turn it back on sir.

[bitfreak!]

geesh I can't win! ha.

Let me know when I can turn it back on sir.

Lol no problem, shouldn't be very long now.

[billotronic]

ready?

[catia]

I think we are ready for you now. Download new client, MD5 775ddf55fa630ef37556a1ed6810dbd1. Delete cryptonite folder, save and restore wallet if you like.

Your script may have some problems now since it is impossible to have identical transactions in the same block. You can get around this by setting the message parameter to a random string or changing the amount of the transactions slightly.

We were trying to find a bug where transactions will show up with -1 confirmations in listtransactions. Some things were tried and it hasn't been seen in a bit, but no real solid explanation of what it was or how to reproduce it has been found. If you see this please send us your debug.log file.

[c18machine]

algo? pow?