Topic: [ANN] Let's run native Python smart-contracts on the Bitcoin blockchain (Read 512 times)

Is this dead?

We have built an entire contract ecosystem on top of the original Bitcoin blockchain.   


could anyone share more detail of how the contract ecosystem are built?

The discord channel can be reached via: https://bitcoinpy.io/discord

any updates here? Discord?

That is actually a very good idea! I will set it up today 

do you plan on having a discord?

Here is a very inefficient version of a miner.
It is inefficient on purpose: the goal was to make it very small and easy to understand.
Many inline comments have been added to understand exactly what bytes are hashed how!
It should be enough to come up with something super efficient, maybe even GPU enhanced.

https://github.com/pycontracts/inefficient_reference_miner

... or ask specific questions. I am happy to include them all in a FAQ section. But it is hard for me to decode and parse the scope of "more".

You can just basically visit their website and read the whole whitepaper instead of waiting about their answers.

Can you explain more

We will most likely finish the GAS miner today and publish it on Github before anything else. This way we can guarantee that everyone has enough time to create their own, optimised GAS mining equipment before the project goes live. Everything else would be unfair and people might (correctly) argue that even though the project is launched in a fair manner, the developers would have had way more time than everyone else to create optimized versions of the mining algorithm, which again would give them an unfair advantage.

Great and interesting project! I hope you could post also the roadmap so that we could know the future of this project.

Hot

Alright guys,
let's run smart-contracts on the Bitcoin blockchain!


Current Status and Pending Work

- Implementation of core client, Qt interface, Contractpython interpreter and compiler are finished and ready for release
- Documentation on the website is pending
- Some more testing is pending, especially whether the VM functions predictably on multiple architectures (with varying endianess and pointer lengths)


Collection of Links

- Website: https://bitcoinpy.io (will grow over time)
- Video Demonstration: https://bitcoinpy.io/sneekpeek (get a feeling for how easy it all is) [HOT!]
- Documentation: https://docs.bitcoinpy.io/ (incomplete, currently pending work)
- Discord: https://bitcoinpy.io/discord


Contribute

If you want to contribute, please feel free to fork any of the current public github repositories and send us a pull request:
- Main website: https://github.com/pycontracts/gatsby_website
- Documentation: https://github.com/pycontracts/docs
- Build your own miner based on the inefficient yet easy to follow "reference" implementation:
  https://github.com/pycontracts/inefficient_reference_miner


A Brief Overview



What is BitcoinPy?


Bitcoin has been around for almost 10 years now. However, despite its use as a store of value and a means of quickly transferring monetary value from A to B, it lacks any other use-case. However, during the recent years new ideas have emerged, one of which are "Smart Contracts" - virtual contracts which are settled based on the "code's law". Think of it as contracts, that have a hard coded set of when-then rules and which cannot be tampered with by any involved party. Ethereum is the first (and so far only) project that has created a well done and nicely useable smart contract ecosystem, although there have been numerous copy cat attempts which implemented their own blockchain layer and are now struggling with an alternation of adoption problems and 51% attacks. We want to suggest how smart contracts, in a similar fashion as implemented by Ethereum, could be brought to the Bitcoin blockchain. BitcoinPy can be considered a "second layer" addition to the original Bitcoin protocol. The goal is to enable Turing-complete smart contracts that run on the native Bitcoin blockchain. But that is not enough, our vision was to make it as simple as possible. While Ethereum requires either advanced low-level byte code skills, or proficiency in a custom programming language termed Solidity (a lack of a full understanding of this new language may result in things like the DAO hack or the Parity disaster), our requirement was to keep it as simple as possible: in our solution, users simply code their smart contracts in Python, a language that many are already familiar with and, as such, are likely to avoid such expensive mistakes.


Why did we choose to develop a Bitcoin extension
instead of a creating a new blockchain?


With so many new blockchain solutions popping out of the woodwork every day, and the Bitcoin hard fork frenzy we have just recently experienced, we felt it's time to improve upon existing solutions. So, why not make use of an already adopted Blockchain, which is already thoroughly tested and has a strong consensus? That is what we did. We have built an entire contract ecosystem on top of the original Bitcoin blockchain. As we do not manage the blockchain, that means we have no more power or decision right than you guys, and the likelihood of attacks, that usually targeted at chains with low adoption such as the fifty-percent attack, is negligible.


This is no fork of the Bitcoin blockchain


BitcoinPy is no hard- or soft fork, and therefore 100% compatible with all other, traditional and unmodified Bitcoin clients. BitcoinPy is a second-layer addition to the existing Bitcoin protocol. As such, it is fully compatible with the entire Bitcoin network in its current stage and with all other traditional Bitcoin nodes running the unmodified Bitcoin core client.


Developing smart contracts for the
Bitcoin blockchain in Python: isn't that cool?


BitcoinPy features smart contracts that are written in Python. As most developers are already familiar with it, the entry barrier is quite low as there is no need to master yet another contract-specific language first. Not only can we assume, that the number of accidental contract bugs is likely to be lesser compared to other platforms with more complex, novel programming languages, but contract developers also do not need to bother about complex nodejs-based toolchains, browser-based development IDEs, or other deployment nightmares. Just code your smart contract using your favorite editor and a Python shell and if you are comfortable with the result, upload it to the blockchain at the click of a button.


But is executing Python code of
untrusted origin safe in the first place?


All Bitcoin Core clients with the BitcoinPy extension have an integrated Python VM, which runs the smart contracts and which is highly modified to ensure integrity and correctness of the results on numerous architectures. Furthermore, it not only limits the CPU instructions depending on how much GAS is supplied by the contract caller, but also provides a friendly interface for developers to access the blockchain's metadata such as the current block, the sender and amount, and others parameters directly from within the contract. Also, the VM supports most of the typical contract abortion methods, such as reverting and suiciding, that we are already used to from Ethereum.

The details on how the VM actually works, how the contracts are compiled into byte code and later executed, and what developers should pay a special attention to will be added to the documentation over the course of the next days.


Bitcoin and GAS: Why this separation
and what is GAS in the first place?


While traditional BTC, for obvious reasons, is required to pay for the transaction fees on the Bitcoin blockchain, GAS - a new token that is also stored purely on the Bitcoin blockchain - is used by those who call a contract to pay for the CPU time a contract needs to execute. You can see GAS as the fuel for the Python VM; the more complex a contract is, the more resources it eats up when the nodes execute it, the more GAS the execution costs. However, sending GAS and creating contracts, regardless of their size, does not cost anything except the BTC transaction fee. The reason we need to use GAS, and cannot rely on BTC only, is that contracts can automatically produce multiple internal transactions, e.g., paying multiple users from the contract's balance. The BitcoinPy GAS can handle this very good; Bitcoin alone on the other hand would require the contract to sign every single internal transaction - and you really do not want a public contract to be able to sign anything :-)


Strict no funding policy:
No ICO, No Premine, No Baloney


Over the past two years, we have experienced an influx of mediocre projects that seemed to have a strong focus on marketing - purportedly to achieve a good income from their initial coin offering - rather than on writing good code and improving upon the Blockchain as such. We want this project to be all about the technology without any other disruptions. Therefore, it is paramount to us, that the entire development of this program is truly "libre." There will be no initial coin offering, no pre-mine, no bonuses, no signature campaigns, and no paid-developers who work for the money and not for the greater cause. BitcoinPy launches with no GAS in circulation at all: if you want some GAS, you have to mine it yourself. Even though some developers, who contribute to this project, might privately mine GAS on their own behalf, they have no advantage over anyone else. It's an even playing field.

BitcoinPy can be considered launched the moment the code is available on GitHub and available for everyone to try out (we will give a notice of at least 30 minutes).


It will be all free open source


BitcoinPy is open source and hosted on Github (well, it will be once we publish all code). We are a non-profit group of developers, the kind you would find at your local CCC conference, trying to move Blockchain forward to the next level. We believe in free software, we dislike companies, and we think that most code, that paid developers crank out in the blockchain sphere, is hideous at best. But if you are one of those guys who loves Mate, trolls slashdot during the day and altruistically fixes bugs in kernel drivers at night, we would love to see you play around with BitcoinPy. Any pull request or bug report is hightly appreciated.


Transition period during the early launch


Since this project is still exeperimental technology, the launch will include an "early bird" phase where the execution of contracts can be halted centrally (or configured to be executed only in a given time frame) in case something goes wrong. Even though transactions are permanent, during this phase incorrectly executed contracts may be reverted or altered, in a way that they reflect what was originally intended. We expect this "early bird" phase to last a few weeks at most. Then, once it is confirmed that everything works as expected, this "functionality" will be removed entirely from the code. If you do not feel comfortable with this (or disagree with it in any form), please feel free to chime in once the "early bird" phase is over.


When Launch?


The development it finished, everything looks good, and technically it would be possible to launch now! But, as you now, better be safe than sorry. So please give us some time to test everything thoroughly. The Python VM is a highly complex piece of code and we need to make sure that contracts are always executed in the same way, regardless of the architecture (it's endianess and the pointer length [4byte vs 8byte]). Also, we will complete the documentation first before we release the source code so everyone starts from the same baseline.


When Video?


If you want to see how easy it all works RIGHT NOW,
we suggest you take a look at our short demonstration video: https://bitcoinpy.io/sneekpeek



Final Words:


- We are not being funded and we do not fund anyone. This also means, we will not pay anyone for signature campaigns, marketing nonsense, or translations. If you think this is a cool project, feel free to translate it. If you want to earn money, you better go and find other projects where money is the primary driver.
- All software released within the scope of this project is free and comes with no warranty (not even implied) at all. Always read the LICENSE files and use at your own risk.