BTC Pay and Receive in Smart Contracts

General Counterparty
1

I’ll admit that I haven’t dived into the smart contracts yet.  But I am hoping someone can answer these questions for me:


1) Do counterparty contracts support sending and receiving native BTC to a contract address?

2) If not, is this on the road map any time soon?


Thanks.
2

I’ve heard that this is indeed possible, I’ll try to find out specifics.

3

See this: https://github.com/CounterpartyXCP/counterpartyd/issues/452#issuecomment-64844137

It looks like the reading of balance status would be possible, but not the execution of BTC Pay.

I do not know if results of Smart Contracts could be used as value broadcasts to release BTC payments stored in bets and so on.
4

A contract cannot move BTC as it can’t hold private keys. Instead we need a way to peg a native Counterparty assets to BTC.

5

Why wouldn’t a Turing complete smart contract be able to generate a Bitcoin wallet?

6

@xcp90, I think kordova above said why. 

If anyone could read the contract, they could see it contains your private address.
If anyone couldn’t read the contract (e.g. see the address and the private key) how could they know whether the contract does what it claims it does (or whether the “obfuscated” key is really the private key for the stated address)?

7

Serpent will be able to make RPC calls to external programs. There’s no need to hard code the private key into the contract. Hard code the RPC call instead, and let the contract manage the resulting Bitcoin wallet. The contract could verify ownership of the public address by signing a message in the most simple of cases. It could also run a full blown proof of reserves scheme.

It would still come down to trusting the maker of the Bitcoin wallet, and optionally the cosigners on the resulting multisig address, because the wallet will have to run on someone’s hardware. But what’s stopping me from setting this up myself to help smooth over OTC trades? You can do blockchain monitoring in any programming language, and trigger an action upon receiving XCP. So it is in fact possible to do, the only question is, is it a good idea for your use case.

There’s nothing stopping someone from setting up a DEX like this, too, for example. The DEX operator lays out the contract which generates a multisig Bitcoin wallet. It could algorithmically pick multisig cosigners, call it 12 oracles, which determine what to do with matched orders. Send BTC to the DEX operator’s multisig address and you can be sure it will be managed in a certain way. There would still be a chance for manual intervention, but in a sufficiently rich and diverse ecosystem with oracles chosen algorithmically, I think it would be more than good enough for most folks.

8

It’s possible like that, but not “out of the box” and it should be said that it breaks the basic premise (no counterparty risk) of Counterparty.

I sure do hope to see a variety of approaches acceptable to various participants - not every transaction and application needs zero counterparty risk. For example for occasional smaller transactions I don’t care to trust 3rd parties over a short period of time.

9

Are Smart contracts already working?  I heard that they were on the testnet and still having problems?


Also, does Counterparty run their own blockchain to run Smart Contracts or do they some how work within the Bitcoin blockchain?
10

The smart contracts are stored in the Bitcoin blockchain (as transactions) and executed by all Counterparty nodes. Smart contracts are indeed currently working on testnet, but they have to be absolutely secure in order to reach the mainnet.

The data storage of contracts is paid in BTC (to Bitcoin miners), and the execution fees (gas) are indirectly paid to XCP holders via deflation by reducing the supply.

11

Thanks deliciousowl.


Here’s what I don’t understand, let’s say that someone tries to create fake transactions that imitate smart contracts, and they get stored into the bitcoin blockchain because miners are not going to accept or reject blocks based on whether or not these transactions are correct. How can Counterparty compensate for this?  Seems like a major problem to me…

Also, what if the blockchain forks, and suddenly these transactions are all out of order, is that a problem?

And I’m curious what gets stored into these transactions?  Do you only store the code for the smart contract or also some kind of results of running that code?

And as mentioned above, the sending Bitcoins in a decentralized way from Counterparty without revealing private keys or prepackaged transactions(that could be copied out of the transaction)… seems like a maybe impossible issue…

12

Cross-chain trading (and BTC) should be possible: https://en.bitcoin.it/wiki/Atomic_cross-chain_trading (and the devs already mentioned that they are working on alternatives, smart contracts scripts provide a LOT of room for improvements of BTC trading)

If someone creates fake transactions that initiate smart contracts, Counterparty will just ignore these transactions since they did not pay the necessary fees. It’s that simple. No gas, no go. Those ‘fake’ transactions would essentially amount to littering… They would be completely inert. The issues you are describing are among the first to have been solved. :slight_smile:

And the results of smart-contracts are reached by consensus of the network.

13

 And as mentioned above, the sending Bitcoins in a decentralized way from Counterparty without revealing private keys or prepackaged transactions(that could be copied out of the transaction)… seems like a maybe impossible issue…


What do you mean? 
I don’t remember reading somewhere that private keys are ever disclosed to anyone. 
Prepackaged transactions do not have private keys either - it’s the same as Bitcoin does it.

14

What prevents someone from taking those prepackaged transactions out of the smart contract and sending them as normal transactions?

15

I googled prepackaged transactions and I’m really having trouble understanding what you mean. What do you mean?

16

I understand that prepackaged means precompiled.


What prevents the issue you mention is simply the same logic that works with all other transactions - they’re signed. You can’t recreate them by impersonating some address you don’t have control over.



17

I want to send deliciousowl 1Btc if certain conditions are met. So I package it into a smart contract and put it on the network. Those conditions aren’t meet but the smart contract contains everything needed to make that transaction. So he pulls the transaction out of the SC and send it to Bitcoin and gets paid anyway.

What prevents it?

18

Okay, I understand your point now. 

Consensus rules should prevent it, although I haven’t looked at SC’s or tried to use them yet. Maybe someone who’s tried knows.
19

Indeed that is directly not possible, BUT you can trade BTC for XBTC using atomic “cross-chain” trading using shared secrets and other types of smart contracts. XBTC is an asset that is 1:1 in value to BTC. And then you can use XBTC in any smart contract for any purpose possible. So essentially what you are trying to achieve is absolutely possible, although with a small extra step.

20

You should definitely be able to do this with serpent, although it will involve one of two workarounds.

The least efficient approach would be arranging for the smart contract to generate a multisig address. It’s inefficient because you’d have to run that contract on either your computer or a server somewhere, and trust that its private key would remain safe on that computer.

The other, better approach is to use a federated peg, which is what Blockstream is using for sidechains before soft forking Bitcoin Core. In a federated peg, you’d send your BTC to a multisig address, which would create a balance of XBTC on Counterparty’s ledger. Do whatever you want to with XBTC, hold it directly in a normal Bitcoin address, and whenever you feel like it, unpeg it back into normal BTC.