Transaction:

Code:

0100000009c0576ac4d3e697ed98f853183610f9c0347014ca616f57ba67e008e0c514645c000000006c493046022100ff9e008de0fed0d3c7c090d1826242a1f7e3767da010e86061f50135dbce97a0022100ee99b2523648d0cc2ada55f2c8f617565624b55f7d7462ce36f73e26415a7b650121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff44f3b2dbb41ddaa5b58b10fff613dac5b0721a5e2aef4869e01f7c008bc4e2fa000000006b483045022032ad0f5c77198719351f904405cdb55d6f75dbdd014f916f8770c1a0c781d4f0022100e5ce3ab3a55686c502d7d8e3faa8a266514d19833cb7071f710be3e1d80730350121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff7870b99767967f1812b215e008ae190effd11342ed73cd1b192b8c19054e3efb000000006b483045022055354515ec723fbe200e6fe1d7474989a36f2f2ce1f413ac16331a9929ba5edc02210090b30e397a7f86547ed18cee853d94c7eae709c671f04f11b5ed1f61eb54724b0121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff00adc7e0a4ed3d17a628c76205dcf1f2e9a03db54889433eaae3ad3b2f974330000000006a473044022011c3605be7f92465023c19fa8c0f917a675ac2b638c9a6175889b3c7befad1130220488fcf876d28b9dd9da1e46080e7da2704abf3ff1faf1f2ac77195286893dd540121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff23d3adac3f7f0cfe3102cb4f0d1f4a7cea9e7978f2e83fd63f4a5febce5df863000000006b483045022002ced02afbe93a70c5e3d620747c6a0c9329f04e28f38efc030628bf65938fe8022100ee9b9bdcafeea51714a8aac9bebe854478abfde078bd75af14048c62db3baf170121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff1579e053fe0af032d9271215c0233dcca1f3a67e0440925cfd799f5752a1a2fd000000006a473044022026824ebeb62477d042fcd0351cd5f082faa5ed86b4e8d71a6b3668a4aa52e383022014c595e409fb20a13a10a2507565708bdce434588bdedc46c0b13808655daea70121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffffdc9b6a08f6dac48086be61caf8ae626f5749705bbf2ae164e0c5303a2ac9ccad000000006a47304402205b8196ce2488988aab198ca7d256b0e0a38e136f4a384f0a2c2b176080577b150220479ad0c1d056207a350dc8ac55bdb5e8b6499da856d771f593d60fc43e359ac50121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff76b38261c104eb3e0e60ff6d3f6136736f9f8cd22cf4b0d1ddd5679d73b7e136000000006a47304402207c26b9ff3b383485ad3a48223365010387da7cd99a1d9bfaf92b13bf19dbd144022040f1131532f96c8b09a1acaf7ef227a5470cb8e53ec32f3d6e69bdf2ea76519e0121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2ffffffff0813e26178d5f897e6d71900593e7bdd1d3878455116340d403a3e447e9a16b4000000006a47304402202597c24484131f2fc6431c308edede3ba9841b5bf45438105e5c03495e83b0d102205b6f102590900f9a7ca02e35d908d814dfab6333885377ad3f4a306788d8d242012103edfc76606c411ca35f7d217636655166e77e6a94d85cf30ca0e25537e53bb0ccffffffff0276000000000000001976a9140fe21ebf7c8eea94f794fd55bedd9aa2c40888fd88ac12602100000000001976a9141188311bf0f8690764532dc09d38894bad8c636e88ac00000000

Output from decoderawtransaction:

Code:

{
    "txid" : "b2f19e6ac7ddce5dcdfeb2dbf0e78733d37709ff12723c044cf68ed8cb997d83",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "5c6414c5e008e067ba576f61ca147034c0f910361853f898ed97e6d3c46a57c0",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3046022100ff9e008de0fed0d3c7c090d1826242a1f7e3767da010e86061f50135dbce97a0022100ee99b2523648d0cc2ada55f2c8f617565624b55f7d7462ce36f73e26415a7b6501 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "493046022100ff9e008de0fed0d3c7c090d1826242a1f7e3767da010e86061f50135dbce97a0022100ee99b2523648d0cc2ada55f2c8f617565624b55f7d7462ce36f73e26415a7b650121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "fae2c48b007c1fe06948ef2a5e1a72b0c5da13f6ff108bb5a5da1db4dbb2f344",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3045022032ad0f5c77198719351f904405cdb55d6f75dbdd014f916f8770c1a0c781d4f0022100e5ce3ab3a55686c502d7d8e3faa8a266514d19833cb7071f710be3e1d807303501 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "483045022032ad0f5c77198719351f904405cdb55d6f75dbdd014f916f8770c1a0c781d4f0022100e5ce3ab3a55686c502d7d8e3faa8a266514d19833cb7071f710be3e1d80730350121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "fb3e4e05198c2b191bcd73ed4213d1ff0e19ae08e015b212187f966797b97078",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3045022055354515ec723fbe200e6fe1d7474989a36f2f2ce1f413ac16331a9929ba5edc02210090b30e397a7f86547ed18cee853d94c7eae709c671f04f11b5ed1f61eb54724b01 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "483045022055354515ec723fbe200e6fe1d7474989a36f2f2ce1f413ac16331a9929ba5edc02210090b30e397a7f86547ed18cee853d94c7eae709c671f04f11b5ed1f61eb54724b0121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "3043972f3bade3aa3e438948b53da0e9f2f1dc0562c728a6173deda4e0c7ad00",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3044022011c3605be7f92465023c19fa8c0f917a675ac2b638c9a6175889b3c7befad1130220488fcf876d28b9dd9da1e46080e7da2704abf3ff1faf1f2ac77195286893dd5401 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "473044022011c3605be7f92465023c19fa8c0f917a675ac2b638c9a6175889b3c7befad1130220488fcf876d28b9dd9da1e46080e7da2704abf3ff1faf1f2ac77195286893dd540121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "63f85dceeb5f4a3fd63fe8f278799eea7c4a1f0d4fcb0231fe0c7f3facadd323",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3045022002ced02afbe93a70c5e3d620747c6a0c9329f04e28f38efc030628bf65938fe8022100ee9b9bdcafeea51714a8aac9bebe854478abfde078bd75af14048c62db3baf1701 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "483045022002ced02afbe93a70c5e3d620747c6a0c9329f04e28f38efc030628bf65938fe8022100ee9b9bdcafeea51714a8aac9bebe854478abfde078bd75af14048c62db3baf170121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "fda2a152579f79fd5c9240047ea6f3a1cc3d23c0151227d932f00afe53e07915",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3044022026824ebeb62477d042fcd0351cd5f082faa5ed86b4e8d71a6b3668a4aa52e383022014c595e409fb20a13a10a2507565708bdce434588bdedc46c0b13808655daea701 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "473044022026824ebeb62477d042fcd0351cd5f082faa5ed86b4e8d71a6b3668a4aa52e383022014c595e409fb20a13a10a2507565708bdce434588bdedc46c0b13808655daea70121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "adccc92a3a30c5e064e12abf5b7049576f62aef8ca61be8680c4daf6086a9bdc",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304402205b8196ce2488988aab198ca7d256b0e0a38e136f4a384f0a2c2b176080577b150220479ad0c1d056207a350dc8ac55bdb5e8b6499da856d771f593d60fc43e359ac501 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "47304402205b8196ce2488988aab198ca7d256b0e0a38e136f4a384f0a2c2b176080577b150220479ad0c1d056207a350dc8ac55bdb5e8b6499da856d771f593d60fc43e359ac50121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "36e1b7739d67d5ddd1b0f42cd28c9f6f7336613f6dff600e3eeb04c16182b376",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304402207c26b9ff3b383485ad3a48223365010387da7cd99a1d9bfaf92b13bf19dbd144022040f1131532f96c8b09a1acaf7ef227a5470cb8e53ec32f3d6e69bdf2ea76519e01 039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2",
                "hex" : "47304402207c26b9ff3b383485ad3a48223365010387da7cd99a1d9bfaf92b13bf19dbd144022040f1131532f96c8b09a1acaf7ef227a5470cb8e53ec32f3d6e69bdf2ea76519e0121039079c7a737d25142ea96d31e701cb97d2daf6e20dbccc622053ada118444e9e2"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "b4169a7e443e3a400d3416514578381ddd7b3e590019d7e697f8d57861e21308",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304402202597c24484131f2fc6431c308edede3ba9841b5bf45438105e5c03495e83b0d102205b6f102590900f9a7ca02e35d908d814dfab6333885377ad3f4a306788d8d24201 03edfc76606c411ca35f7d217636655166e77e6a94d85cf30ca0e25537e53bb0cc",
                "hex" : "47304402202597c24484131f2fc6431c308edede3ba9841b5bf45438105e5c03495e83b0d102205b6f102590900f9a7ca02e35d908d814dfab6333885377ad3f4a306788d8d242012103edfc76606c411ca35f7d217636655166e77e6a94d85cf30ca0e25537e53bb0cc"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00000118,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 0fe21ebf7c8eea94f794fd55bedd9aa2c40888fd OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9140fe21ebf7c8eea94f794fd55bedd9aa2c40888fd88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "12Sz1yjHkbM4QXFbd32staHs3czgYTF64e"
                ]
            }
        },
        {
            "value" : 0.02187282,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 1188311bf0f8690764532dc09d38894bad8c636e OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9141188311bf0f8690764532dc09d38894bad8c636e88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "12bhe34ZEmUobxdDqU3H3wPUyEbip91uPz"
                ]
            }
        }
    ]
}

The tx was generated with createrawtransaction and signed accordingly with a 0.7.x bitcoin client. Now when I try to send with sendrawtransaction the behaviour is different it with 0.7.x (transaction gets accepted) and 0.8.5 (transaction is rejected with Code -22). It seems that IsStandard() fails with 0.8.5 but succeeds with 0.7.

Does someone know where the behaviour is changed? Unfortunately I can't debug this at the moment and from just looking at the code i am not understanding why it fails.

Thank you!

So few days ago my Galaxy S2 broke. It still starts up, but only with power attached. I do have a full backup on SD-Card created with Titanium backup (Pro).
My new phone should arrive tomorrow and I am unsure what I need to do with the Google Authenticator settings. I assume if I just install Titanium Backup on the new phone and restore the backup eveything will work again. But I would like not to do a full restore, instead I would prefer to start with a clean phone - I really only care about the 2-factor-auth settings.
So the bottomline is:

• Can I use Titanium Backup to just restore the Google Authenticator app?
• Will it include all configured accounts?

Looking for a VPS with physical location outside EU or US. Any recommendations?

I'm working on a webapp which requires that a user proofs ownership of an address.
Current idea is that user has to sign a random string with his address. On the server I can use the rpcmethod "verifymessage" with the bitcoin address, same random string and signature.
Does this make sense / Is there a better or alternative approach?

Some time ago I heard of https://www.gittip.com/. I really like the idea and concept behind it compared to existing crowdfunding or one-time tip systems. and naturally think that this would be even more awesome when bitcoins are used.
Right now you need to put a credit card on file for tipping anyone, and you need a bank account for getting your money out of the system with all known limitations and attached fees.
The devs are actively discussing bitcoin integration (https://github.com/whit537/www.gittip.com/issues/14), but have no consensus found so far. But the discussion there seems to indicate that they are only willing to partner with a bitcoin payment system like bitpay.com on the frontend, and basically stick to USD for everything else.

I am tempted to start an open-source clone of this with full focus on bitcoin (and only bitcoin), without depending on external services like bitpay and the related direct and indirect fees. So you only can tip in bitcoins and you only can cash out in bitcoins, no interface to banks etc.

What is your opinion? Would efforts be better spent trying to get bitcoin integtated into gittip.com? Or would you prefer a bitcoin-only clone of the project, made by "us", the bitcoin community?

[unlocked]

I am thinking about possibilities for implementing recurring payments service with as little risk and user-interaction as possible.

Goals:
-> Keep the site's hot wallet balance as low as possible to make it unattractive for robbing
-> Allow the user to "pre-pay" for as long as he wants.
-> Allow the user to always cancel not-yet-paid payments

Scenario:
Let's say user wants to pay 1 BTC each week to an address.
User goes to service website, enters information "pay 1 BTC/week to Address X".
User sends 10 BTC to website.
Website splits these 10 BTC into 10 transactions of 1 BTC, each with a locktime one week further in the future.
=> User is done
=> Receiver gets 1 BTC/week
=> Receiver literally can see in the blockchain that payments to him are really planned (of course this is just for information - unlocked payments could be cancelled anytime)
=> Few days before the last pay date is reached site sends a reminder mail to user if he wants to continue the recurring payment he has to send funds.
=> Happiness  

Now let's say the user wants to cancel the not-yet-paid transactions:
-> User goes to site, says to stop all payments
-> Site updates the unlocked transactions with a new Outpoint (The users address).
=> Q: Can the user get back his coins immediately? Can the locktime be modified also at this place, so the user gets his coins back right away? Or does he still have to wait for the locktime to be reached? Or could the site generate just a new normal transaction with all unlocked transaction's inputs as inputs that "overrides" the waiting transactions?

Now assume the site gets robbed and an attacker obtains the wallet.dat:
What is the actual balance of the wallet? If all incoming payments from Users are immediately broadcast with according locktime to the recipients - Would the wallet appear to the robber as "empty"? What additional information would he need to change all existing unlocked transactions to point to his address?
In general: Would this approach give any security boost over a classical "pay from hot wallet via cronjob"-approach?

[bitbattle.me - Blockchain gambling improved]

bitbattle.me - Blockchain gambling improved

More than 250,000 bets placed with a total volume of 140,000 Bitcoin!

Jump straight into action without depositing and waiting for confirmations!
Don't want to wait hours until your bet gets eventually picked up?
Want to roll the dice without spamming the blockchain?
Fed up with your wallet being fragmented?
Want to track your bets in realtime on the website?
Pushing transactions without an opponent gets boring?

bitbattle.me is changing the game! It is inspired by the various dice games, but is adding some unique features:

• Have your own set of permanent bet addresses
• Track all your bets and sessions with personal statistics
• Optional incognito mode so only you can see your full stats and history
• Watch your and other people's bets and sessions live in the browser
• Multiplayer: Play against a (random) opponent
• Multiplayer: No luck? Still you can win by taking more risk than your opponent!
• Multiplayer: bitbattle your buddies with invitation games
• All kinds of statistics
• API & sample bot implementation

Most features are available without creating an account or registration! Simply create your player with attached set of Bet addresses - No email, no account, no password to remember! An account is mandatory to be able to start or join multiplayer sessions.

The basic bet system is similar to the various dice sites, but the available bets are spread more equal with win probability steps of ~5%. House edge for all bets is 1.9%.

Checkout the game rules, FAQ, available bets and API description.


Update 2013-06-02:

• Transaction fees reduced according to current bitcoin-qt client (0.0001 instead of 0.0005)
• Updated acceptance policy for incoming transactions:
•  If a transaction has fee >= 0.0005 0.0001, and all inputs are confirmed -> ALLOW
•  If a transaction has fee < 0.0005 0.0001, but all inputs are confirmed -> ALLOW
•  If a transaction has fee < 0.0005 0.0001, and at least one input is unconfirmed -> REJECT
•  If a transaction has at least one unconfirmed input but fee >= 0.0005 0.0001 -> ALLOW
•  If a transaction has at least one unconfirmed input and fee < 0.0005 0.0001 -> REJECT

Update 2013-05-02:
You can now opt to hide your stats and sessions from public. If you don't want the world to see how much you are betting you can go to your account settings and click on "Anonymize me in public stats".
Enabling this will anonymize or hide most of your personal information:

• Your dashboard will not be available for other users
• Your player name, sessions and transactionIDs will be replaced by '****' in all public statistics
• Your personal statistics will not be available for other users

Update 2013-03-19:

• API extension: Now it is possible to obtain detailed information about player's bet addresses, win odds etc. in json-format. Just take player's dashboard url and append /json/ at the end. (Sample: http://bitbattle.me/player/herbert/json/)
  More details in section "Player information" in the API description.

Update 2013-03-16:

• Display improvements: All bitcoin amounts are now rounded to 4 digits instead of 3 digits and have a tooltip with the exact amount on mouse-over.
• Socket.io-based API available! Check out the documentation at http://bitbattle.me/api/
• Open-source sample bot written in Python, including simple martingale strategy, available on GitHub.

Update 2013-02-18:

• The "Get started" page now contains a section for optional account creation. (Note that for account creation no email confirmation is necessary, so you could register with fake email. However in this case there is no possibility to help you in case you forgot your password.)
• If you are logged in you have a dropdown menu on your username (top right of navbar) with shortlinks the the dashboard(s) of your player. (Yes, you can have multiple players connected with your account)
• If you are logged in, every player you create will automatically be linked to your account
• You can link your existing anonymous player to your account. Click on the "connect to account" button in the player's dashbord and follow the instructions (You will have to sign a message with your payout bitcoin address to prove ownership).
• It is no longer possible to close other player's sessions (You can only close sessions of your own player when you are logged in)
• It is no longer possible to start or join a multiplayer session with other players. (You can only do this with your own player when you are logged in)
• It is no longer possible to create multiple players with the same name. Existing duplicates have been renamed.

Update 2013-02-08:

• Player-related urls now using 'slug' based on playername instead of uuid (example: http://bitbattle.me/player/herbert/). Old bookmarks are still valid, they will redirect to the new urls.
• Running sessions table in dashboard and index page now show the remaining seconds until session timeout
• Fixed a rare racecondition while closing sessions that could lead to duplicate payment objects, resulting in no payment being made (Thanks to R33F for helping to track down this bug!)

Update 2013-02-01:

• Bet limits raised by 66%! Win up to 50 Bitcoin with a single bet!

Update 2013-02-01:

• Make the notification of waiting multiplayer game more prominent, including waiting opponents name.
• Make sure to close multiplayer sessions in time even when no bet was placed.
• Inform player about remaining seconds if he wants to close a session early.
• Added info on transaction acceptance policy to rules
• Show timestamp in payments history

Update 2013-01-28:
New statistics and various small UI fixes:

• Bet History
• Session History
• Payment History
• Slightly redesigned main page
• Limit the number of bets/sessions/payments displayed on the players dashboard (As info on past data is now available in the player's statistics)

Update 2013-01-12:

• Placing multiple bets of the same type within one transaction is now allowed
• Extended double-spend protection. Incoming transactions are now checked based on these rules (and some more  ):
•  If a transaction has fee >= 0.0005, and all inputs are confirmed -> ALLOW
•  If a transaction has fee < 0.0005, but all inputs are confirmed -> ALLOW
•  If a transaction has fee < 0.0005, and at least one input is unconfirmed -> REJECT
•  If a transaction has at least one unconfirmed input but fee (>= 0.0005) -> ALLOW
•  If a transaction has at least one unconfirmed input and fee < 0.0005 -> REJECT

Update 2013-01-05:

• Rework session close logic to prevent deadlocks
• Add some more crosslinks to blockchain.info for transactions and addresses
• Improve live connection for IE users (now using flashsocket)

Update 2012-12-29:

• Fix display bug when other player's bets show up in dashboard
• (hopefully) fix display bug when bets show up multiple times in dashboard
• Closing a session is now only allowed 30 seconds after the last bet has been placed
• Increase maximum bet stakes by 50%!

Update 2012-12-22:

• You can search for bets by transactionID (Button "Lookup Tx" on main page)
• Rejected bets now have tooltip on mouseover which states the reason for being rejected
• Refund payments now have a tooltip on mouseover which states the reason for the refund
• Some additional minor fixes

Update 2012-12-19:

• No more bet timeout for singleplayer sessions
• Increase session timeout to 10 minutes
• Added "close session" button to session details page
• Increase bet timeout in multiplayer sessions from 75 to 90 seconds
• Decrease bet limit to 50 bets/session

Update 2012-12-18:

• TxFee calculation now follows the same rules like the official bitcoin client. Payout transactions should get faster confirmations now.
• The issue of too little confirmed balance in the hot wallet ("Wallet depleted" error) should not occur (so often) anymore.
• Payments are now handled asynchronously. You will notice that all payment start in state "pending" and after a short time (usually <1 second) switch to status "paid"

Update 2012-12-14:

• The lucky number is now displayed in the session log
• The number of bets per session is now limited to prevent huge sessions like Carlos produced ;-).
• When a game is closed the reason for closing is displayed (bet limit reached, time limit reached etc.)
• Fix: Pending Payment issue caused by huge sessions
• Fix: Refunds in multiplayer sessions caused an internal error and were stuck
• Fix: After a bet is rejected due to insufficient wallet balance you had to open/close a multiplayer session in order to be able to bet again

Update 2012-12-11:

• Invitation links are back!
• The "Start Multiplayer" link will now change to "Join multiplayer" when another player started a multiplayer session. This should make it a bit easier to have a multiplayer session as you immediately see when one is started...

Hi,

i am trying to make bitcoinmonitor.net more automated failsafe. One thing that currently requires manual intervention by admin is downtime of the main application while the bitcoind is still running. In this scenario bitcoind will try to notify the app about new blocks. As the app is down, these notifications get lost.
Result: When the app is running again admin has to manually make sure that the missed blocks are collected and handled apropriately.

Idea to automate this process:
- App stores for each received block the hash and height.
- If a new block comes in app calculates delta between new block's height and last seen block's height.
- Normally the delta should be exactly 1, but in case blocks have been missed by the app the delta would be larger.
- If blocks are missed the app requests the missing blocks using getblockhash(height) and getblock(hash) rpc commands

So if the last received block has height 10 and new block of height 15 comes in the app will try to get additionally blocks of height 11,12,13 and 14.

I think this should work fine in the normal case, but i am not sure if this would be safe for blockchain reorg scenarios.
Could it happen that after a reorg the newest block has a height than the last seen one?
Or could it happen that after a re-org a new block is accepted at the same height of the last block?

Note that my bitcoind patch triggeres notification on new blocks only when they are accepted and part of the main chain (Triggering is done at the end of CBlock::AcceptBlock())

Just tried to add a bitcoin-uri to my signature, but no luck. Board keeps adding "http://"-prefix as it does not recognize the bitcoin-uri.

What i want to do:

Code:

[url=bitcoin:12AxBpvmqzYbSHmvZML6Xv9TPncJgdnikm?label=Herbert]12AxBpvmqzYbSHmvZML6Xv9TPncJgdnikm[/url]

What gets stored:

Code:

[url=http://bitcoin:12AxBpvmqzYbSHmvZML6Xv9TPncJgdnikm?label=Herbert]12AxBpvmqzYbSHmvZML6Xv9TPncJgdnikm[/url]

I have no idea if this can be added easily or not...

I have bitcoind running 0.6rc1 for some time. Since sometime yesterday it stopped accepting new blocks.

This is what i get in debug.log when a new block comes in:

Code:

03/08/12 10:36:46 received block 00000000000002821c36
03/08/12 10:36:46 REORGANIZE
03/08/12 10:36:46 ERROR: ConnectInputs() : 6a26d2ecb6 VerifySignature failed
03/08/12 10:36:46 ERROR: Reorganize() : ConnectBlock failed
03/08/12 10:36:46 InvalidChainFound: invalid block=00000000000002821c36  height=170174  work=257117002938452064195
03/08/12 10:36:46 InvalidChainFound:  current best=00000000000003bd2bf5  height=170059  work=256377602133619763100
03/08/12 10:36:46 InvalidChainFound: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
03/08/12 10:36:46 ERROR: SetBestChain() : Reorganize failed
03/08/12 10:36:46 ERROR: AcceptBlock() : AddToBlockIndex failed
03/08/12 10:36:46 ERROR: ProcessBlock() : AcceptBlock FAILED

Is this happening because its still 0.6rc1? Or related to the duplicate transaction fix?

[bitcoinmonitor.net will shutdown.]

bitcoinmonitor.net will shutdown.

I hope to have it running 2-3 more days, but circumstances are out my control. So right now there is nothing I can do about it, and it seems unlikely that it will be back up soon.


Original post from 2012-02-16:

Ever since the ugly end of bitcoinnotify.com last december I was thinking about implementing a better notification service myself, including a secure, easy-to-use payment service. This idea kept bugging me, so over Christmas holidays i started working on it. Now, after many hours spent thinking, coding, learning and testing I think it's time for a public announcement!

http://www.bitcoinmonitor.net

Of course I know there are other services already existing, but it seems many of them offer notifications as a kind of add-on to other stuff, not really focusing on providing a decent user experience. And in general it never hurts to have a choice - especially for the area of providing payment services I consider it absolutely necessary to have multiple choices which could even be used in parallel for added security/reliability.

Important: The notification service will stay free for everybody. Of course i need to think about covering the costs for server and traffic, but this will not be done by charging the average user. One idea which might have potential is embedding advertisement into the notifications, or offering complete payment integration modules for the well-known shop systems - but this is not decided yet.

Major goals I had in mind when working on this site:

• Usability:
  To make it easy also for non-techies to understand how the site works I introduced the concept of agents. Of course usability is a subjective matter, so if you have any improvement suggestions let me know.
• Control:
  Full notification history - You can track each and every single notification in your dashboard, including status e.g. on the response of http callback. API access is quite high on my TODO-list, which will make it possible to setup and manage your agents via json-based http API. Also a retry-strategy for failed notifications is clearly defined.
• Speed:
  The main point in providing payment notifications is to have them as fast as possible. So the whole architecure is event-driven - no polling anywhere.
• Stability:
  Use existing, rock-stable frameworks and tools whenever possible. This means: Mysql and django for the core, celery and rabbitmq for task handling, YAML css framework for the layout. Especially bitcoinmonitor.net does NOT require any additional tool/database/whatever to interact with the bitcoin network. It is just a stock bitcoind with small patches applied to trigger on new unconfirmed transactions/blocks and allow retrieving of arbitraty transaction information.
• Scalability:
  Direct benefit of using existing technology versus NIH-syndrome is scalability. If necessary each component can be moved to it's own hardware, made redundant or be load-balanced.

This is the initial public launch (well, few days ago I posted it on G+ ;-), so the site is still considered in betaphase and is not yet finished.
The layout and design is really just the default YAML template and definitely needs some beautification and improvements. The list of right now available notifications is rather short. Content and texts are probably rather clumsy. API access is only half-way done and not yet available to the public.

tl;dr:
Please checkout http://www.bitcoinmonitor.net and let me know what you think!

At least since monday morning https://bitcoinnotify.com/ seems to be down.

Somehow I expected it after following the various not-amusing threads about it's selling. Still I would have preferred to get at least a short warning to all registereed users that it will go down instead of just nothing,  not even a post here in the forum

Maybe the new owner (whoever that is right now as the last thread has been deleted: https://bitcointalk.org/index.php?topic=53297.0) can shed some light on the situation? Will it come back or is it down for the foreseeable future?  (Anyway i started working on my own implementation already ;-))

Hi,

I understand that the gettransactions command only will return transactions concerning the users wallet. Is there a way to query bitcoind for any transaction, independent of the users wallet?

Thanks!

[0.0025 BTC]

http://txt4coins.net

txt4coins provides premium sms service. Highlights:

• worldwide delivery
• you can set sender name/number
• no registration/login required
• superfast delivery (after 0 confirmations!)
• API access (pay-per-use, no registration)
• bulk messages

The price of one message is only 0.006 BTC 0.0025 BTC!

If you have any question or issue please reply here, PM me or send mail to michael@txt4coins.net.

Payment service provided by bitconmonitor.net!

Grade die mail von tradehill bekommen:

SEPA account changes

We are currently in the process of changing SEPA accounts, as our current EUR partner has decided to refocus his business. We would like to thank our partner for the invaluable help he has given to TradeHill to establish our EUR/BTC market and wish him success in his next venture.
We expect this transition to our new SEPA account to take several weeks to complete. In the mean time, EUR deposit and withdrawal will be available via Paxum account or OK PAY account. Please do not send SEPA deposits to the former account, as it will be rejected by the account.
We will keep you updated on the blog with any updates about this status.

If you currently having a pending SEPA deposit and have not sent this, please do not submit this transfer. You can choose to fund your account using one of the methods mentioned above, or wait until we have made full migration to the other account!

Kurzübersetzung:
Der Geschäftspartner der die SEPA-Überweisungen gemanagt hat sucht sich andere Geschäftsmöglichkeiten. Ab sofort ist weder Ein- noch Auszahlung mittels SEPA möglich.

Dabei hatten die das Konto in Deutschland - sehr schade:(
Hab erst vor zwei Tagen eine größere Menge Euros überwiesen, zum Glück sind die schon im Account angekommen...

MtGox kann auch grade kein SEPA, bitcoin7 gibts nicht mehr, ... Was jetzt? Auf Paxum und Co kann ich gut verzichten....

I am working on http://txt4coins.net and asking myself what kind of API you would prefer.
Basically there are two options:

Pay-per-use:

• no registration required
• no pre-payment necessary
• you only pay what you really need
• requires more complex logic on your side as you always need 2 steps: Submit message, pay message
• no risk on your side in case site is shut down as there is no pre-payment
• no way to implement a volume discount

Prepaid:

• Registration required
• You need to charge your account before you can send a message
• Simple logic on your side - Only one step necessary to send a message
• possibility of volume discounts
• risk on your side to get your prepaid coins back in case site is shut down

Currently implemented is the pay-per-use approach as I think it fits the bitcoin-model best. (Check out http://txt4coins.net/betatest/api/ for an API description). However it means a more complex workflow for anybody using it due to the 2-step approach, so for easy adoption the old-school prepaid method would be better?

[0.01 BTC]

Hi,

today i launched the public beta of txt4coins.net:

http://txt4coins.net/betatest

txt4coins provides premium sms service. Highlights:

• worldwide delivery
• you can set sender name/number
• no registration/login required
• superfast delivery (after 0 confirmations!)
• API access (pay-per-use, no registration)
• bulk messages

To keep the risk of breakage low initially the maximum number of currently active messages (waiting for payment) in the system is limited to 12. If this turns out to be too less i will increase this number (If all slots are busy you will get the error "Could not obtain payment address. Please try again later").

During betaphase the price of one message is only 0.01 BTC!

Looking forward to your feedback, especially regarding speed of non-german recipient numbers. During my tests the time between initiating the transfer in bitcoin client untill message comes in on the phone was at most one minute...

Update October 9th:
Delivery status is now tracked in more detail:

• delivery accepted - message accepted by SMS gateway
• delivery to SMSC - message arrived at SMS Center of operator
• delivery buffered - message buffered at operator (handset turned off or no network reception)
• delivery failed - message could not be delivered due to wrong phonenumber or handset being offline for more than 48 hours

... and some html/css fixes to better support IE8/IE9.


Update October 18th:
txt4coins now offers an anonymous, registrationless pay-per-use API! With this API you can send txt messages via http API without registration and without any prepayment.

Check the docs: http://www.txt4coins.net/betatest/api/

As txt4coins.net is still in betatesting the price stays at incredible 0.01 BTC per message. Given the current exchange rates txting was never cheaper


Update October 25th:
New feature: Bulk messages!

Now you can send the same message to multiple recipients (currently up to 50) at once. This feature is available both directly from the website and via the pay-per-use API. The price is calculated based on the number of recipients (price per message * number of recipients). Maybe I will add a volume discount at a later stage...

This is the last big feature i wanted to implement before closing the betatest and "officially" launching the site. As i will be off the grid for most part of the next week betatest will continue for around 3 weeks though.

And of course the price still remains at 0.01 BTC per message!

[Preis pro SMS bei 0.01BTC]

Hi,

mein erstes Bitcoinprojekt startet im öffentlichen Betatest!

http://txt4coins.net/betatest/

Hier kann man SMS verschicken:

• weltweit
• Absender frei wählbar
• ohne Registrierung/Login
• superschnell (Versand nach 0 confirmations!)
• SMS mittels API verschicken - auch hier ohne Registrierung im Pay-per-use Verfahren
• Massenversand mittels website oder API

Um erstmal zu sehen wie gut alles funktioniert liegt die maximale Anzahl der SMS die im System gleichzeitig aktiv sein können (also auf Zahlungseingang warten) bei 12. Das kann ich aber hochschrauben falls es zu eng wird (Falls alle "slots" belegt sind kommt die Fehlermeldung "Could not obtain payment address. Please try again later").

Während der Betaphase liegt der Preis pro SMS bei 0.01BTC!

Ich bin gespannt auf euer Feedback insbesondere was die Geschwindigkeit angeht. In den Tests die ich bisher machte kam die SMS maximal eine Minute nach dem Click auf "überweisen" im client an :-)

Danke schonmal!

Update 9.10.:
Der Lieferstatus wird jetzt detaillierter getrackt:

• delivery accepted - Nachricht wurde vom SMS gateway angenommen
• delivery to SMSC - Nachricht ist im SMSCenter des Operators angekommen
• delivery buffered - Nachricht wird beim Operator gehalten, da Handy ausgeschaltet oder kein Netz
• delivery failed - Nachricht konnte nicht zugestellt werden z.B. weil Nummer falsch oder Handy mehr als 48Stunden offline

Ausserdem ein paar Fixes am html-code damit das ganze unter IE8/9 etwas besser funktioniert.

Update 18.10.:
Ab sofort gibt es eine registrierungslose pay-per-use API! Damit könnt ihr per API SMS versenden ohne euch vorher anmelden zu müssen und ohne vorher ein Guthaben aufzuladen.

Doku siehe hier: http://www.txt4coins.net/betatest/api/
(Ja, am Design muss ich noch arbeiten - Das ist recht unübersichtlich...)

Übrigens bleibt es weiterhin trotz des schwachen Kurses während der Betaphase bei 0.01 BTC pro SMS! So günstig war SMS verschicken noch nie...

Update 25.10.:
Nächstes Feature: SMS Massenversand!

Ab sofort kann man eine Nachricht gleichzeitig an bis zu 50 Empfängernummern schicken. Das geht sowohl über das Formular auf der website als auch über die pay-per-use API. Im Moment wird der Preis einfach als (Anzahl Empfänger * Preis einer SMS) berechnet. Auf meiner Todo-Liste steht aber schon ein Mengenrabattsystem.

Mit diesem Feature rückt das Ende des betatests näher - Technisch sind jetzt alle Funktionen da die ich für den ersten Release geplant habe. Jetzt gehts nur noch um Bugfixing und Verbesserung der Website. Ich bin nächste Woche mehr oder weniger offline, also wird die Betaphase sicherlich noch so 3 Wochen dauern.

Und der Preis bleibt natürlich weiterhin niedrig bei 0.01BTC während der Betaphase