|
Awesome stats, checking this thread regularly :-)
One suggestion: Could you add the number of bets to the graph? So one could see if the overall usage of the site increases/decreases and how the profit relates to the general usage?
|
|
|
|
und jetzt kommt nicht mit dummen ausreden warum man anonyme Karten braucht, die braucht man nur wenn man das Gesetz fürchten muss!!
Wow, also da fällt mir nichts mehr ein. Bin ich hier im falschen Forum? |
|
|
|
|
Danke für den Link, hat mir gut gefallen! Ich finde er macht den Spagat zwischen technischen Details und leichtem Verständnis ganz gut.
An Fehlern ist mir nur aufgefallen dass er ASIC und FPGA vertauscht hat, was aber für das Zielpublikum nicht wirklich eine Rolle spielt.
Und schade dass er in der Diskussion am ende die Frage nach der Deflation/Mengenbegrenzung der verfügbaren Coins nicht beantworten konnte (Stichwort "Kommaverschiebung" um die Menge der Bitcoin-Einheiten zu vergrößern).
|
|
|
|
|
Please give up on this tainted coins idea. There have been enough threads discussing this, each showing a multitude of reasons why it won't work as expected. Just don't waist any more time on this topic. Thank you.
|
|
|
|
|
Hilarious. I'm tempted to give it a try :-)
|
|
|
|
The simple Armory Daemon is now on github. It aims to be as close to a direct replacement for the Satoshi interface as possible. https://github.com/thedawnrider/BitcoinArmory-DaemonAvailable json-rpc calls are based on the Satoshi rpc interface and are as follows: getbalance getnewaddress getreceivedbyaddress sendtoaddress This looks very interesting. Combining this with bitcoinmonitor.net url callbacks (using the API) will provide you a complete solution to accept payments without the need to put your hot wallet online anywhere and without the hassle to set up/maintain a long list of pre-generated addresses with your bitcoinmonitor.net agent. Awesome!  As soon as I find some time I will set this scenario up for one of my sites. |
|
|
|
|
Is there a specific reason you link against the static python libs? On my Linux box (Arch Linux) only the dynamic libs are availble (*.so). I changed the Makefile to use the .so files and it seems to work so far.
|
|
|
|
|
2 weeks ago i had a successfull SEPA payout. Took around 4 workingdays, so it could be faster but I'm glad they payed at all given the current situation...
|
|
|
|
|
So i can basically create as many receiving addresses on the webserver as I want, but without any risk in case the server gets compromised? Awesome!
|
|
|
|
|
Site had some load issues the last 24 hours, so you might have received notifications slower than usual. Somehow bitcoind was eating up CPU like crazy. Restarted it this evening and everything seems back to normal.
|
|
|
|
Price drop!Now 0.015 BTC per message  .
|
|
|
|
More discussions in IRC today prompted further tweaks to this API:
"get any transaction, even transactions that aren't in your wallet" functionality will be moved from gettransaction to a new 'getrawtransaction' API call, for two reasons:
1. It doesn't 'feel' right to mix the high-level info with the nitty-gritty low-level detail.
2. We think there's a potential for security vulnerabilities if there are existing services that assume that 'gettransaction txid' returns an error for any transaction not in the wallet (as it does in all previous releases).
So the new plan is to put the new functionality in a new RPC call:
getrawtransaction <txid> [verbose=0] : If verbose=0, returns a JSON string that is the hex-encoded, serialized transaction. That is the "machine readable, as concise as possible" use case. If verbose=1, returns a JSON object with all the nitty-gritty details, to cover all the other use cases.
Also, Jeff already has a pull request for JSON-2.0 "batch" functionality, so if you need information about all transactions in a block or all of a transaction's parent transactions you can get it with one RPC round-trip.
Thank you Devs, this is great! Is there some more information on this batch mode available? Would it also be possible to request in one call information about many unrelated TXs (because you mention "all transactions in a block"...)? |
|
|
|
Theymos has installed a much-wanted "Watchlist" feature. Click the "watch" link on the top of a topic page to add it to your watchlist. Click "Watchlist" at the top of the page (if you are using forum's default theme, the SMF default theme, or the BlackBox theme) to see unread replies to posts that you are watching. Hooooray  Thanks! |
|
|
|
Hi, nice project, I just opened an account to take a closer look.
I'm wondering.. if I created a dedicated wallet, say in Armory, and I loaded in the root characters needed to calculate all possible addresses, or a watching only copy, could this system keep track of any transactions that come through on the blockchain to a matching address? Say it was possible, how much might you need to create and maintain it? And could you pickup outgoing transactions as well using the same principal?
Let's see if I understand you correctly: You use a client with deterministic wallet. You want to provide only the "seed" of the deterministic wallet to the bitcoinmonitor agent, so it can derive all bitcoin addresses automatically. Correct? I can not say if this would be possible or how much work would be involved. I did not follow the deterministic wallet concept in detail so far. But it sounds very cool, because you would not need to enter all addresses manually/by API  Regarding outgoing transactions: It is already possible to get notifications also on ougoing transactions. This can be configured for each agent individually. |
|
|
|
On the topic of preventing double-spend attacks (race attacks): - The site's bitcoind now runs with -nolisten and increased number of connections (currently 100). So the chance for a successful race attack is dramatically reduced
 - I am still working in parallel on providing active race-attack detection and notification
|
|
|
|
Delayed notifications todayToday bitcoinmonitor.net had some trouble. Starting somewhere yesterday night the process handling new block events was hanging. This had the following consequence: - 0-confirmation notifications were triggered and executed as usual (they are not depending on the new blocks handling)
- All other notifications (1 to 10 confirmations) were not triggered
The site is now working again fully functional, and all missed notifications should be delivered by now. I am still investigating what is the root cause of the hanging daemon process.
|
|
|
|
Price drop!Now 0.020 BTC per message .
|
|
|
|
Eh, just stumbled on this thread :-) There was a bug in the sysinfo page, not counting all delivered messages. Current stats: Delivered: 93 Failed: 13 So failure rate is like 12% (which is still quite high, but mostly caused due to some trouble with some chinese operator...) |
|
|
|
Until you have listening nodes, you can lessen the exposure to a race attack by disabling listening on bitcoind ( -nolisten) and by explicitly connecting (using -connect= ) to a well connected node. It doesn't mean a race isn't possible, but that the chance that your notification will jive with what comes through in the next block will be > 50% (presumably) even if there were a race attack attempted.
What would be the best way to get a list of well-connected nodes? Is there some list of "trusted" nodes existing already which have valid DNS entries? |
|
|
|
Mir ist aufgefallen das der Bitcoin Daemon extrem viel RAM frisst.
Hab ne VM mit 1 GB Ram auf der 64 Bit Ubuntu +Teamspeak zu Zeit läuft ~170 MB Speicherauslastung.
Jetzt würde ich gern Bitcoin noch mit drauf packen und hab festgestellt das dann komplett 1 GB Ram ausgelastet ist und er den Swap benutzen muss.
Gibt es eine Alternative zum normalen Bitcoind mit der ich Bitcoins empfangen, senden und im Wallet von Account zu Account verschieben kann also das übliche JSON-RPC zeugs mit weniger Speicherlast?
Ich möcte nicht deswegen meine Serverkosten verdoppeln müssen wegen nen Paar MB.
Also bitcoind (nur der daemon, ohne GUI) braucht bei mir laut htop VIRT 419MB und RES (der eigentlich interessante Wert) nur 196MB. Und der läuft schon seit vielen Tagen ohne Unterbrechung. Ist allerdings selbst kompiliert, aber ich kann mir nicht vorstellen dass das einen großen Unterschied macht... |
|
|
|
|
Show Posts
