I added ping time measurement to bitcoind, and it works, using the "ping" and "pong" commands (ping sends a unique nonce, pong echoes that nonce).

I added the ping time as an additional output to getpeerinfo.  The ping time is in seconds, as a decimal number, so it often appears as a very small decimal number with many places, looking rather appropriate for Bitcoin

Now, I can see, in the table of connected peers, the ping time for each peer.  The ping command is handled in the normal command handling function, it isn't given additional priority or anything like that, so the ping time also includes all command processing backlog time, revealing which nodes are heavily congested with commands to be processed (such as nodes trying to catch up on blockchain synchronization).

I also added a new RPC command, "ping", to request that a ping command be sent out to all peers.  This is in additional to the usual case of sending out the ping command as a keepalive.

It's not ready for pull request yet, but to take a look at it, it's here:

https://github.com/Krellan/bitcoin/commit/fbc91c10d818432070ef8bac56b07707f43ef0b1

Interesting observations:

1) The reference bitcoind sends ping commands with 0 (zero) as a nonce, however, during my testing I encountered other peers that sent me valid nonces (nonzero, looks random enough to me).  So, there must be other patches floating around that also add valid nonces to the ping command?

2) I noticed a lot of nonce mismatches.  Upon further inspection, there are a lot of peers that send a pong reply with 0 (zero) as the nonce, regardless of what I had sent to it in the original ping command.  I wonder what causes this?  The reference bitcoind doesn't do this, it is correct, and it looks like a bug in some other client.

3) In my implementation I only keep track of one outstanding nonce/timestamp at a time.  There's nothing stopping the user from sending another ping while still waiting for the first to complete, though.  I wonder if it is worth it to complicate the implementation by using a vector so I can remember more than one nonce/timestamp at a time per node, or only consider the most recent ping attempt to be the only valid ping?

4) I'm using a unique random nonce for each peer, which is rather wasteful of valuable random number entropy.  Perhaps use the same nonce for all peers in a single ping command, or would that open up other problems?

5) Adding the new RPC command "ping" opens up an opportunity for a user with RPC access to attempt to DoS the rest of the Bitcoin network, by sending out ping commands as fast as possible.  I need to ratelimit this.  Any suggestions on what a reasonable ratelimit would be?

6) Similarly to the above, if a peer is sending me ping commands too quickly, I should also ratelimit my pong replies.  Any suggestions for that?  There are other things as well, such as sending me unsolicited pong commands (without a corresponding ping).  If peer is doing these, should I punish them with Misbehaving() or just silently ignore them?

Thanks!

This is a rather cool feature, I'm happy about it, and it was inspired by the "pings" webpage of p2pool.

Josh

If you look in Google Play, you will see a lot of other people reporting the same problem.

https://play.google.com/store/apps/details?id=de.schildbach.wallet

Previous versions of this app used to have checkboxes, "Sync on Power" and "Sync on Wi-Fi".

The current version of this app no longer has these choices exposed to the user.  Instead, it adds a nice feature, that is, the ability to have these checkboxes be cumulative (requiring BOTH power AND wireless in order to sync).  However, there's no way to disable this.

Please, please, please, restore the ability of the user to disable the sync, so that the user can stop the app from syncing automatically.

You are very lucky in Germany, but here in the USA, unlimited data plans on cellphones seem to be disappearing.  I want to be able to charge my phone without fear that a peer-to-peer app is going to start up whenever it sees power, and start burning up my bandwidth outside my control.

Please, please, please.

Nobody likes apps that do things behind their back.

Thank you for listening!

If developer is unable/unwilling to restore this feature, then I would be curious to hear suggestions for a workaround.  The "Trusted Peer" feature might work, I could set a peer of 127.0.0.1 (thus preventing it from connecting it anywhere), and using the "Skip Regular Peer Discovery" checkbox to control whether or not I want it to search for additional peers or not.  Also, the "Autorun Manager" app looks promising, I could revoke the event listeners of Bitcoin Wallet and thus prevent it from seeing events that would cause it to begin syncing.

Josh

Originally posted this in the Newbies forum, probably not the best place, it fell off rather quickly.

https://bitcointalk.org/index.php?topic=232971.0

Reposting here, after some refinement.

Something I wanted to make for folks to try out at the Bitcoin conference that was in San Jose in May, but logistics and other factors didn't quite come together in time.

A pinball machine that takes Bitcoin....

I have some pinball machines, as do friends of mine.  An appropriately themed game would be one of the newer, better games: Tron

The game would be set up in a public area, for all to see.  Instead of quarters, I'd print out a barcode and attach it to the front of the game.  Pay to that address and the game would credit up, and then you get to play it.

The hardware would be straightforward.  A little embedded Linux ARM board, running the Bitcoin client.  A large SD card would have plenty of room for the blockchain and the rest of the Linux environment.  The board would have at least one GPIO output, that my software could control.  A little custom circuit would have to be made, using a relay, isolated, to use the GPIO to temporarily close a switch that is normally open, so that the pinball machine can be coined up.  To run the Bitcoin protocol, the Linux board would have an Internet connection via cellular modem.

The advantage of the little board running the Bitcoin protocol itself, is that it would be more self-sufficient.  An alternative is to have it be merely a slave, connecting to another computer somewhere else, and then the only time the cellular modem would need to be used would be when it was actually time to credit up the game.  This has the advantage of requiring much less expensive cellular data, however, then the game is slaved to that other computer, and if that link is lost, players will feel ripped off because they'd pay the Bitcoin but receive no game play!

Wherever it runs, it should be trivial to write a little daemon that continuously monitors a particular Bitcoin address, and detects incoming payments to that address.  Since the game would be something of low value (BTC 0.01 or BTC 0.005 per play, I'm thinking), and the player is waiting immediately to play, and the whole thing is a proof of concept anyway, I would feel comfortable accepting payments with zero confirmations.  There is a risk of double-spending, sure, but perhaps this could be mitigated by monitoring other points in the Bitcoin network (perhaps look up each transaction on blockchain.info or similar service, to detect double-spending attempts).  Since players are anonymous, I wouldn't need to care about the source of the funds, or trying to match them up with an identity.  Somebody halfway around the world could make a payment, causing the game to seemingly add credits to itself out of thin air

Since it would only be accepting payments, and not sending them out, the device need not have the address in its wallet.  This gives it more security, since if somebody breaks into the game and swipes my board, all that is lost is the value of the hardware, no Bitcoin would be lost.

The only disadvantage of this design is that it uses the Bitcoin protocol directly, and the payment amounts are small, so the transaction fee becomes a factor, and it seems kind of silly to have each little game stay on the blockchain for all time.  However, by using Bitcoin directly, instead of a middleman service, it becomes available to all players as an impulse buy, without anybody having to register and fund first at a middleman service.

So, anybody done this already?  Wonder if there's anybody else in the Bitcoin community who is into pinball.  The same concept applies to any other arcade game or amusement device, as well.  Vending machines could also be used, but there'd be a conversion factor to take into account, as the vending product would probably still have to be bought with fiat.

Josh

Something I wanted to make for folks to try out at the Bitcoin conference, but time and other factors didn't quite come together in time.

A pinball machine that takes Bitcoin....

I have some pinball machines, as do friends of mine.  An appropriately themed game would be one of the newer, better games: Tron.

The game would be set up in a public area, for all to see.  Instead of quarters, I'd print out a barcode and attach it to the front of the game.  Pay to that address and the game would credit up, and then you get to play it.

The hardware would be straightforward.  A little embedded Linux ARM board, running the Bitcoin client.  A large SD card would have plenty of room for the blockchain and the rest of the Linux environment.  The board would have at least one GPIO output, that my software could control.  A little custom circuit would have to be made, using a relay, isolated, to use the GPIO to temporarily close a switch that is normally open, so that the pinball machine can be coined up.  To run the Bitcoin protocol, the Linux board would have an Internet connection via cellular modem.

It should be trivial to write a little daemon that continuously monitors a particular Bitcoin address, and detects incoming payments to that address.  Since the game would be something of low value (BTC 0.01 or BTC 0.005 per play, I'm thinking), and the player is waiting immediately to play, and the whole thing is a proof of concept anyway, I would feel comfortable accepting payments with zero confirmations.  Since players are anonymous, I wouldn't need to care about the source of the funds, or trying to match them up with an identity.  Somebody halfway around the world could make a payment, causing the game to seemingly add credits to itself out of thin air

Since it would only be accepting payments, and not sending them out, the device need not have the address in its wallet.  This gives it more security, since if somebody breaks into the game and swipes my board, all that is lost is the value of the hardware, no Bitcoin would be lost.

The only disadvantage of this design is that it uses the Bitcoin protocol directly, and the payment amounts are small, so the transaction fee becomes a factor, and it seems kind of silly to have each little game stay on the blockchain for all time.  However, by using Bitcoin directly, instead of a middleman service, it becomes available to all players as an impulse buy, without anybody having to register and fund first at a middleman service.

So, anybody done this already?  Wonder if there's anybody else in the Bitcoin community who is into pinball.  The same concept applies to any other arcade game or amusement device, as well.  Vending machines could also be used, but there'd be a conversion factor to take into account, as the vending product would probably still have to be bought with fiat.

Josh

I've been running 0.8.1 for a while, it's tried and true.

Should I upgrade to 0.8.2?

What advantages and disadvantages does it bring?

I'm curious, because even though 0.8.2 came out recently, I did "getpeerinfo" in my client and find that the vast majority of other nodes that I'm connected to are still running 0.8.1.  Are people holding back for a reason?

Thanks!

Josh

Hi there.

Anybody remember the old intrade.com site?  It was very useful during the 2008 and 2012 elections in the USA.  However, it was taken down.  An obvious idea is to make a clone of that site, but now using Bitcoin instead of "traditional money", to avoid the financial/bank problems that Intrade ran into.

Does such a site exist already?

I found betsofbitco.in which lets you place yes/no predictions, however, it isn't based on a contract that can be bought/sold like Intrade was.  The big advantage of Intrade was that it gave everybody an accurate percentage prediction on whether or not something would be coming true in the future, based on the price of that contract, so people could use it as a crowdsourced prediction tool.

The contracts paid out at 100% if true, 0% if false, and before the outcome of the event was known, it was floated on an open exchange, to trade freely, by posting bids/asks within that range.  Speculators could buy or sell contracts.  Short selling was also easily handled without running into margin problems, because unlike a traditional stock market, the maximum risk of these contracts is known, as the value can never go above 100%.

If a clone of Intrade doesn't already exist in the "Bitcoin world", well, that's your market opportunity!

Is anybody working on such a site?

Josh

Hoping this isn't the super obvious newbie question that I just overlooked.

I've done "Backup Wallet" in my bitcoin-qt client, it wrote a wallet.dat file just fine.  I repeated that a few times, backing up to various drives and USB sticks.

I noticed the file is rather large for what I thought was just the private keys for my Bitcoin addresses.  What is contained in the wallet file?  Mine was around 300K, which is still very small, but large for just a few private keys.  What else is in the wallet file?

Anyway, my question is, how do I then restore the wallet that I've backed up?  Thinking "Restore Wallet" would be right next to "Backup Wallet" in the menu, it wasn't.

I want to also set up a bitcoin-qt client on another computer, and want them to sync up, so that they both see the same addresses and show my balance.  This will also be a good test of whether or not the wallet.dat file truly does a full restore.  Ideally, the account balance should always match, assuming both computers are fully caught up to the latest blockchain, right?

Also curious: How can I merge two wallets together, in the bitcoin-qt client?  That would also be useful.

Thanks!
Josh

I'm curious, how does the Bitcoin network resolve conflicting transactions?  I looked for this in a FAQ, but couldn't find details on exactly how the network chooses which of two choices to believe, when given conflicting choices.

This could either be done intentionally (flooding others in an effort to induce lag, hacking the Bitcoin client to disable consistency checks, generating false confirmations, intentional double-spending, connecting a large network of your hacked Bitcoin clients in an effort to steal traffic from the existing network, any other ways) or accidentally (connecting to the Test network instead of the real network, running offline for a while then reconnecting later).

Which determines the winner?  How does the network know to discard unwanted transactions, provided that those unwanted transactions are not totaling enough to constitute a 51% attack?

It makes sense that Bitcoin would still be vulnerable to a 51% attack.  A corporation is vulnerable (convince 51% of shareholders to vote your way, or just buy 51% of all shares, and you can appoint yourself CEO and do whatever you want), and a democratic government is vulnerable (convince 51% of voters to vote for you, and you are President).  Evidently that's pretty much how the world works, nothing can really be done about that

Josh

Anybody run Gentoo?

I noticed that bitcoind and bitcoin-qt are up to date (version 0.8.1), and work fine, but have to be keyworded so they are taken from the "unstable" version, not the mainline version.

However, cgminer is masked, not merely keyworded, and even after unmasking, what's there is badly out of date.  I'm wondering if there's a reason for this?  Has it just not been maintained in Gentoo for a while, or does it really have a reason (security hole, or whatever) to be masked?  I'm considering making a Gentoo ebuild for the most current version of cgminer, if nobody else has yet.

Thanks!

Josh

Hi again, last of my newbie questions.

What's to stop a Bitcoin miner, participating in a shared mining pool, from cheating?  That is, if a miner is lucky enough to discover a winning block, what's to stop them from publishing it on their own, and putting the entire 25 BTC reward in their own pocket, thus cutting out the rest of the pool?  The miner who finds a lucky low hash would know what inputs they used to create the hash, so that should be enough for them to mint the block to an account under their own control, instead of submitting it back to the pool, right?

It seems just like pooling money for traditional lottery tickets whenever there's a big jackpot: only with Bitcoin, everybody is anonymous and doesn't know each other, so there's nothing to stop the guy who holds the winning ticket from cashing out the jackpot all to himself and then skipping town.

Really glad this board doesn't throttle postings of new posters, BTW.  Amazing that it's such high volume and still essentially spam free!

Josh

I'm curious: A Bitcoin block, over time, gets split up into multiple smaller blocks as it is spent in small transactions.  If a large transaction is required again, those smaller blocks can be joined up again, in any order with any other blocks.  So, how then does the Bitcoin transaction fee get divided up?

Does each transaction get traced back to the original mined block, across all joins/splits over time, to properly account for each miner's contribution to this particular transaction, so the payment can be divided up fairly?  Or would this be too much overhead, and a simpler technique is used?  I tried to read up how the Bitcoin protocol rewards miners over time, but couldn't find an answer for how it handles transactions that are a mixture of value from various different mined blocks over time.  Am I not getting something here?

Thanks!

Josh

Hi there!

Question: If a Bitcoin transaction is sent, and the transaction fee is zero (or not high enough), the transaction will not be forwarded through the network, because other transactions have priority and took up all allowed space.  So, the transaction will not go out.  I'm wondering how long it is necessary to wait, before the transaction expires?  Does it ever expire, or is there a risk that some far point in the future your transaction could suddenly go through?

Is it possible to resubmit the same transaction (spending the same coins twice), but the second submission has a higher transaction fee, so it overrides the first transaction and effectively cancels it?  Or does the Bitcoin protocol not support this?  Or is there something I'm missing?

Thanks!

Josh