Topic: bitcoind transaction to ip address (Read 9247 times)

Or gplhost's DTC, thus enabling bitcoin billing by shared hosting / VPS hosting / dedicated server hosting businesses.

I would love to see a bitcoin module for WHMCS.

After reading Insti's post, I think it would be useful to produce modules/extensions/plugins for existing open source eCommerce softwares

http://en.wikipedia.org/wiki/List_of_free_and_open_source_eCommerce_software

Accomplishing this can be through individual efforts, perhaps each effort tailored to a specific eCommerce software.  However, perhaps also/instead a community could be established to dedicate towards providing Bitcoin integration into all/most open source eCommerce software.  I think the community-driven focus on providing Bitcoin integration/support to all is good idea.

Yes, the Iphone app that allows two people who meet in person to exchange contact information.  It would be easy to include a bitcoin address field that could be accessed by the Iphone bitcoin client to permit one to send money to the other immediately.  This wouldn't work in the absence of service or a network outage, however, so it's not the ideal solution for direct IRL transactions.



I don't.  In fact, I don't think that the IP option should even be on by default.  I think that it would be a security risk.  Not only can a probe determine if a particular website/server/laptop-in-the-cafe has a bitcoin client running, and therefore a potentially profitable target for a cracker to break into; performing multiple requests on the same IP could give the attacker multiple addresses to the same person.  By themselves this seems unimportant since cranking the hash math backwards upon one hash begets an astronomical number of possible results.  But crypto can be undermined by comparing the reverse hash results of one to those of the other, significantly narrowing the possible set of public keys that could have begot it.  Not to say that this is a particularly easy computation to make, either; but a possible one.  Of course, even knowing the public key will not help an attacker to steal bitcoins from said person, but it would allow the attacker to search the blockchain and see all his transactions.  This would not only tell the attacker how much this person has, but could also be used to identify the owner by data mining the transactions.  At least that *could* be possible.  I don't know if this has been considered already, or even if this is a realistic concern.  But I do know that a laptop that responds to bitcoin specific ports or requests already says too much.  That alone could make choosing a target for a laptop thief an easy one.

Bump? The iPhone app? I don't understand.

I'm certain that using IP numbers is not the answer. How do you account for Tor?

Beyond the message feature, none that I can think of on the open Internet.  However, it would be useful for direct smartphone-client to smartphone-client trading over ad-hoc wireless.  It would need to be secured, however.

There might still be a better way for two people to do an in person transfer than use ip addresses.  Something similar to bump, perhaps.  An in person transfer would require some kind of two way communications, however, which is not currently required.  In order to allow the receiving client to verify the transaction against it's local copy before the actual transfer.

I was thinking of some sort of simple donations accepted sort of site where you just say send your bitcoin donations to ip address, put your name and email address in the message and we will email you a receipt if you desire one. Or leave your name and address in the message if you want to be added to our mailing list or whatever. You don't always want to generate a full bitcoin receive address just on spec that they will send a donation.

Maybe not the best thought out idea but thats what I was thinking.

I still don't have a perfect grasp of the communication tokens used in bitcoin, but could we not extend the bitcoin proxies ever so slightly to accept another type of payload, a message? This message would be encrypted using the recipient public key and probably a hash of the transaction in question. I'd make completely separate from the blocks, storage wise, probably storing only messages for the last 24 hrs or so on each node.

Of course, to avoid DoS attacks the message needed to be sent after the transaction and be somehow cryptographically connected to it, so proxies can:
1) ignore any bogus message that doesn't relate to a specific transaction
2) find a message related to a specific  transaction (only important on the receiving address, but non-proxy clients would ask the next node, I guess)

Ah ok, you track by new receive address, I understand now. I forgot you can generate an address on the fly like that with a label. Yes, I certainly want control from a website perspective rather than a client only.

So one could generate label "customer_123" for address "" and which a payment comes in to that one address only for the right amount. It won't matter what send address the customer does/doesn't generate. It must be late, I should have seen that before  

That's good to know because it can help integrate with the market sites to do currency conversion so one doesn't have to adjust the BTC prices every day to cope with the market up/down swings.

Sent 10BTC for the help. 

I think we are looking at things slightly differently.

This is how I think you are thinking about your process.

Your shop publishes an address: A_SHOP
Customer does a bitcoin transaction from A_CUST to A_SHOP for 9.95 and passes extra parameters 'from: [email protected]' and 'for: your cool ebook'
Your bitcoin payment system picks up this this transaction.
Your system sends 'cool ebook' to '[email protected]'

Another Customer does a bitcoin transaction from A_BOB to A_SHOP for 9.95 'from: [email protected]' 'for: audiobook version'
Your bitcoin payment system picks up this this transaction.
Your system sends 'audiobook' to '[email protected]'

In my proposed system it works like a traditional shopping cart/checkout system:

Customer comes to your shop.
Clicks the 'buy cool ebook button'
Fills our their delivery address on a web form.
You create a unique receiving address for this transaction: A_UNIQUE1
You note this mapping in your database. A_UNIQUE1 is 9.95 payment from '[email protected]' buying 'your cool ebook'
Your website then presents the customer with the address A_UNIQUE1
Customer does a bitcoin transaction however they like for 9.95 to A_UNIQUE1
Your bitcoin payment system picks up this this transaction.
Your system sends 'cool ebook' to '[email protected]'

Bob comes to your shop.
Clicks on the 'buy audiobook button'
Fills our their delivery address on a web form.
You create a unique receiving address for this transaction: A_UNIQUE2
You note this mapping in your database.
Your website then presents the customer with the address A_UNIQUE2
Bob does a bitcoin transaction however they like for 9.95 to A_UNIQUE2
Your bitcoin payment system picks up this this transaction.
Your system sends 'audiobook' to '[email protected]'

Is that clearer?

The advantages of doing things this way are that you have control over the information that the customer is sending you before they actually send it.
If you decide to sell tshirts and need to include a 'size' field you can easily add this on your web end.
If they're trying to buy something that is out of stock, or if they are below the legal age you can deny the transaction and not give them an address to send to.

PM me if you need any help implementing such a system.

Per the example, how would that process work with what you suggested? How are you going to predict what address they send payment to you as?

This seems like the "wrong" way to be doing things.
Your webserver should be capturing all these details and generating a unique receiving address.
So you know what a transaction to XYZ is for and who it is from.
Then you just need your webserver to query your bitcoind to see if transaction XYZ for 10BTC has occurred.

From and Comment fields

Right now, if you transfer from one address to another, well that's about all the info you get, client ABC transfered 5BTC to client XYZ.

With IP to IP, it would be more like Client ABC transfered 5BTC to Client XYZ, and add extra data like "for a lotto number or stock buy or store purchase, etc."

This would allow website operators to accept transactions with custom data that can be used to further process for other things.

Example; I run a website where if you send me 10 BTC, I'll e-mail back a copy of an e-book. You could use the client "from address" field to plug in your e-mail so that when the 10BTC comes in, the website will know that it just got a payment and send the e-book to the return e-mail address automatically.

Another use is payment documentation. I transfer 100BTC to XYZ person and put in a comment of what it was for "paid 100BTC for a new video card".

Why is ip to ip a useful way to make a transaction?

What if it had a flag for "secure/unsecure" transaction type, where one can have a password for static IP to static IP transactions and an unsecure mode that works like the default IP sending the GUI uses?
If the address based transactions types could send the comments/from field like the direct IP to IP, that would be another reason not to really use the feature (except for testing) 

If someone takes the ip address method to the next level it really should be changed to provide some kind of security, like agree on a password/address or something ahead of time.  Sending to an address and creating the key automatically provides no authentication and there's no recourse if it went to the wrong place; the intended receiver is unaware you even tried to send anything.  It is trivial to proxy it and MITM that kind of activity and with the value of bitcoins rising it might just be worth doing eventually.

I consider the ip address sending a local testing feature more than a production level feature in the way it is currently implemented.  One possibility that could work is if the receiver provided a public key (address) to you first and you used a combination of internet address and public key.  It is not as convenient but the alternative is to just send it to the ether and hope nobody grabs it before it gets to your target.  If anyone has used liberty reserve or something similar you know it is certainly not convenient to log into and such, but when it comes down to a choice of losing your money or dealing with an inconvenience I think most people would prefer the latter.

Well I guess it's time it got some attention 

Dang, that's two things I have to put my list now, good thing it's open source! 

It's not implemented.

It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.

I cant figure out how to send a transaction to an ip address from bitcoind command line interface. Has the function been implemented yet? (linux 64 if it matters)