It seems to be a bug in geth, try the solution presented here : https://github.com/ethereum/go-ethereum/issues/2173
they assume that the solution is :
Convert all values to hex (with bc if you use bash)
Make sure to specify both gas and gasPrice! Enclose all values in single quotes
eth.sendTransaction({from:'0x123456', to:'0x123456',
value: '0x8AC4270ACC4B7FF7', gas: '0x5208', gasPrice:
'0x4A817C800'});"
Firstly, great that you are learning more about DApps, it's always great to see the community growing. However, you do have some misunderstanding about the way the DApps should be designed, so I'll try to point you in the helpful direction.
Technology Used: Ruby on Rails (Back-End), React (Front end), Solidity(Smart Contract)
As pointed in this answer:
A DApp has its backend code running on a decentralized peer-to-peer
network.
DApps by definition don't have classic backend, like the RoR would be. That means, in order for your application to be called DApp, the smart contracts should contain all your backend logic. The frontend could be any JavaScript, really, along with the web3 library that gives you the APIs to communicate with the smart contract backend.
This is a completely different paradigm, which I had problems wrapping my head around for quite some time. There are decentralized alternatives for some of the classic technologies, such as IPFS or Swarm for storage or hosting your DApp website on, "users" should be tied to blockchain addresses, you could use PouchDB, etc. The DApp should be fully open-source and autonomous.
If you wish to build the betting DApp, you really don't need to store user information in database - you can program the frontend and, for example, interact through the contract which sends the % of any bet to contract in your control and have sound business model while providing good service DApp users. But if you want each bet on blockchain, the transaction costs would sometimes prove too high. However, this doesn't mean that you can't have hybrid app - true DApps in their current state do have some limitations.
Working on Lemon Email, we had to weigh some of the benefits of the established technologies (SMTP server for example) along with the benefits of decentralized applications - so we decided to create the DApp to suit everyone. We used the Ethereum Blockchain to store metadata of our interactions, and IPFS as our storage. If you wish, you can read more about our architecture here.
Some additional reading:
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://ethereum.org/dao
https://www.packtpub.com/big-data-and-business-intelligence/mastering-blockchain
Best Answer
I found this to work to call a function and send Ether with it,
to
is my contracts address,value
is the amount in wei I want to send with it anddata
is the address of my function that I want to call when sending the data