1) Attendees at a Bitcoin event are each given a physical Bitcoin (from a trusted source and perhaps in paper form to reduce overheads) that contains zero balance.

2) Each attendee then sends an specific amount (say 10 BTC) to their physical Bitcoin's public address.

3) Swap physical Bitcoins of the same amount with another attendee (after checking balance and making sure private key is still hidden).

Anyone tried this yet?

After playing around with vanitygen and spending a while looking for "available" vanity addresses by searching blockchain.info I discovered that already a very large number of plain english words have single tx's with a 0.00000001 BTC balance.

To get a good idea of what I'm referring to take a look at the following tx:

http://blockchain.info/tx-index/1009186/4e7b84a7ee19b7ea9f2d69fcb2734fb096cb012b413f8897b4f42871b225faba

So it seems to me that someone went rather gung ho with vanitygen to try and own all the simple "firstbit" addresses they can possibly get. But what really can you do with them?

(maybe I can expect to see small amounts appearing in my wallet from these addresses after this post)

Code:

1WhoaKiRPrZWRWxjCcs4J2NTnyM9nezTq
1LikEsho5kfz1Ex9pw4keH9DYQ6S9gAWNH
1siLLyaisPRd8BsKsxmikSMkuw3KpxDh6
1PoStsmYCvbqsFJxdKC1h8gyhBEJLvAcN8
1LiKEc4Zx9AKcxT6xnYjtXzexweSwEYwpL
1TheSen7LCVi7dWW3hFN14SG2zn3MNdbM

Hopefully this hasn't already been brought up in the similar named thread already but I thought it might be worthwhile to start a new thread to discuss the merits of designing a meta-reputation protocol that works via tx's in the blockchain itself rather than discussing a specific WoT solution.

The following are some basic principles:

1) Each WoT system would have its own specific Bitcoin address.

e.g. 1SampleWoT

2) Each member joining the WoT system provides a single address that will be used for that system (and which most likely would also be the same address used for all other such systems).

e.g. 1SampleMember

3) In order to activate a new "account" a member sends (from their specifically chosen address) a small amount to the particular WoT address.

1SampleMember -> 0.09 -> 1SampleWoT

4) If the user provides sufficient proof to the WoT owner (such as GPG sig with signed copy of the user address) then a tx containing a very specific amount is then sent from the WoT to the user's account address to indicate it has been activated.

e.g. 1SampleWoT -> 0.00000011 -> 1SampleMember (where the last digit is either 0 or 1 to say added or removed and previous digits are reserved to identify the "type" of proof).

If say some other kind of relevant item/document was accepted by the WoT then this would have another specific amount:
1SampleWoT -> 0.00000021 -> 1SampleMember

and if this proof was later to be rescinded then:
1SampleWoT -> 0.00000020 -> 1SampleMember

5) Once the member has met the minimum requirements to use the WoT they would be able to create a "rating" record for another member (which they could locate either via the other user's specific address or by say their email address using the actual WoT application).

In order for the rating record to be accepted the member would next send a very specific amount from their address to the WoT address (where presumably this amount would be copied and pasted from the WoT application). One possible way for this amount to be determined is as follows:

Take the CRC32 of the member being rated's address as a decimal value then take mod 100,000 and divide by 10,000,000 and add a rating multiplier and min. fee.

if the allowed "multiplier" values were:
.00000001=-8
.00000002=-4
.00000003-=2
.00000004=-1
.00000005=+1
.00000006=+2
.00000007=+4
.00000008=+8

then you might end up with an amount looking something like:

1SampleMember -> 0.05123455 -> 1SampleWoT

(with 0.05 being the min. fee required to send a rating, 12345 being the modulus of a CRC-32 of the destination address and 5 meaning +1)

Assuming that the details are correct then the WoT would then create a tx to the destination members address as follows:

1SampleWoT -> 0.00000005 --> 1OtherMember

The big advantage of this idea is that all WoT actions are audit-able through the blockchain itself allowing different software implementations to be written that can perform all their calculations (in very different ways if desired) without having to rely upon any 3rd party DB.

Apologies if this idea has already been hashed out before (did try some searches but maybe my Google-fu is not so strong).

I was thinking about the issues of ownership and virtual property and the following idea came to mind:

Consider a Bitcoin address that contains a small balance:

1ownerXXX 0.01

Now consider some sort of XMLish "virtual property certificate":

[property]
<service>WoW
 <item>Player
  <role>fighter
  <strength>1000
  <experience>10000
...
  <token>xxx123456
 </item>
</service>

and the use of the new "sign a document" feature of Bitcoin.
(so the above document is signed by owner of 1ownerXXX to prove ownership)

Assuming that the token "xxx123456" can be checked with the online service to verify ownership and validity then if one player wants to transfer this "virtual property" to another player one could send the property to an escrow (yes 3rd party trust involved here so some sort suggestions for a decentralised alternative solution would of course be welcomed) as follows:

1ownerXXX ==> 1escroXXX

After this tx occurs the escrow creates an address for payment which if funded with the requested amount results in:

==> 1ownerXXX ==> 1escroXXX ==> 1newowner
1payment ==> 1oldowner

and if full payment not met by agreed time then:

==> 1ownerXXX ==> 1escroXXX ==> 1newowner ==> 1ownerXXX
(and possibly 1payment ==> 1newoner as a refund due to insufficient funds)

The actual service (such as WoW) will decide who the "owner" of the virtual property is by simply following the transfer from the original address to its latest owner via the blockchain.

The main point here being to use Bitcoin blockchain as a way of showing proof of ownership of virtual property.

Has something like this already been implemented (and if not why not)?

I recently upgraded to the latest release and after starting up bitcoin-qt (using Windows XP) I noticed this:



I think the text ("~207 blocks remaining") might be better off being just black although this is probably just a sign of my eyesight getting poorer with age.

Oddly enough if I put the focus to another window the text color changes to black (am guessing this must some sort of standard Qt "feature").

Other than that it is looking nice!


Cheers,

Ian.

I used the "sendfrom" expecting it (incorrectly now I know) to use the BTC from the receive address I had previously issued a "setaccount" for (instead it picked some other address not visible in the GUI).

What I am now wanting to do is to stop "listtransactions" from showing that particular "send" as belonging to that account (well more basically what I am wanting is for "getbalance" to match the balance that I see in blockchain.info/blockexplorer.com for the address I did the "setaccount" on in the first place).

So is there anyway to change the account for a specific tx?

I understand that coderrr's branch provides control over the addresses chosen to "send from" when performing a "sendtoaddress" and changes the RPC for "sendtoaddress" to the following:

sendtoaddress <bitcoinaddress>[:<sendfromaddress1>[,<sendfromaddress2>[,...]]]

From the perspective of being able to control the addresses I think it should also be possible (at least through RPC) to optionally specify the address to send change to. Syntax of the RPC command could be as follows:

sendtoaddress <bitcoinaddress>[:<sendfromaddress1>[,<sendfromaddress2>[,...]][;<changeaddress>]]

Also - any ideas when/whether the coderrr branch will be merged into the main trunk?

I recently imported a vanity address for my company (1ciyam3htJit1feGa26p2wQ4aw6KFTejU) into the current 0.6 version and gave this address the account/label name "ciyam" and moved some BTC into the address (so far so good).

Next I used the bitcoind "sendfrom" to send a payment out as follows:

bitcoind -rpcpassword=***password*** sendfrom ciyam 1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxY 0.25

but if I look at the vanity address in blockchain.info the 0.25 tx doesn't appear (the 4 tx's which you can see there now are an initial test one - a larger BTC input and then 2 tx's I did much later to adjust the balance according to what my own wallet was showing for the account).

If I do the following:
bitcoind -rpcpassword=***password*** listtransactions ciyam

then I see 6 tx's and a balance of exactly 100.

Am guessing that I've missed something fundamental here as I don't get why my "sendfrom" tx's don't show up when looking at the address under blockchain.info.

Can anyone please explain to me what I've misunderstood?

I imported a private key using bitcoind while bitcoin-qt was running (Windows) and although it appears that the import operation worked fine both bitcoind and bitcoin-qt hung. After ctrl-c from bitcoind still bitcoin-qt would not respond (had to kill the task).

I then restarted bitcoin-qt and luckily all seems to be fine - looking at debug.log showed just a bunch of blank lines between fetching blocks and the restart (so no indication why clients were presumably locked and why killing one process didn't unlock the other).

BTW I have had no problem doing "read" operations (such as listtransactions) with the GUI running or using setaccount (this operation is the first other "write" operation I've performed whilst running the two clients simultaneously).

A few years ago I grabbed a document put out by the government in China that listed "official translations" for Chinese dishes (it was created in the run up to the Olympic games) and put all of the translations (after a lot of manual effort in order to make them more consistent and concise) into an application whose purpose was to use this information as a starting point for creating translations for specific restaurant menus.

Back then I was trying to create a small business that would provide English translations to local restaurants and did get a bit of interest but it wasn't really worth the effort without the work being far more simplified (testing of several typical local menus would only generate around 20-40% of hits within the DB of known dish names).

After a few months of effort I ended up with over 3,500 dishes (where quite a lot are basically the same dish named slightly differently in Chinese).

I think now a better idea might be to develop a smart phone app which would operate using OCR and the DB in order to show you a translation of any dish name that you scan (if it can't find an exact match then the dish name can usually be pulled apart to identify the cooking style, flavouring and major ingredients).

The DB itself could also be greatly increased by crowd sourcing (perhaps for small BTC payments per menu) making it then more viable for using it with the app I developed to do specific translations.

If anyone has any interest in (and even better has experience with) developing such a smart phone app please let me know.

My wife had to re-install Windoze on her laptop recently and not realizing where a lot of her "application user data" is stored (the C drive which was wiped over) she lost everything that was there (which could but luckily didn't involve losing much of any value).

Maybe it might be an idea that when first started up from a fresh installation the user is prompted where to store the DB info (the wallet location in particular of course) as I know at least in her case she would be sure to have picked another drive to store the data on (as she does this for all other apps she uses when prompted).


Cheers,

Ian.

I have only recently started playing with bitcoind (which is most likely the way I intend to use Bitcoin in my own software) and got rather confused with the "account" label when using the "listtransactions" command (see https://bitcointalk.org/index.php?topic=66214.0).

After Pieter Wuille's help I was able to understand that the problem I was seeing was that the GUI displays account labels for Sent tx's that have been assigned to the "sent to" address whereas "listtransactions" only shows account labels for "sent" category tx's that have been assigned to the "from" address (or something at least close to that).

So in short you cannot in any easy way get the same output as you see in the Sent tab in the GUI from bitcoind. My proposal is to add an option to listtransactions so you can get the same output (both "account" output and filtering for "send" category tx's to be taken from the "sent to" address). Note of course this is an option and would by default be false.

The change is to the bitcoinrpc command listtransactions whose usage would become as follows:

listtransactions [account] [count=10] [from=0] [usesenttoaddresses=false]

When usesenttoaddresses is set true then the account mapping for "send" category tx's is to the sent to addr (rather than the current behaviour).

Link for suggested commit changes:
https://github.com/ciyam/bitcoin/commits/opt_use_sent_to_addr_for_acc

I don't have an environment set up for compiling Bitcoin (and am flat out doing other work) so for now I would be grateful for any comments or suggestions with the proposed change.


Cheers,

Ian.

I have just started playing with bitcoind (under Windoze using the 0.4.0 and running the GUI as the server) and noticed that when I did a "listtransactions" an entry like this:

...
{
    "account" : "",
    "address" : "1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6",
    "category" : "send",
    "amount" : -0.50000000,
    "fee" : 0.00000000,
    "confirmations" : 1234,
    "txid" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "time" : 1213411747
},
...

I wanted to put an account on the 1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6 address so I initially did this via the GUI (which shows up in the Address book fine) but it just stayed blank in the listtransactions output when I re-ran the command.

So I then ran the following:

bitcoind setaccount 1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6 name

and it created a new address (documented behavior if the account name is the same as it already has I read) so why can't I see the account when I do listtransactions?

Strangely enough if I run this:

bitcoind getaccount 1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6

then it returns "name" is one would expect.

Waiting now for 1 hour for this block to be generated (according to http://blockchain.info as well as what I observed looking at http://blockexplorer.com).

Is this kind of wait common (as I hadn't noticed it before)?

Just wondering about the wallet encryption and persistence when bitcoin-qt is started without a wallet (as in a new installation).

What I am wondering is whether "wallet.dat" gets persisted (with exclusive file access locking) with the private keys unencrypted before you actually enter the passphrase to encrypt or is the wallet information just held in memory until you shutdown the client?

Any Bitcoin tourists out there?

After recently acting as tour guides for family members before our wedding, my wife and I have decided to offer via this forum the opportunity for anyone interested in visiting Beijing to be able to pay for their entire trip (apart from air tickets) in Bitcoin (RMB conversion rates to be taken from btcchina).

We are not going to organise trips for large groups (maximum of six people) so we can provide flexible arrangements and avoid the need for hiring large buses.

We are not affiliated with any tourism company and will take people only to places that they are interested to visit (itinerary suggestions will be provided upon request). In particular you will not be taken to any shops unless you have asked to go there (this can be a big problem with budget tours in China).

The initial Bitcoin payment won't be necessary until arrival (we will meet you at the airport) and payment for each tour day can be made at the end of the day. We will provide receipts for all transportation, accommodation, tickets and meals and will charge a modest fee (around 5 BTC per day) for our services.

We have not yet set up a web site for this endeavor as we are just putting this out to test the water and to offer people another way to actually spend their Bitcoins.

For further information either reply here or PM me.


Cheers,

Ian.

I have read a few recent posts about using Bitcoin for some very different things such as for election vote tallying (with little or nothing in the way of any detail about how this can really work) and am not sure whether or not Bitcoin provides answers to the most challenging problems in this area.

To my mind most importantly one needs to ensure that each individual that is eligible to vote can vote, that no individual can vote more than once and that no authority can be (at least realistically) able to trace an individual's voting choice.

To my thinking this could be perhaps addressed in the following manner:

1) All eligible voters are sent an identifiable voting form (could be in the form of a small BTC payment made by the government that must be spent within a certain time frame).

2) An encrypted voting choice needs to be created by the individual (perhaps a newly generated BTC address created by your favorite party which would somehow need to be signed for the next step to work).

3) Encrypted voting choices to be anonymously exchanged by voters (with signature checks of these voting choices to ensure their validity).

4) Voting forms with the anonymous voter's voting choice are then returned to government (in the form of a BTC repayment).

I'm not sure if BTC is going to be a solution (and step 3 has perhaps little to do with it at all) but I think this kind of approach could lead to something quite important in the future.

Perhaps others can point out on any obvious faults and/or any better solutions to this idea?


Cheers,

Ian.

The following program (using OpenSSL 1.0.0a) is attempting to use AES to encrypt the contents of file "x" and output to "y" but under Win32 I get an AV in SEED_ofb128_encrypt upon calling AES_cfb128_encrypt.

I read the OpenSSL FAQ and did try adding the code calling the init functions and/or including applink.c (commented out below) but all to no avail.

Code was compiled as follows:
cl.exe /nologo /MD /GR /EHa /W3 /wd4068 test.cpp kernel32.lib user32.lib ssleay32.lib libeay32.lib /link

[test.cpp]
#include <fstream>
#include <iostream>
#include <openssl/aes.h>
#include <openssl/ssl.h>
//#include <openssl/applink.c>

using namespace std;

int main( int argc, char* argv[ ] )
{
//   SSL_library_init( );
//   CRYPTO_malloc_init( );

   int num, bytes_read, bytes_written;

   unsigned char indata[ AES_BLOCK_SIZE ];
   unsigned char outdata[ AES_BLOCK_SIZE ];

   unsigned char ckey[ ] = "thiskeyisverybad";
   unsigned char ivec[ ] = "dontusethisinput";

   AES_KEY key;
   AES_set_encrypt_key( ckey, 128, &key );

   ifstream inpf( "x", ios::in | ios::binary );
   ofstream outf( "y", ios::out | ios::binary );
   while( true )
   {
      bytes_read = inpf.rdbuf( )->sgetn( ( char* )indata, AES_BLOCK_SIZE );

      AES_cfb128_encrypt( indata, outdata, bytes_read, &key, ivec, &num, AES_ENCRYPT );

      bytes_written = outf.rdbuf( )->sputn( ( char* )outdata, bytes_read );

      if( bytes_read < AES_BLOCK_SIZE )
         break;
   }
}

If anyone can see any obvious problems with this code or the compiler options I'd really appreciate a heads up.


Regards,

Ian.

Hi all,

Just wondering exactly when the standard client will generate new keys in your wallet. Will it do so only exactly when the last key in the key pool has been used or will it do it before that?

The reason for the question (and depending upon the answer the reason perhaps for a change request) is that I keep my wallet encrypted using external software which via a script I use to run the client decrypts and after the client finishes executing automatically re-encrypts the wallet (I am not using the Bitcoin wallet encryption).

My concern is that if the new keys are only generated when the pool is totally exhausted then if something terrible happens to my computer whilst the wallet is being re-encrypted then I could potentially lose BTC that was received via a newly generated key (this would not be a problem if new keys were generated whilst a number of "old keys" are still available to be used first).


Cheers,

Ian.

Hi all,

After following a couple of recent problems on this forum that people are having trying to recover corrupted encrypted wallets that seemingly got this way due to Bitcoin being shutdown unexpectedly (although not whilst actually generating keys) has made me wonder why the wallet is being stored in the DB?

Is it because the wallet size is expected to be potentially be too big to buffer in RAM?

Is it because it needs to be written to at some other time apart from when issuing a new transaction?

Why not just store it in a text file (plain/encoded) which is read/written in its entirety when the need arises and kept closed at all other times.


Cheers,

Ian.