There is really no need to upload the document itself (just store multiple copies all over the place) - if you want "proof" of "first publication" of the document then you just want to publish the hash of it.

Mind you anyone could modify the document and publish the hash of that so publish the hash before you publish the document itself (i.e. wait until several confirmations before actually publishing the document anywhere).

If you are hoping to use this as some sort of protection of copyright understand that this has never (AFAIA) been tested in any court yet (so I wouldn't be 100% confident that doing this will have protected you).

Looks interesting although from the "How secure are incoming funds?" FAQ I found this:


Am guessing you meant "signing".

So basically for incoming funds you can use "listunspent" for the wallet determining account balances according to specific addresses (and adjusting your RDBMS account balances accordingly) and then move the funds to cold storage periodically.

So basically you need an index for Address and User (which presumably is only unique with the combination as each user should probably be encouraged to use different addresses for each deposit).

To handle re-orgs you might want to keep two balance figures one for amounts already shifted into cold storage and one for the total current set of UTXOs for each user and you'd probably only want to move into cold storage those UTXOs that are older than any re-org you think might occur (say 100 blocks to be safe even if a huge fork occurs).

You might also want to keep a third balance of "unconfirmed funds" just so a User can known that funds they have just sent are "on the way" (without them having to use blockchain.info or something else to check).

I think perhaps look into running an Electrum server https://roll.urown.net/server/bitcoin/electrum-server.html (and https://github.com/spesmilo/electrum-server/) as it will index the UTXOs by address (the key thing needed really).

Note that it also requires "bitcoind" to be running (so you'll need a lot of disk space and presumably some decent hardware as well although if you are planning to service thousands of users am guessing you would already be planning for that).

The "listunspent" output includes a "spendable" attribute (which I assume will be "false" for watch-only addresses). So you can determine the total balance and the "immediately spendable" balance also (if that is the concern).

Bear in mind if you do use a "bitcoind wallet" then you are going to have big problems once it has hundreds of thousands of addresses (from what I've read from others it doesn't scale well).

Although I've not looked into the code my guess is that even if you provide "listunspent" with a set of addresses it will iterate through every UTXO that the wallet contains (so will get slower and slower as the UTXOs increase).

Although I think it is a pity that "listunspent" (assuming some sort of indexing flag has been put into the config) can't be used to find UTXO's for any address the main problem that you have in trying to link "bitcoind" to an external RDMBS is the whole "re-org" thing.

In the RDBMS world once you "commit" a transaction you can no longer "roll it back" but in the blockchain world this is simply not the case - thus marrying the two technologies is always going to result in some issues (as are often reported about for blockchain.info).

For the Bitcoin wallet I developed I have a "Check Balance" button to issue a "listunspent" in order to make sure it keeps in sync (of course that check could be automated but it would still need to be done prior to trying to create a new tx just in case the UTXO set has changed).

You most likely do not want to use the "bitcoind" idea of "accounts" (it is not the same idea that anyone who has ever done bookkeeping could make any sense of) and the wallet has scaling issues.

I think you are probably best to use the RPC to extract UTXO information from "bitcoind" into accounts that you keep in an RDBMS (from memory that will require a special flag for indexing but admittedly I haven't actually used that so you'll need to read up on exactly what that does).

The key command to retrieve UTXOs is "listunspent" although normally that will only output UTXOs that belong to your "bitcoind wallet".

Another very important thing to understand is you need to keep your RDBMS accounts "in sync" with the blockchain (small re-orgs of one or two blocks do occur and you should be very careful about unconfirmed txs).

EDIT: Hmm... it seems you still can't do "listunspent" for an address that is not in your wallet (am rather surprised that hasn't been added as it makes sense for "bitcoind" to have that feature so people don't resort to using things like blockchain.info). The indexing flag is only for txid lookup (which can be problematic due to malleability as mentioned).

Thank you very much for the code and I will look into adding "libsecp256k1" to my project (added to the "to do" list).

As no-one has been in contact in regards to this offer (and it has been months) I have decided to now use the BTC for other purposes.

There are loads of articles that are basically unrelated to Bitcoin appearing in the Press section.

You'll notice that the posters are earning money from this and of course this forum mostly encourages people to earn money by posting crap!

I expect soon like most other parts of this forum there will be no Press posts worth bothering to read either.

Although the CIYAM Wallet is not currently being used (except for testing by myself) I am wondering if I could get some help to change my ECDSA signing (assuming it isn't correct).

The code is here: https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L511

I'd appreciate a link to let me know how to fix it if it isn't right.

(can it be done using OpenSSL or do I need to include the Bitcoin ECDSA code to get it right?)

I actually have a sample application for messaging which I'll probably set up for public "playing around" under ciyam.org in the coming weeks.

But what I can show here is a simplified version of the "transaction log" to clarify how it works at that level:


This would be the tx broadcast to create a private message (it would be encrypted using AES from the hash of the creator's password that is salted and put through X rounds of SHA256).

Note that at this point the message is in a "draft" state (and could be updated by its creator if so desired). So the blockchain is acting as a shared storage for draft messages.


This would be the tx broadcast to send the private message to 54321 (there would be one of these per recipient in the case of multiple recipients). The content would match that of the first tx but would now be encrypted using a key that is derived from an ECDH shared secret (so that that recipient can decrypt it).

The rest of the record's data is cloned from the initial one (and the initial record would now been changed to a "sent" status so it can no longer be updated). It should also be noted that the second record's content cannot be edited (by any party) only some non-essential state (such as a "read" flag) would be permitted to be changed.

Hmm... did I intimidate any potential posters?

The commit for the Message package changes has now been pushed (and it is a big one).

For now I've decided not to do the icon thing (mostly because I can't work out what would be best to use) but I think having an Encrypt checkbox is reasonable enough for now.

Some further testing to happen over the weekend then I'll start work on the Blog package.

I think it was probably a pity that Satoshi actually did that (of course you know it was to show that there was no premine) as unfortunately his approach has been used by others and then extended through other approaches (I even worked out how to encode information in the sigs themselves although I've never actually used it live - come to think of it that is actually perhaps a better approach as it is just reducing the signature entropy a little and doesn't actually waste space).

It is inevitable that such pollution is going to happen and limiting dust is (at least for now) about the only reasonable method to preventing the UTXO set getting too large.

Whilst there have been some very interesting developments over the last couple of years in regards to consensus ledgers and "Turing complete" smart contracts there has actually been little to zero change in the way that people are creating software.

The CIYAM project has always been focused primarily on changing the way that software is created and this process has been described as Software Manfacturing for very good reason. In CIYAM applications there is simply *no manual source code* created at all - all the source code is generated (and if you think you couldn't create something that works well and looks okay when it is 100% generated then I suggest you take a look at http://ciyam.org/open).

This same approach is being applied for the creation of CIYAM blockchain applications (and steady progress is being made which can be followed here: https://bitcointalk.org/index.php?topic=598860.0).

Having created Automated Transactions (http://ciyam.org/at) and helped with it being implemented in two different blockchains (with two different code bases) I have come to the conclusion that it (and similar technologies such as Ethereum) are really not going to be the "way forward" (they have been an interesting experimental step though).

Running a VM (be it a Java-like one like Ethereum or a virtual CPU like AT) is basically slow - and when it is being "instrumented" (in order to limit its steps according to an account balance or amount of "fuel") it is actually even slower.

But do we need to actually do this in order to implement generalised smart contracts?

In my opinion we do not. A much more efficient approach is going to be to instead instrument "operations" that are described at a much higher level (and implemented by a generalised application server).

Using SQL is a very high-level method of working with an RDBMS but unfortunately does not enable any tight controls in terms of efficiency (i.e. you can easily create a very inefficient query that would tie up both CPU and I/O resources), however, if you have a very high level approach that does enable tight controls you can achieve such efficiency.

So such an approach won't be exactly like SQL but will be somewhat similar (with tight controls in the application server to prevent inefficient operations from being processed) and this is exactly what the CIYAM application server was designed to do (even before I'd heard of Bitcoin).

Therefore in my opinion the future of consensus applications is not going to be low-level VMs but instead a very high-level approach.

Feel free to discuss and disagree but any trolling, insulting or pointless posts for the sake of ad-sig posting will be deleted.

The Message package rework is almost complete (a commit will most likely be pushed tomorrow after some final tweaks and testing).

What is really nice now is that the the end-user doesn't need to do anything to encrypt the content (it just happens automatically although there is an Encrypt checkbox that can be unchecked if one purposely wants to send a message that is not encrypted).

It might also be useful to add an icon to the message to indicate whether it is encrypted (have just added that to the "to do" list for tomorrow).

And maybe you aren't aware that nothing is free (everything that appears to be is actually gathering data for either the NSA or private companies).

^ From a guy who clearly is a fan of Google who are not in the business of giving away all of their money to "make things even for everyone" either.  

It means very little to Bitcoin apart from possibly the stuff that was introduced that uses CA certs (which I've not even heard of anyone using so far and which is not really a core part of Bitcoin).

Bitcoin itself uses ECDSA and doesn't use any sort of Diffie-Hellman keys.