Determining if contracts should have
their own address prefix (eg; CiLUGp1hc7aooWWh89MAV6Gu11E7tMz267), which
would avoid accidental sends (both BTC and assets) to a contract.
Shall not contracts have the ability to receive BTC? Think if I have a vending machine contract. You send me 0.1 BTC, I return to you 10 MYCOIN. If address begin with C, then how to send BTC?
A contract will never be able to send bitcoin. It can only send XCP and assets.
If a contract address were a valid bitcoin address, there would sure become cases where people would deposit BTC to it by mistake. They would be lost forever.
For your vending machine case, I think the contract can read the balance of another (a real) address and then send assets from its own address.So, yes, you can have a vending machine. @rubensayshi, am I correct?
you’re correct that there’s no private key to a contract, if we’d make contracts actual BTC addresses and you’d send BTC there the BTC will be gone forever because the contract can’t send BTC, it can only send XCP and assets.
A vending machine would require to work with XCP I think.
I don’t think we (initially) have a way to get a BTC balance inside a contract (only XCP and assets), but even if we did I don’t see how you’d be able to do what you describe and check the balance of a BTC address to see if a payment was made, those address(es) would have to be hardcoded into the contract and you’ll have a big mess if multiple people at the same time try to ‘use’ the vending machine contract because you can’t differentiate between who’s paying what.
the only option would be to also have a way to list the TXs in that case and figure out the ‘sender’ if the TX and then you could pay out to that, but that’s not an easy task because the ‘sender’ of a BTC TX can be multiple addresses etc…