[...]
At the moment it would be very complicated and time consuming to adopt a second sig aproach for me. reg
Jeez, then just don't use it. What was your point again? |
|
|
|
|
*subscribe*
Interesting. Hope I can go there personally...
|
|
|
|
You may be interested in pull requests 841 and/or 886, which add such functionality to the reference client. Nice. Seems to add much of the stuff I need :-) |
|
|
|
Perhaps a (signed) version field would be useful, to allow for future breaking changes.
+1 for the version field in the signed data. 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 ?
We have to support both variants, our own and the new standard. I am thinking to add a setting where user can check "old proprietary (obsolete) callback" and "callback according to <name to be found> standard". With the latter being the default for all new clients. So existing configurations will continue to work while all new users will per default get the new standard callback. |
|
|
|
Have a look at the bitcoin fork I made for www.bitcoinmonitor.net. Among some other stuff the rpc command "getBlock" is extended to include basically the full block information, including all transactions with inputs and outputs that are contained in a block. Also there is a new command "getAnyTransaction" which can be used to get information on any transaction known, not only to transactions which involve your own wallet. Also here all inpoints and outpoints are included. => https://github.com/TripleSpeeder/bitcoinHTH. |
|
|
|
To me, it's just a bunch of noise.
To me it's just a bunch of posts to increase the post count before the scam offers start coming. +1. Or he is a bot. |
|
|
|
|
Can you explain a bit on the implementation? Is this "just" a bitcoind frontend with bitcoind running on your server? Or is the concept similar to blockchain.info or strongcoin?
|
|
|
|
|
Well, after rethinking the JSON thing I changed my mind. I think Mora is right, we should make this as easy as possible and not require any additional libs/tools.
Also there is another point: For calculating the signature/hash you have to convert all parameters back to string anyway. So json gives you a real (big)Integer for e.g. the Satoshi amount but the first thing you need to to is convert back to string in order to check the signature.
Summary: /me votes for standard key=>value parameters.
|
|
|
|
Hmpf. Something is going wrong on the production system with the new build, while at home everything runs perfectly. Rolled back to the previous release, so withdrawal notifications are currently NOT available.
Issue solved in the meantime. I should have known not to deploy being tired in the middle of the night - forgot to start the new build of bitcoind and the old one does not provide all necessary parameters with the block notification... |
|
|
|
|
Hmpf. Something is going wrong on the production system with the new build, while at home everything runs perfectly. Rolled back to the previous release, so withdrawal notifications are currently NOT available.
|
|
|
|
I propose an additional fied:
"timestamp" which should be the date/time this transaction was observed by the monitoring system.
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?) Gaaah, i hate this timezone stuff. But indeed this should be un-ambigious a fixed Timezone. I am currently working on extending notification possibilites of bitcoinmonitor.net to support outgoing payments. To support this also for http callback we should keep the wording neutral, so "to_address" would become "address" and "amount" can be positive for incoming and negative for outgoing payments.
Agreed, maybe a type field, to designate if the address is sender or receiver ? I don't think this is necessary. It should be quite obvious: Negative amount -> Outgoing payment. Positive amount -> incoming payment. 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.
If sha1 is better for any reason - let's take it :-) No objection from my side. Proposal how to store the data in the POST body: Use a json string e.g. {
"signed_data": {
"address": "12r9JzPNnyWs2j1s9KLW5keqBr4kbJjxz6",
"amount": 122678000,
"confirmations": 2,
"timestamp": "2012-02-19 10:37:20.203541",
"txhash": "e0c84120068bfefddab051e751f3df963c4ed29e7b13eadac026e6f17f55fb06",
"ip": "127.0.0.1"
},
"signature": "38a25ec14b9ffcfe98938f3e35ac9cf41de2a971",
"service": "<service name here>"
<any additional information specific to service>
}
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. It has the advantage of allowing nested data structures. So like in my example we can nicely model an array of signed_data and it would be quite obvious which parameters to include for signature checking for everyone. With a flat key=>value structure it's not so obvious anymore and might lead to errors. Also json knows basic datatypes (strings, numbers, ...) so there is less risk of misinterpretation/wrong conversion. A json-parser is available in any language you can think of (see http://json.org/), and some/many popular languages have it already built-in. |
|
|
|
New Feature online: withdrawal notificationAgents can now be configured to check for incoming transactions (Deposits), outgoing transactions (Withdrawals) or both. Useful e.g. if you want to keep an eye on your savings account and want to be alerted if any fund is removed without your knowledge  This is available immediately for all types of notifications (currently email, newsfeed and url callback). Also a potential issue is now fixed which could result in missed transactions/notifications (happened when a new block was received which contains a transaction which has not been seen before as an individual tx message. Now whenever a new block is coming in the contained transactions are double-checked to make sure I don't miss a notification). I don't think this ever happened so far, though  Have fun! |
|
|
|
Thanks Mora, this is a great proposal, I fully support it! 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))
I propose an additional fied: "timestamp" which should be the date/time this transaction was observed by the monitoring system. I am currently working on extending notification possibilites of bitcoinmonitor.net to support outgoing payments. To support this also for http callback we should keep the wording neutral, so "to_address" would become "address" and "amount" can be positive for incoming and negative for outgoing payments. About the block number - Is this really necessary? I am not sure if it adds significant information. If not, i would omit it just to keep the list of parameters as short as possible. 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. While this is a very flexible approach it might make adoption of the system a bit more complicated. I think we should be able to agree on one algorithm. TBH I am lacking background knowledge to make an educated decision - basically I don't care which one to use. There still would be the option to put the algorithm specifier outside the common signed_data part, so special solutions would still be possible. 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.
Very simple proposal which i chose also for bitcoinmonitor.net: Alphabetical ordering ;-) After security checks, a signature validation could be performed in PHP if ($_SERVER['REMOTE_ADDR'] == $ip &&
$$algorithm($to_address.$amount.$confirmations.$txhash.$block.$ip.$secret) == $signature)
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. Proposal how to store the data in the POST body: Use a json string e.g. {
"signed_data": {
"address": "12r9JzPNnyWs2j1s9KLW5keqBr4kbJjxz6",
"amount": 122678000,
"confirmations": 2,
"timestamp": "2012-02-19 10:37:20.203541",
"txhash": "e0c84120068bfefddab051e751f3df963c4ed29e7b13eadac026e6f17f55fb06",
"ip": "127.0.0.1"
},
"signature": "38a25ec14b9ffcfe98938f3e35ac9cf41de2a971",
"service": "<service name here>"
<any additional information specific to service>
}
|
|
|
|
I've donated half a bitcoin, and will double my donation if you add functionality for addition and removal of an agent's watched addresses via an API call. Appreciated :-) This way, you don't have to constantly monitor hundreds of addresses that may or may not be in use, and I can ping you with a new address for every sale and remove it once it's done. Win/win situation. Bonus points if you can make it so that addresses not in use for N days are automatically removed.
Ha, this is exactly what I had in mind for the API! Like you said, availability of these features should simplify both ends. At the moment the API development is still in early stages as there are/were few other topics I want to get done before (feed implementation was the main point, one more bigger task to do). So it will take probably around 2 more weeks until i have a first API ready for testing. |
|
|
|
New Feature online: RSS/Atom feedsAgents now have a new notification option. You can enable creation of feed entries in the agent settings. If feed entries are enabled for an agent, you will see two links "rss feed" and "atom feed" in the dashboard. As an example I set up two feeds: Check how many coins DeepBit is getting on the famous 1VayNert... address: Atom - RSSFollow incoming donations for bitcoinmonitor.net: Atom - RSSNote: These links, by nature of rss/atom, are public. Anybody who knows the url can read them (and it is quite easy to guess feed urls with the current url scheme...). So it's probably not a good idea to setup an rss feed for your personal wallet unless you want everybody to know whats your income ;-) |
|
|
|
Good to see another alternative to the old notify service It would be neat if we all could agree on a subset of POST data, that we all send, so that the same code could be used with any notify service, afaik theres 4 to pick from now. That does not prevent each software from adding extra data, just as long as the basic data is what is used for signature verification. That would also mean any shop modules could easily be adapted for each site. Like that idea! Maybe we can start a page on the bitcoin wiki to discuss/define the format? |
|
|
|
Hmm. It looks like I am going to have to experiment with it to totally understand what the heck I am seeing.
Let me know if you need any assistance. Any hint to improve support section is also welcome :-) |
|
|
|
Where are you hiding your donation address?!
Okay, you asked for it  Donations for supporting bitcoinmonitor.net are welcome at 12AxBpvmqzYbSHmvZML6Xv9TPncJgdnikm  |
|
|
|
Just wondering are you using the bitcoind patch I made for MORA?
No, extending bitcoind was one of the first things I started. Should be around 2 months ago (here is one of the first commits: https://github.com/TripleSpeeder/bitcoin/commit/1a6f1ae144568ac4086e64d649c4595c09393564). The callback implementation is based on a quite old branch by Gavin he posted long time ago somewhere here... Otherwise i definitely would have given you the credits :-) |
|
|
|
The site itself is not opensource and written using django as the main web framework. I forked bitcoind to implement some custom rpc-commands, this fork is of course publicly available at github: https://github.com/TripleSpeeder/bitcoin. So services that are dependent on your site will be doomed if your site goes down or goes out of business. I think it's a cool service to use though. Probably yes - one of the reasons I started work on this site was actually the sudden disappearance of bitcoinnotify which I used for txt4coins.net :-) But i do hope that eventually there will be multiple services like bitcoinmonitor.net available (afaik there is at least one similar open-source implementation available at bitping.net), so as a shop owner i can subscribe at multiple services to not depend on one single service. Also there is no final decision about going open-source with the full site. Overall I am a big supporter of open source and use it everywhere possible. But at the moment this site really is my baby so it would be hard to "give it away" :-) But If I ever have to decide to take the site down for any reason it is more than likely that I will at least make the whole thing open source before i leave. That's only fair for all users. |
|
|
|
|
Show Posts
