Perfect deal. Exchanged successfully, thanks.

turned out the largest disc usage was from database logs 
They are no more, and client seems to be ok with their passing 

Over the last 2 years, I have been running a bitcoin service.
Now the disc usage is getting out of hand, and I am wondering if there is any improvements in that in newer versions?

The one I am running is quite old (it does not have access to any bitcoins), and since I am using a custom patch, it may not be so simple to upgrade.

Also what amount of disc usage is acceptable atm ?

Currently I have 20GB used just by .bitcoin

Hi,

You need to run a modified bitcoin client that does the calling of tx.php.
The patch is linked from the bitping page, but im afraid its quite a few versions back from the main bitcoin tree, so it may not cleanly patch up against the newest version.

https://github.com/MORA99/bitcoin (Patch by stucpp)

Hmm, found a bug in the monitor code, that caused some addresses to not be detected 
It should be fixed now, will test again.

Did you create the order after the payment was sent (but before it reached 4 confirmations) ?

I am currently running a test to check if theres anything wrong with the system.
Which informations are you looking for in history ?

Mine worked today also, got the game in less than 30minutes

Tried to use it from both FF and chrome today, both got stuck at "checking information" after entering game url, email, btc address and accepting price...

bummer

Well the "secret" vs non secret is really just symmetric or asymmetric encryption.
In symmetric the same key is used to encrypt and decrypt, in asymmetric a public key is used to decrypt data signed by a private key.

We can make asymmetric without having to go the PGP route, but I am not sure if its really needed, the users still need to protect them selves against a server compromise, by using more than 1 service, or looking up the data on a blockexplorer(of cause not everyone will actually do that).

How do you propose to validate the content without a secret ?
-Not only the sender, but also that the contents have not been tampered with.

If the server is compromised, all bets are off, but the user secret means you need to know url, address and secret to fake a call.
If that secret is a user "defined" one, or a ssl key or something else, is maybe the same.

The raspberry is powerful enough to handle the bitcoin verification itself, however may lack network connectivity.

The triggering of a output based on a bitcoin payment is easy enough, use any of the notify services to call your url and verify the data.
Can be made to not require a incoming connection if its behind a firewall etc.

But ofcause that requires the monitor service to be running, and then you might as well do it without the bitcoin part.
Not sure if any of the light systems are opensource and used widely enough to be an option ? (closed source propriety servers are not)

isnt escow normally used when exchanging btc for something else ?
So while you can verify that a BTC payment was made, you cant verify ie. if the parcel was shipped.

Well that depends on minimum bet, maximum bet and wallet size

Say minimum 0.01BTC max 1000BTC wallet ~1300BTC

0.01
0.02
0.04
0.08
0.16
0.32
0.64
1.28
2.56
5.12
10.24
20.48
40.96
81.92
163.84
327.68
655.36
BUST

Thats 17misses in a row, absolutely possible, however fairly unlikely.
The casino can limit the betting range, but the bot could just jump tables.
And since its a bot, even 0.01BTC per win will be fine, if it can just do 1 win per 5minutes thats 2.88BTC per day per bot/played table, they can even share money pool if the deposit system accepts a low amount of verifications, or you could have bots continuously sitting at different tables, so when the 0.01bot looses a 0.64bet, the next bot takes over at a higher stake table and the first bot starts over on a new round, that way you dont need to move the big cash around.

Ofcause this is not practical, since the risk is alot higher than the gain, a 1000BTC risk for maybe 10BTC/day, you might as well play it all on red and wall away

Yes that system was what I meant, what do you mean with "dont even need to try" ?

The published hash idea is pretty neat, would work well for most games, as long as the hash is complex enough.
(0xAA 0xAA 0xAA) would be pretty obvious for a 3 wheel spin thing.

Perhaps a (signed) version field would be useful, to allow for future breaking changes.

Not sure how it could be made so a gradual changeover would be possible, a version field would only allow gradual upgrade of clients, once a server is upgraded, everyone gets v2 messenges...

Also do you have an idea about how it should be implemented in existing systems, where users are already using the old system ?

Well, while there is a C parser avaliable, most seem aimed at full blown systems, a sensor platform may have as little as 8MHz, 16KByte flash space and 2KByte ram.

However even those devices can cope with simple json, so its not a "must not have"

Good idea, then the receiver can also detect delayed notifications, due to outage of sender/receiver.
I suggest using a a standard timezone so we dont have to include timezone (zulu?)

Agreed, maybe a type field, to designate if the address is sender or receiver ?

I think some gambling sites would like it, to save an extra lookup to find the information, ie. the lotterly ended at block 27 which was the first block in Januar 1970.

As far as I know, it is a bit easyier to find a hash collision with MD5 than sha1, and bitcoin uses some form of sha.
But as a signature, I dont think the difference is all that big, I use sha1 today, but can switch to md5 if someone that knows the systems better, agrees that there is no security problem in it.

Good idea, Agreed.

Is there any specific reason you would rather post a json body than use the key=>value system ?
Using key=>value allows PHP scripts to access the data as $_POST['key'], instead of having to go with a json parser, and "internet of things" will have a hard time parseing json.

And how do you plan to handle abuse ?
For 10$ you cant answer too many abuse reports per customer, well hardly 1.
And then there's the ones from your ISP/DC that you have to answer to keep your connection/server.

Not shooting it down, a basic web hosting service with BTC processing would be most welcome, but its not complex enough, so any reasonably competent sysadmin can copy the concept and maybe even at lower prices (After all a standard server in germany comes with 3TB of space and 16GB ram with almost unlimted bw for 100$/month)

As discussed briefly in another bitcoinmonitor thread, some form of standard for HTTP Post notifications would be beneficial for all.

The goal with this thread, is to agree on a minimum subset of variables, and signature generation, that all services will implement, so that no matter which service you use, the basic function is the same.
This would allow shops to pick a payment module, and payment notification service(s) independently.

The standard will need to define which fields are mandatory, and which fields are used in the calculation of signature, in which sequence and how the signature is calculated.

To start off, heres my bid for mandatory fields
The names are only suggestions.

• to_address
• amount (in satoshi to avoid any radix point confusion)
• confirmations (Number of confirmations at the time of the notification, not necessary the requested amount)
• txhash (the hash of the transaction that contains the payment)
• block (height of the block that contained the tx, -1 if unconfirmed)
• signature (see below)
• service (name of the service, could be used in shops where 2 of 3 notifications are needed, before its accepted)
• IP (public ip of the service, since this is included in the signature, a replay attack has to be done from the same IP (yes it can be spoofed))

If we can agree on a hashing algorithm, thats cool.
But since we may not, and any algorithm in time could become obsolete, I think a field to specify the used algorithm is useful, also this could allow services to make a easier CRC, for the "internet of things", like xor/crc8.

• algorithm (sha1, md5, crc32, etc.)

To keep it simple to implement, we should only list the ones that are likely to be used, since any payment system will need to implement all, so if possible, we should keep to the most standard ones, that are likely to be available.
I would suggest using PHP as the reference, since its pretty popular, and contains quite a few hashing systems.

I hope we can agree on a sequence, so that the system does not need to load a list of fields to calculate the signature.

After security checks, a signature validation could be performed in PHP
The service name does not need to be included in the calculation, since it would be used to lookup the secret value, so if its changed the validation will fail.

Any service can add extra fields, like btc_amount, from_addresses, datetime, etc.
Since the signature does not include those fields, the same code can still be used.
If those fields contain data, a middle-man would have interest in modifying, a second signature could be added.


This is only my suggestion, please feel free to comment and explain your view on how it can/should be done.

Sure, or another thread for the discussion part.

For the rough part we seem to be using the same idea, some values concatted together with a secret value and hashed, the values and hash algorithm is different, but...