Bitcoin with Smalltalk

I have been following Bitcoin since its first bubble in 2011. As a social phenomenon it has been captivating, it is like witnessing the wild west from my armchair.

A couple of things one may want to know before diving in:

* The Bitcoin universe is full of crooks trying to steal coin from you and it seems they are becoming rather sophisticated lately. Dictionary attacks on so-called brain wallets seem to be very successful at this point in time. The Silk Road take down further illustrates that crookedness can go way beyond stealing into the realm of assassination plots.

* Many sites were you can store Bitcoin turn out to be fly-by-night operations. Several times such operations took half of the Bitcoin trusted to them and returned only part to the rightful owners. For some reason this maneuver has lead to applause rather than ostracization. Since the first heists on sites that handle Bitcoins it is public knowledge that renting virtual servers to run your Bitcoin software is like giving the combination of your safe away to strangers. Most fledgling Bitcoin-handling sites run their wallet on such servers anyways. These and similar events demonstrate that there is little self-cleansing and mutual education going on in the Bitcoin ecosystem.

* Bitcoin is designed and promoted as being decentralized. However when you look at actual technical incidents on the Bitcoin network you realize that the system is extremely centralized. The decision making of Bitcoin protocol changes is supposed to be spread out over  the miners, it turns out they lack the technical knowledge needed for such decisions and vote blindly for whatever the core developer crew promotes. These developers are roughly five people situated in western countries only.

* Core Bitcoin developers themselves can be malicious: one is documented as putting religious messages into the ledger and to have conducted cyber attacks on alternative virtual coin implementations.

* Bitcoin is not the only kid on the block. At its heart is a distributed consensus algorithm that takes loads of energy to maintain: currently estimated around 80 MW(!) continuously. Since the introduction of Bitcoin more economical (as well as faster) distributed consensus algorithms are appearing, I know of one: the Ripple protocol. Thus Bitcoin may be obsoleted before its take-off reaches escape velocity.

* Bitcoin has by design built-in limits to create artificial scarcities, which in turn create markets that are put in place to stabilize the network. Some of these limits are maintained by an algorithm (for example the mining difficulty adjustments) other are maintained by politics: the minimum required transaction fees and the maximum transaction volume. These political decisions appear to be made by only a subset of the core developers. Currently the maximum transaction volume is set such that it bottoms out at about 7 transactions per second. When the Bitcoin network reaches this limit there will emerge a competitive market with rising transaction costs. Thus it is written in the stars that Bitcoin is *NOT* a micro-payment network even though it is advertised as such.


The above are some warnings one normally does not see compiled together, altogether I am bullish on the virtual currencies phenomenon but have grown very wary of the discrepancy I see between the (unintentional?) propaganda and what I observe in real life.

On 11/7/2013 5:49 PM, Paul Baumann wrote:

 

Why Smalltalk? Smalltalk code is able to evolve quicker than code of most other languages. If you want raw bit twiddling performance then use C. If you want to write a business application that needs to adapt quickly to changing market conditions then use Smalltalk and wrap a shared library when necessary. Crypo-currencies are already implemented in many languages. Most code is readily available as open-source on github.com. Smalltalk can build on these technologies faster than other languages. Smalltalk can accommodate application complexity and can dominate through rapid adaptation over time.

I would consider this a minor (but not unimportant) feature. Where Smalltalk could shine is where reflection is needed.
It would be a great research tool if Smalltalk were not merely used to implement aspects of the Bitcoin protocol (or its support services), but also provide a higher-level model such that it is possible to make mechanized assertions of certain security criteria.
If the same could be done for the Ripple protocol we could offer the digital currencies ecosystem an agile testing ground for new ideas.

 

As an example of the money that people recognize around Bitcoin, there is a 300 BTC bounty (about $90,000 USD) listed here: http://Bitcoinmagazine.com/7961/mastercoin-a-second-generation-protocol-on-the-Bitcoin-blockchain/. If that much is offered just to implement technology that builds on Bitcoin then understand how much could be leveraged by using the technology.

This particular bounty is given out by a long-time Bitcoin holder (probably a multi-millionaire on paper now) to get something very exciting (a distributed stock exchange) going. I would caution against reading such offers as a measure of development value though. Having said that: it would be very exciting to make commodity markets work without a centralized authority. I don't know about the revenue model though, freemium will not cut it in this ecosystem :-)

There are many opportunities. A crowd funded project is one way to get started. Consider the complexity of the blockchain and how few companies currently provide blockchain analysis (GS/S would be perfect for this). Then consider that alt-coin variants of Bitcoin use similar technology but few of them have any blockchain analysis tools. I'd love to see Smalltalk mentioned in Bitcoin circles. Remember me when you get rich off this. :)

 

One of first requirements is to interact with the Bitcoind daemon (part of Bitcoin-QT). I'd like to see this as a core service of all Smalltalk dialects. Smalltalk vendors should implement this immediately just to keep Smalltalk relevant for the next decade.

Mind yer hyperbole, Bitcoin is not needed to keep Smalltalk relevant ;-)

I also do not think it is wise to make it the vendor's responsibility to acquire the knowledge needed to not screw this up.

A single dedicated group offering a 'virtual currencies library' for multiple ST dialects would seem more appropriate for this type of knowledge. Perhaps the STIC could be more relevant here than individual vendors, but more probably we will need a benevolent dictator.


While interfacing with the reference implementation (Bitcoin-QT) is a must-have, it is probably not where the action is.
Interfacing to centralized third parties that enable Bitcoin to be traded against goods and commodities is where I see the money being made.

So i guess we would also want
-- libraries to handle consumer transactions through other parties (Wrappers for BitPay and similar merchant integration services for Bitcoin. And don't forget about Ripple)
-- interfaces to make money by trading money , the whole forex thing but tailored for Bitcoin and Ripple (Smalltalk for bankers ... again)
-- libraries to create overlay networks on top of Bitcoin, Ripple and others. For example to implement nano-payments, autonomous agents, mechanized escrow, automated electricity routing, 'smart property', 'distributed mechanical turk' etc, etc, etc.

Many people will be able to build rich applications from this starting point. This will quickly draw people to Smalltalk. Don't wait for vendors though, we should know from experience that Smalltalk vendors are slow to add support for new technologies and then contributions meet further "not built here" delays. This is an issue of pride and control that has always hindered Smalltalk growth.

Meh, I think it is simpler than that: Smalltalk vendors treat Smalltalk like any other language. In conversations I almost invariably hear 'but X does it this way'. The measure is simply put waaaay to low (out of ignorance, not out of pride or a desire for control).

Linux is the dominant OS for crypto-currency development, so use it from the start if you want to easily participate in this broader development community. You may have to blend languages. You likely have to translate code and refine.

I would predict that the revenue is in end-user facing applications. This might be a web server running on some *nix, but I would expect Smalltalk to shine in agile UI development. This would mean: mobile, mobile and mobile with a pinch of Ms Windows thrown in. Do note that the revenue is in the business model not in the software...

 

This is a call to arms. If Smalltalk doesn't evolve together then Smalltalk will certainly be abandoned separately.

Smalltalk itself seems incapable of evolving much. I only see significant progress when individuals stand up and do something (RB, SUnit, Pharo, Newspeak, Traits, Seaside etc). The vendors will happily jump onto bandwagons that seem to have overcome initial inertia.

I think the Smalltalk ecosystem is very unhealthy in that we developers seem to expect vendors to take up the slack left by the absence of commercial third party library developers.



I also think Smalltalk could be an outstanding platform to support virtual currency deployment.


Reinout Heeck
-- speaking on my personal behalf, not my employers even though I wrote this on his dime --
(disclosure: I own several kinds of virtual currencies)

 

Paul Baumann

 

 

 

 

 

 

 

 

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I'm interested in ripple, and mastercoin.

Ethereum has lofty goals, but I'm starting to be afraid they're never
going to launch -- maybe this would even be a good thing because the
good ideas would be incorporated into other projects.

Mastercoin is showing signs of slowing down, but is well funded, and
by building on the bitcoin blockchain rather than securing their own
chain with an alt coin they are at the forefront of treating bitcoin
as a sort of secure transport layer for building other tools; assuming
they can keep moving development forward and not fall into turing
tarpit mode.

Ripple is totally orthogonal to bitcoin, using consensus rather than
proof of work and a "centrally managed for now" distribution model
that has pissed people off and earned them distrust among the
cryptorati, but which I think may work for the top down "get the banks
on board" approach they seem to be following. 3 second rather than 10
minute confirmations are also nice.

And yes, I think smalltalk could serve a very nice niche in the crypto
2.0 ecosystem.

On Fri, Mar 21, 2014 at 11:11 AM, Paul Baumann <[hidden email]> wrote:
> I agree.
>
> Look at ethereum. It is behavior and data combined into kinda-like object oriented. The behavior is duplicated for every "object" (there is no reuse from a class). The behavior appears to be one method that would check data for what to do. Try reading the syntax of even their five line namecoin solution and you wonder how it could behave a promoted.
>
>         if tx.value < 25 * 10^18:
>             stop
>         if contract.storage[tx.data[0]] or tx.data[0] < 1000:
>             stop
>         contract.storage[tx.data[0]] = tx.data[1]
>
> The above syntax is very basic but I don't see a way to read it that looks functional. For example, the line "if contract.storage[tx.data[0]] or tx.data[0] < 1000:" appears to be attempting to store tx.data[0] (whatever that is) and if that fails then "stop" only if the data is less than 1000 bytes. If it failed and is larger than 1000 bytes then it is going to repeat the failed storage and compare the result with tx.data[1] for no purpose? I don't see how to read that code. Even if "=" is assignment then it storage seems to still happen before assignment (to the result?). I'm sure I could read the rest of http://blog.ethereum.org/2014/02/03/introducing-ethereum-script-2-0/ to figure out what it is really doing, but the point is that it reads like gibberish to the point where it might be easier to read the op codes.
>
> If those five lines really do something useful then important details are entirely within both the tx data and contract.storage implementation. If everything meaningful is hidden in secret squirrel stuff then how can etherium also be flexible enough for more useful things? I trust my confusion is just a learning curve to work through, but it seems there is much opportunity for improvement.
>
> I had been thinking that maybe it would be useful to have tools to browse code in the ethereum blockchain. It would be good to decompile ethereum bytecodes for code maintenance in Smalltalk syntax. Smalltalk is easier to use and maintain. The bytecodes would perform the same regardless of the syntax it is decompiled to; however, if the Smalltalk->bytecode generator is well written then it is possible the tool could be used to optimize code too. It could decompile to self-reducing nodes that generate a more efficient form of bytecode (perhaps with a target strategy for either size, speed, or cost). Perhaps the nodes could self-reduce to a class with multiple methods. Perhaps there could be a way to call reusable behavior from the blockchain.
>
> I love the goal of ethereum, but the more I look at it I think it is a long way from growing into a useful object oriented cryptocurrency. If this is the second generation of crypto currency then it looks like Smalltalkers have the opportunity to define a third generation OO form that is both useful and maintainable. Some form of code royalty system could be used.
>
> Paul Baumann
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of PhilipGlover
> Sent: Friday, March 21, 2014 00:44
> To: [hidden email]
> Subject: Re: [vwnc] Bitcoin with Smalltalk
>
> I'm new to smalltalk, but I've been studying Bitcoin for a while now and, if I understand the message sending nature between objects, I think an object oriented cryptocurrency would be even more effective, and particularly more efficient for confirming transactions.
>
> Thoughts?
>
>
>
>
> --
> View this message in context: http://forum.world.st/Bitcoin-with-Smalltalk-tp4719921p4750132.html
> Sent from the VisualWorks mailing list archive at Nabble.com.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Philip,

 

Here is my understanding of what you are proposing...

 

Put 1 BTC into an address. The private key for the address becomes a unit of exchange. Each unit can be represented on the blockchain as a 1 BTC contract/object (behavior and data). The private keys are encrypted within each object and can only be used by through object behavior. A user's wallet contains private keys for each object (not the private key of the unit represented by the object). Think of each object private key as having been printed to paper (or card) for cold storage. Any wallet can do basic queries to learn what each object is capable of doing, but the private key of the object is proof of authorization to use private object behavior (like spending or conversion). One private behavior would be the ability to transfer authorization to the owner of a new private key (of the object). In effect, you have behavior-rich blockchain-managed version of a physical bitcoin that can be privately exchanged between people somewhat like a 1 BTC cascacious coin can be. The BTC value need not be spent because ownership of the object can be updated. Ownership is anonymous because object addresses are unique never combined. It is similar to colored coins but with behavior on the blockchain and an object having a fixed and recognizable value. A private behavior of a 1 BTC object would be the ability to transform (or exchange) itself in the blockchain with 1,000 mBTC objects. The wallet may have behavior to automatically transform many smaller units into fewer larger units. The behavior becomes a way to "color" coins, transfer coins with anonymity. Objects can also have behavior to participate in escrow services.

 

I think you are also saying that ownership of the object(s) can be updated offline too. That is the part that I don't see working. I think you still need object ownership to be recorded and verified through a distributed public ledger. You cannot prove a unique copy of the ability to use each object, you can only have a standard for determining what transaction for the same object is first (and subsequent are rejected).

 

Another tricky part of what I think you've said is a virtual representation of something physical (like a 1 oz Gold Maple coin). You could have an object represent the gold coin, but it seems like the gold coin object should be backed by a physical gold coin. I think the Ripple way of having a gold broker is a way to make it work, but it is a debt-based system of trust that is subject to fraud. If anyone can mint their own brand of gold coin objects then a system of broker reputation becomes important. The BitShares development is trying to figure out that solution now. Last I heard is that they original plan for prediction markets may not work.

 

What we need is the ability for any broker to define the behavior and quantity for a class of objects that the blockchain is able to execute behavior for. When a broker gets another gold coin in the vault then he can issue a gold coin object (a certificate/contract) for that physical coin. The certificate is tied to the reputation of the broker alone (not all the other gold coin certificates that other brokers may create). The certificate can be traded. The certificate would be the right to exchange for the physical coin.

 

You have good ideas. Thanks for sharing. There are already variations of what you are suggesting, but nothing that combines them all into a nice OO framework.

 

Paul Baumann

 

 

 

From: Philip Glover [mailto:[hidden email]]
Sent: Friday, March 21, 2014 14:57
To: Thomas Hartman
Cc: Paul Baumann; [hidden email]

Subject: Re: [vwnc] Bitcoin with Smalltalk

 

I'm inclined to agree with you regarding the opportunity for an OO currency to accomplish what ethereum has set out to do, but in a much simpler and elegant manner. It seems to me that the goal of ethereum was to create a new language for all of these new fangled cryptocurrency and smart-contract platforms to coexist within, but I believe they will end up being inherently limited by trying to produce a language in the first place. If the currency was created within an object-oriented environment, it could simply define the way it was manipulated within the limitless environment created by objects sending messages to each other. 

Smalltalk offers the opportunity to create currency/units-of-value/smart-contracts that are self-referencing, and therefore self-descriptive. With Smalltalk we can create a currency in which the units of exchange are persistent objects that understand themselves with reference to a trustless ledger or blockchain which in turn understands itself. Better yet, the unit-of-value object understands that it is unique, and can only be modified, moved, or split-up by being sent the proper message by the owner with the proper key.

An OO environment allows us to create the currency with virtual behavior to reflect the behavior people are intuitviely used to with physical commodities like gold. In short, what I see is, where Bitcoin requires addresses and a blockchain to prevent double spending, the OO currency would prevent double spending by having a defined message set between the units of the currency themselves. 

I'm speaking hypothetically here, but perhaps an exchange of the currency would occur when the owner of object X agreed to transfer the object (or part of the object) to a new owner. A transaction would be performed when the object was sent a message to change ownership between two access-objects, let's call them Wallets. Each transaction would transform the object into a new object, or set of objects. If the object/currency is only modifiable by a set of instructions arrived at by the consensus of the users, I'm fairly certain this also makes counterfeiting of the currency impossible. You no longer have to update a blockchain, the objects just contain within themselves some sort of proof-of-existence, by proving they've only been manipulated by the agreed to instruction set. This could allow for completely ad-hoc exchanges, where objects are just manipulated by the intrinsically sound message protocol.

Obviously this is just an idea I'm trying to describe in real-time, so it could probably use some revision, but I think we can make a much simpler and far more robust cryptocurrency by making the currency out of cryptographically-protected, consistent object manipulation.

The analogy I can think of is give the objects that act like the unit of value the properties of gold. Gold can't be double spent because there is only one object. Create the object so that by self-definition, the only way it can be spent is by transforming itself into a new set of objects of an equal quantity.

What do you think?

 

On Fri, Mar 21, 2014 at 11:30 AM, Thomas Hartman <[hidden email]> wrote:

I'm interested in ripple, and mastercoin.

Ethereum has lofty goals, but I'm starting to be afraid they're never
going to launch -- maybe this would even be a good thing because the
good ideas would be incorporated into other projects.

Mastercoin is showing signs of slowing down, but is well funded, and
by building on the bitcoin blockchain rather than securing their own
chain with an alt coin they are at the forefront of treating bitcoin
as a sort of secure transport layer for building other tools; assuming
they can keep moving development forward and not fall into turing
tarpit mode.

Ripple is totally orthogonal to bitcoin, using consensus rather than
proof of work and a "centrally managed for now" distribution model
that has pissed people off and earned them distrust among the
cryptorati, but which I think may work for the top down "get the banks
on board" approach they seem to be following. 3 second rather than 10
minute confirmations are also nice.

And yes, I think smalltalk could serve a very nice niche in the crypto
2.0 ecosystem.

On Fri, Mar 21, 2014 at 11:11 AM, Paul Baumann <[hidden email]> wrote:
> I agree.
>
> Look at ethereum. It is behavior and data combined into kinda-like object oriented. The behavior is duplicated for every "object" (there is no reuse from a class). The behavior appears to be one method that would check data for what to do. Try reading the syntax of even their five line namecoin solution and you wonder how it could behave a promoted.
>
>         if tx.value < 25 * 10^18:
>             stop
>         if contract.storage[tx.data[0]] or tx.data[0] < 1000:
>             stop
>         contract.storage[tx.data[0]] = tx.data[1]
>
> The above syntax is very basic but I don't see a way to read it that looks functional. For example, the line "if contract.storage[tx.data[0]] or tx.data[0] < 1000:" appears to be attempting to store tx.data[0] (whatever that is) and if that fails then "stop" only if the data is less than 1000 bytes. If it failed and is larger than 1000 bytes then it is going to repeat the failed storage and compare the result with tx.data[1] for no purpose? I don't see how to read that code. Even if "=" is assignment then it storage seems to still happen before assignment (to the result?). I'm sure I could read the rest of http://blog.ethereum.org/2014/02/03/introducing-ethereum-script-2-0/ to figure out what it is really doing, but the point is that it reads like gibberish to the point where it might be easier to read the op codes.
>
> If those five lines really do something useful then important details are entirely within both the tx data and contract.storage implementation. If everything meaningful is hidden in secret squirrel stuff then how can etherium also be flexible enough for more useful things? I trust my confusion is just a learning curve to work through, but it seems there is much opportunity for improvement.
>
> I had been thinking that maybe it would be useful to have tools to browse code in the ethereum blockchain. It would be good to decompile ethereum bytecodes for code maintenance in Smalltalk syntax. Smalltalk is easier to use and maintain. The bytecodes would perform the same regardless of the syntax it is decompiled to; however, if the Smalltalk->bytecode generator is well written then it is possible the tool could be used to optimize code too. It could decompile to self-reducing nodes that generate a more efficient form of bytecode (perhaps with a target strategy for either size, speed, or cost). Perhaps the nodes could self-reduce to a class with multiple methods. Perhaps there could be a way to call reusable behavior from the blockchain.
>
> I love the goal of ethereum, but the more I look at it I think it is a long way from growing into a useful object oriented cryptocurrency. If this is the second generation of crypto currency then it looks like Smalltalkers have the opportunity to define a third generation OO form that is both useful and maintainable. Some form of code royalty system could be used.
>
> Paul Baumann
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of PhilipGlover
> Sent: Friday, March 21, 2014 00:44
> To: [hidden email]
> Subject: Re: [vwnc] Bitcoin with Smalltalk
>
> I'm new to smalltalk, but I've been studying Bitcoin for a while now and, if I understand the message sending nature between objects, I think an object oriented cryptocurrency would be even more effective, and particularly more efficient for confirming transactions.
>
> Thoughts?
>
>
>
>
> --
> View this message in context: http://forum.world.st/Bitcoin-with-Smalltalk-tp4719921p4750132.html
> Sent from the VisualWorks mailing list archive at Nabble.com.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.