Bitcoin with Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Bitcoin with Smalltalk

Paul Baumann

I hope you are all aware of Bitcoin by now. This technology from 2009 is amazing and is changing the world. Crypo-currencies are entering rapid growth and people are now making money by building services around bitcoin. A few people with Smalltalk origins have a hand in bitcoin, but the general silence on forums tells me that most Smalltalkers are not involved in crypto-currencies. Smalltalk was slow on internet services. Smalltalk should be able to catch this wave.

 

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.

 

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. 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. 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. 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.

 

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

 

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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

askoh
Administrator
How can I start learning and thinking about this opportunity for Bitcoin and Smalltalk?

Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Paul Baumann
Here are some good sites:

bitcoin.org (overview and wallets)
thebitcoinchannel.com (good news source)
bitcointalk.org (forum for every topic)
blockchain.info (excellent online wallet)
bitcoinity.org (market charts)
bitcoinwisdom.com (market charts)
bitpay.com (merchant services - BTC converted directly into checking account)
bitstamp.com (US exchange with liquidity)
btc-e.com (fast exchange with greater currency options)
gyft.com (one way to spend with store gift cards)
localbitcoins.com (local in-person trades)
bitmit.net (like ebay but paid with bitcoins)
aLittleBitOfCoin.com (gift cards)

Download a mobile wallet for your phone. Mycelium and blockchain.info have the most features. iPhone users may be limited in this regard (I hear Apple doesn't like competition). You can visit blockchain.info from a web browser if you encounter iPhone problems. There are many options for Android users.

Once you have bitcoins you can quickly send them to anyone in the world. Buy-and-hold is the best option. Keep most your bitcoins safe in cold storage (paper wallets). Spending options continue to grow. The US unofficially limits ways to get USD into bitcoin. I'm not current on which are still good options for buying bitcoins; bitcoin.org will have recommendations. By January you are more likely to see $1000/BTC than $0/BTC ever.

Gold is real money, but not easily divisible. Gold notes made gold more practical. Notes were replaced with fiat backed by "you must accept for all debts" orders which kept fiat in greater circulation (due to Gresham's Law). Fiat is now more easily exchanged electronically, and that convenience has become the inherent value of fiat. Bitcoin is more convenient than a credit card while costing little to exchange. It is a superior form of money/capital/currency/commodity/security/note/asset/etc. There is little agreement on what to call it, but it works well and appreciates like metals should when fiat is devalued. Part of bitcoin going up in price is really fiat having less value. The US can't stop printing money without the whole system collapsing, and the killer is that you'd be expected to pay for what was beyond your ability to stop. Bitcoin is an option to preserve capital and resist hostility. And no, people don't pay Gold for gas today either;  bitcoin is more asset tha!
 n a currency until the holding of fiat is commonly recognized as a liability.

It is easy to see ways to fit Smalltalk into the picture once it hits how exciting crypto-currencies are. Money touches everything.

Of Liberty,

Paul Baumann



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of askoh
Sent: Thursday, November 07, 2013 13:44
To: [hidden email]
Subject: Re: [vwnc] Bitcoin with Smalltalk
Importance: Low

How can I start learning and thinking about this opportunity for Bitcoin and Smalltalk?

Aik-Siong Koh



--
View this message in context: http://forum.world.st/Bitcoin-with-Smalltalk-tp4719921p4719984.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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Reinout Heeck-2
In reply to this post by Paul Baumann
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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Thomas Hartman
Great writeup. I'm going to answer point by point.

I agree 100% with your first three points. Security is a huge problem. Solutions are emerging, but the current situation is bad for the layman. Too easy to get hacked if you do it yourself, too easy to get ripped off if you trust an exchange. But I think this will get better with time.

I also agree with point four, but it's unimportant. So what if there are religious messages in the blockchain? And killing off alt coins... well, whether this is malicious or not depends on if you are long bitcoin or altcoins. There are those who believe that like with Highlander... There Can Be only One ;) I guess time will tell, but in any case it's more of a feature than a bug from the point of view of bitcoin.

Point 5, I disagree. I think bitcoin is doing a very credible job of achieving escape velocity. Ripple is interesting, but it's not a competitor, more of a complement to bitcoin. And, ripple doesn't seem to have much momentum. Ripple and mastercoin compete in the same space to some extent, and I think mastercoin (piggy backing on bitcoin) might actually have a shot at unseating ripple.

Point 6, I mostly disagree. Even with the scarcities baked in, bitcoin could do exceedingly well as a micro transaction backing currency. Especially have a look at


IIUC, the key insight is that microtransactions can be batched and settled, and the settlements can be much smaller in size when they are finally broadcast to the block chain. Alternatively, bitcoin could be used as a clearing currency and there could be various "sub chains" with lower but still sufficient security, to handle the higher volume data.



On Mon, Nov 11, 2013 at 6:02 AM, Reinout Heeck <[hidden email]> wrote:
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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Reinout Heeck-2
On 11/11/2013 7:15 PM, Thomas Hartman wrote:
Great writeup. I'm going to answer point by point.

Thanks for your perspective on Bitcoin, I'll refrain from discussing these details here though -- trying to stay on topic:

I would like to hear your opinions on Smalltalk library creation for Bitcoin.
Which audience do you envisage shoud be catered to, what would you like to see?
Compatibility with which wallets?
Re-create a full node implementaion, an SPV node or merely communicate with the reference implementation?
Support generic virtual currency research?
Concentrate on integration vendor APIs?
etc. etc.


Thanks!

R


I agree 100% with your first three points. Security is a huge problem. Solutions are emerging, but the current situation is bad for the layman. Too easy to get hacked if you do it yourself, too easy to get ripped off if you trust an exchange. But I think this will get better with time.

I also agree with point four, but it's unimportant. So what if there are religious messages in the blockchain? And killing off alt coins... well, whether this is malicious or not depends on if you are long bitcoin or altcoins. There are those who believe that like with Highlander... There Can Be only One ;) I guess time will tell, but in any case it's more of a feature than a bug from the point of view of bitcoin.

Point 5, I disagree. I think bitcoin is doing a very credible job of achieving escape velocity. Ripple is interesting, but it's not a competitor, more of a complement to bitcoin. And, ripple doesn't seem to have much momentum. Ripple and mastercoin compete in the same space to some extent, and I think mastercoin (piggy backing on bitcoin) might actually have a shot at unseating ripple.

Point 6, I mostly disagree. Even with the scarcities baked in, bitcoin could do exceedingly well as a micro transaction backing currency. Especially have a look at


IIUC, the key insight is that microtransactions can be batched and settled, and the settlements can be much smaller in size when they are finally broadcast to the block chain. Alternatively, bitcoin could be used as a clearing currency and there could be various "sub chains" with lower but still sufficient security, to handle the higher volume data.



On Mon, Nov 11, 2013 at 6:02 AM, Reinout Heeck <[hidden email]> wrote:
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




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Paul Baumann
In reply to this post by Reinout Heeck-2

Reinout,

 

I wanted to repond to the many concerns you've raised. Sorry, my responses are long.

 

Yes, bitcoin attracts many crooks. After the initial shock you realize that crooks and money are inseparable. Bitcoin at least avoids theft by those that print the money. There are certainly risks to beware of. Be careful how you store your bitcoins. Use offline/paper wallets for large amounts. Dictionary attacks will likely be growing, so don't use deterministic keys (a wallet based on a pass phrase that you select) because  someone will eventually guess the password. Don't believe everything the government tells you about the silk road. It is easy to see their stories don't hold up when you look deeper. Bitcoin sites do come and go quickly. Buyer beware. Most go because their bank discontinued service as soon as they learned the business was using bitcoins. Government actively discourages your ability to protect your capital from them. None of that will stop bitcoin; it just drives businesses overseas and further decentralized. Next year a law comes into effect were US citizens will not be able to hold foreign accounts. The walls are being constructed. Bitcoin doesn't care, and in fact grows from such intimidation.

 

Your point is that bitcoin can be corrupted, and I can't prove that it can't be. Five people (Galvin Andersen being the primary developer) are most active in what functionality goes into each bitcoin release. Bitcoin is easily converted to an altcoin if you personally don't like an upgrade that miners generally accept. Bitcoin is the most popular crypto-currency, and therefore the easiest to explain to someone new to them. I'm not aware of malicious behavior by bitcoin developers, and I think I'd know about that. Regarding religion (since you brought it up), I expect a variant of bitcoin to be the "mark of the beast" to be imposed by a global organization. Bitcoin itself (and all current variants) are a direct threat to existing state control and the only thing they can do is force a version they can control. The bible says you will have a choice, and I believe common use of safe crypto-currencies will make it harder for a state to impose a malicious one that they can devalue (in place of all forms of taxation) for their unlimited benefit. What I say requires no religious beliefs though. Anyone should be able to see that giving state control over your money supply eventually ends in servitude and ruin.

 

Ripple was owned by a company that could be shut down. Ripple is too complicated and the trading of debt is too much like a Ponzi scheme for me. One new technology that I'm interested in is BitShares (https://soundcloud.com/mindtomatter/e57-protoshares-and-selfish). An ounce of gold has seen countless wars and costs over the years. Electricity consumption for bitcoin mining may seem modest in comparison. Something of value should be hard to produce. The price is no higher than what people are willing to pay. Mining difficulty can imply a perceived future value for the coins produced.

 

Mining difficulty is adjusted by algorithm according to mining performance (not politics). It is not an "artificial scarcity" but an assurance of supply where everyone knows the rules. Be careful not to favor a currency that could be devalued to the benefit of people who do no real work to earn it (or that justify theft with a lie about some greater good to society). Miners will profit more from voluntary transaction costs as mining rewards decrease over time. There is no maximum transaction volume with bitcoin. The protocol had been changed several months ago to limit "dust" trades that were causing excessive blockchain growth. People were abusing that they could send 0.00000004 of a USD penny to someone so the minimum amount for a transaction had to be raised until that much bitcoin really has value. That was not political; it was to limit malicious blockchain growth.

 

Bitcoin is not subject to force and coercion. Bitcoin is an option not to suffer the abuses of state. For now though, you can think of it as an incredible opportunity in an emerging industry that is just starting to change the world in a way that respects your rights and property.

 

I agree it is like "the wild west" and the gold rush has begun. Already more people are making money selling mining equipment than they make from mining. The bitcoin money is in services around bitcoin.

 

Paul Baumann

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Reinout Heeck
Sent: Monday, November 11, 2013 09:02
To: [hidden email]
Subject: Re: [vwnc] 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


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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Thomas Hartman
In reply to this post by Reinout Heeck-2
On Tue, Nov 12, 2013 at 3:22 AM, Reinout Heeck <[hidden email]> wrote:

I would like to hear your opinions on Smalltalk library creation for Bitcoin.

Still a newb, but I'll do my best. Warning/apology: maybe half baked.
 
Which audience do you envisage shoud be catered to, what would you like to see?

1) Wall street. Smalltalk already has a niche on wall street. I think bitcoin (maybe other cryptos too) is going to hit wall street in 2014, and it is going to hit hard. So, libraries that integrate nicely with existing trading apis, but add functionality unique to bitcoin. Off the top of my head: confirmation times (how many blocks to be safe?), and counterparty risk when arbitraging between the various bitcoin exchanges comes to mind. 

2) Casinos and gambling. This is a big part of the bitcoin economy currently, and stands to continue during the volatile regime when "it is isn't quite money."

3) Universal world currency -- worldwide money transfers, remittances. Multicultural / multilingual / multi character set seems to be often a pain point. Smalltalk seems to have a natural ability to get intuitive and well factored translation layers in place.

4) Everything else. Sometimes I refer to this as the "alpaca socks sector." Using bitcon for "actual commerce." I think this one goes without saying, but it's actually the least strategic sector for smalltalk libraries in terms of shining bright.
 
Compatibility with which wallets?

1) satoshi wallet: Code is a mess, but it's the standard, so at least give this a nod.
2) better factored systems are libbitcoin and bitsofproof. I think libbitcoin has more momentum now, but I'd look at both. 

A good api would try to provide a compatibility layer that is somewhat agnostic between wallets, and make it easy to add more.
 
Re-create a full node implementaion, an SPV node or merely communicate with the reference implementation?

You need full node only if you're going to be doing analysis on the blockchain. This is an important feature, but it's a niche. So I'd say support both, but for the majority of applications target SPV first.

For full blockchain analysis, something that works naively with gemstone/GLASS might be valuable in terms of attracting "newbs" to the smalltalk/bitcoin ecosystem. Speaking personally, I was amazed how fast it was to prototype with vw. (I haven't actually tried gemstone yet, just heard anecdotes.)
 
Support generic virtual currency research?

I think bitcoin has a strong lead for now, so prioritize btc, but a lot of the btc infrastructure will port naturally to other currencies and systems once they start to matter. I agree with Paul Baumann that mastercoin is worth keeping an eye on, but maybe it's premature to prioritize, especially since we don't even have many public bitcoin libs at this time.
 
Concentrate on integration vendor APIs?

This is for the alpaca socks sector, so yes, but I would say trading apis first.
 
etc. etc.


Thanks!


R


I agree 100% with your first three points. Security is a huge problem. Solutions are emerging, but the current situation is bad for the layman. Too easy to get hacked if you do it yourself, too easy to get ripped off if you trust an exchange. But I think this will get better with time.

I also agree with point four, but it's unimportant. So what if there are religious messages in the blockchain? And killing off alt coins... well, whether this is malicious or not depends on if you are long bitcoin or altcoins. There are those who believe that like with Highlander... There Can Be only One ;) I guess time will tell, but in any case it's more of a feature than a bug from the point of view of bitcoin.

Point 5, I disagree. I think bitcoin is doing a very credible job of achieving escape velocity. Ripple is interesting, but it's not a competitor, more of a complement to bitcoin. And, ripple doesn't seem to have much momentum. Ripple and mastercoin compete in the same space to some extent, and I think mastercoin (piggy backing on bitcoin) might actually have a shot at unseating ripple.

Point 6, I mostly disagree. Even with the scarcities baked in, bitcoin could do exceedingly well as a micro transaction backing currency. Especially have a look at


IIUC, the key insight is that microtransactions can be batched and settled, and the settlements can be much smaller in size when they are finally broadcast to the block chain. Alternatively, bitcoin could be used as a clearing currency and there could be various "sub chains" with lower but still sufficient security, to handle the higher volume data.



On Mon, Nov 11, 2013 at 6:02 AM, Reinout Heeck <[hidden email]> wrote:
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




_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Reinout Heeck-2


I would like to hear your opinions on Smalltalk library creation for Bitcoin.

Still a newb, but I'll do my best. Warning/apology: maybe half baked.

Excellent, I find that naiveté is great tool to reach abstraction (people often roll their eyes when I suggest this).

 
Which audience do you envisage shoud be catered to, what would you like to see?

1) Wall street. Smalltalk already has a niche on wall street. I think bitcoin (maybe other cryptos too) is going to hit wall street in 2014, and it is going to hit hard. So, libraries that integrate nicely with existing trading apis, but add functionality unique to bitcoin. Off the top of my head: confirmation times (how many blocks to be safe?), and counterparty risk when arbitraging between the various bitcoin exchanges comes to mind.
In general I would expect Wall Street to already have handling in place in its usual way: by shoving IOUs around. If that works for gold it'll work for Bitcoin ;-)
Also in my experience integration into banking software will take the form of one-off jobs, not integration through existing standards.
Looking at the functionality you mention it seems that providing a wallet API ought to be enough for this niche.


2) Casinos and gambling. This is a big part of the bitcoin economy currently, and stands to continue during the volatile regime when "it is isn't quite money."
So should our library have a SatoshiDice clone as example?
It seems to require address monitoring notification API.
In the case of a SatishiDice clone notification will trigger: running the wager, paying it out and generating a report for the website to make the bet outcome provable.


3) Universal world currency -- worldwide money transfers, remittances. Multicultural / multilingual / multi character set seems to be often a pain point. Smalltalk seems to have a natural ability to get intuitive and well factored translation layers in place.
Ok, does that imply such a library provides a set of GUI elements? Would make perfect sense to me :-)
Requires work for each St platform though.




4) Everything else. Sometimes I refer to this as the "alpaca socks sector." Using bitcon for "actual commerce." I think this one goes without saying, but it's actually the least strategic sector for smalltalk libraries in terms of shining bright.
I call it 'long tail' and disagree with you re shining bright ;-)

Actual commerce could need:
a physical items shop integration
a virtual items shop integration
consulting tools integration. e.g. pay-per minute integration with Skype and such tools?
simple chores integration à la Amazon Mechanical Turk pay-per-(electronic)piece integration
 
Compatibility with which wallets?

1) satoshi wallet: Code is a mess, but it's the standard, so at least give this a nod.
Paul Bauman suggested Bitcoin-QT RPC API support as the minimum/first thing.

2) better factored systems are libbitcoin and bitsofproof. I think libbitcoin has more momentum now, but I'd look at both. 

A good api would try to provide a compatibility layer that is somewhat agnostic between wallets, and make it easy to add more.
yes, but this is harder than it sounds. For example some wallets have coin-control some don't.
This might be further compounded by security implications, papering over details could open unsuspected security holes.
I'll have to look in the two systems you mention, I never looked at the code so far....


 
Re-create a full node implementaion, an SPV node or merely communicate with the reference implementation?

You need full node only if you're going to be doing analysis on the blockchain. This is an important feature, but it's a niche. So I'd say support both, but for the majority of applications target SPV first.
an SPV node reimplementation



For full blockchain analysis, something that works naively with gemstone/GLASS might be valuable in terms of attracting "newbs" to the smalltalk/bitcoin ecosystem. Speaking personally, I was amazed how fast it was to prototype with vw. (I haven't actually tried gemstone yet, just heard anecdotes.)
 
Support generic virtual currency research?

I think bitcoin has a strong lead for now, so prioritize btc, but a lot of the btc infrastructure will port naturally to other currencies and systems once they start to matter. I agree with Paul Baumann that mastercoin is worth keeping an eye on, but maybe it's premature to prioritize, especially since we don't even have many public bitcoin libs at this time.
 
Concentrate on integration vendor APIs?

This is for the alpaca socks sector, so yes, but I would say trading apis first.
interesting, I hold the opposite opinion: the long tail is larger than all forex traders together.


Anyone else?
I'd be particularly interested to hear from Bitcoin agnostics, what would you want to have available when one of your customers asks for Bitcoin/Namecoin/Mastercoin/Ripple/Bitshares integration?
What functionality do you expect they will ask for?

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Thomas Hartman
> the long tail is larger than all forex traders together.

Eventually yes, but that gold is buried deep. Gambling and finance is closer to the surface.



On Wed, Nov 13, 2013 at 4:33 AM, Reinout Heeck <[hidden email]> wrote:


I would like to hear your opinions on Smalltalk library creation for Bitcoin.

Still a newb, but I'll do my best. Warning/apology: maybe half baked.

Excellent, I find that naiveté is great tool to reach abstraction (people often roll their eyes when I suggest this).


 
Which audience do you envisage shoud be catered to, what would you like to see?

1) Wall street. Smalltalk already has a niche on wall street. I think bitcoin (maybe other cryptos too) is going to hit wall street in 2014, and it is going to hit hard. So, libraries that integrate nicely with existing trading apis, but add functionality unique to bitcoin. Off the top of my head: confirmation times (how many blocks to be safe?), and counterparty risk when arbitraging between the various bitcoin exchanges comes to mind.
In general I would expect Wall Street to already have handling in place in its usual way: by shoving IOUs around. If that works for gold it'll work for Bitcoin ;-)
Also in my experience integration into banking software will take the form of one-off jobs, not integration through existing standards.
Looking at the functionality you mention it seems that providing a wallet API ought to be enough for this niche.



2) Casinos and gambling. This is a big part of the bitcoin economy currently, and stands to continue during the volatile regime when "it is isn't quite money."
So should our library have a SatoshiDice clone as example?
It seems to require address monitoring notification API.
In the case of a SatishiDice clone notification will trigger: running the wager, paying it out and generating a report for the website to make the bet outcome provable.



3) Universal world currency -- worldwide money transfers, remittances. Multicultural / multilingual / multi character set seems to be often a pain point. Smalltalk seems to have a natural ability to get intuitive and well factored translation layers in place.
Ok, does that imply such a library provides a set of GUI elements? Would make perfect sense to me :-)
Requires work for each St platform though.





4) Everything else. Sometimes I refer to this as the "alpaca socks sector." Using bitcon for "actual commerce." I think this one goes without saying, but it's actually the least strategic sector for smalltalk libraries in terms of shining bright.
I call it 'long tail' and disagree with you re shining bright ;-)

Actual commerce could need:
a physical items shop integration
a virtual items shop integration
consulting tools integration. e.g. pay-per minute integration with Skype and such tools?
simple chores integration à la Amazon Mechanical Turk pay-per-(electronic)piece integration
 
Compatibility with which wallets?

1) satoshi wallet: Code is a mess, but it's the standard, so at least give this a nod.
Paul Bauman suggested Bitcoin-QT RPC API support as the minimum/first thing.


2) better factored systems are libbitcoin and bitsofproof. I think libbitcoin has more momentum now, but I'd look at both. 

A good api would try to provide a compatibility layer that is somewhat agnostic between wallets, and make it easy to add more.
yes, but this is harder than it sounds. For example some wallets have coin-control some don't.
This might be further compounded by security implications, papering over details could open unsuspected security holes.
I'll have to look in the two systems you mention, I never looked at the code so far....



 
Re-create a full node implementaion, an SPV node or merely communicate with the reference implementation?

You need full node only if you're going to be doing analysis on the blockchain. This is an important feature, but it's a niche. So I'd say support both, but for the majority of applications target SPV first.
an SPV node reimplementation




For full blockchain analysis, something that works naively with gemstone/GLASS might be valuable in terms of attracting "newbs" to the smalltalk/bitcoin ecosystem. Speaking personally, I was amazed how fast it was to prototype with vw. (I haven't actually tried gemstone yet, just heard anecdotes.)
 
Support generic virtual currency research?

I think bitcoin has a strong lead for now, so prioritize btc, but a lot of the btc infrastructure will port naturally to other currencies and systems once they start to matter. I agree with Paul Baumann that mastercoin is worth keeping an eye on, but maybe it's premature to prioritize, especially since we don't even have many public bitcoin libs at this time.
 
Concentrate on integration vendor APIs?

This is for the alpaca socks sector, so yes, but I would say trading apis first.
interesting, I hold the opposite opinion: the long tail is larger than all forex traders together.


Anyone else?
I'd be particularly interested to hear from Bitcoin agnostics, what would you want to have available when one of your customers asks for Bitcoin/Namecoin/Mastercoin/Ripple/Bitshares integration?
What functionality do you expect they will ask for?

R
-

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

PhilipGlover
In reply to this post by Paul Baumann
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?
 
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Paul Baumann
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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Thomas Hartman
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

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

PhilipGlover

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Paul Baumann

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.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

PhilipGlover
Paul,

Thanks for trying to interpret my string of ideas, I think you're understanding me for the most part, but I think I may have even contradicted myself a bit along the way leading to some confusion. After trying to refine the though process a little further let me give it another go. My thought process is easiest to describe in an environment where all of the "coins" already exist, so I'm going to start from there, I'm sure a mining process could be developed to try and better encourage decentralized adoption.

Let there be a pool of all of the smallcoins - this Smallcoin pool is an initial, divisible object of a fixed quantity of coins. A smallcoin object can only be manipulated by the Wallet object that "owns" it, because it is the only object able to send it a change of ownership (or fractional change of ownership) message. In order for the wallet to transfer any quantity of smallcoin ownership to another wallet, that receiving wallet must have the same verified message set (essentially a clone). Since the wallets are only able to communicate with genuine wallets, the messages can be sent ad-hoc from wallet to wallet, and the smallcoin objects just change themselves to change ownership. Perhaps this is maintained on a blockchain, but I don't see why the integrity can't be verified by the very nature of the smallcoin objects and wallet objects that are interacting.

What I meant by the gold analogy was give the smallcoin object an understanding of its own quantity. When it is transferred, it must transfer itself in a manner that maintains a conservation of quantity. Like when gold is manipulated in the physical world, mass is not generated or destroyed, simply transformed or separated.

These are just ideas for now, but I really think there's something to defining the owner and unit-of-account objects in a way where they no longer await confirmations of transactions, but rather, they only know how to accept and perform true transactions where quantities are properly conserved.

Happy Friday,
phil


On Fri, Mar 21, 2014 at 2:27 PM, Paul Baumann <[hidden email]> wrote:

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.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Paul Baumann

>> Perhaps this is maintained on a blockchain, but I don't see why the integrity can't be verified by the very nature of the smallcoin objects and wallet objects that are interacting.

 

What is to prevent someone from double-spending by copying their entire wallet of smallcoins and then transfering them to two different wallets?

 

>> Since the wallets are only able to communicate with genuine wallets

 

How would you know if a wallet is "genuine" or a copy of a genuine wallet?

 

You'd have to explain how you can avoid having an auditable ledger.

Paul Baumann

 

 

 

From: Philip Glover [mailto:[hidden email]]
Sent: Friday, March 21, 2014 18:31
To: Paul Baumann
Cc: Thomas Hartman; [hidden email]
Subject: Re: [vwnc] Bitcoin with Smalltalk
Importance: Low

 

Paul,

 

Thanks for trying to interpret my string of ideas, I think you're understanding me for the most part, but I think I may have even contradicted myself a bit along the way leading to some confusion. After trying to refine the though process a little further let me give it another go. My thought process is easiest to describe in an environment where all of the "coins" already exist, so I'm going to start from there, I'm sure a mining process could be developed to try and better encourage decentralized adoption.

 

Let there be a pool of all of the smallcoins - this Smallcoin pool is an initial, divisible object of a fixed quantity of coins. A smallcoin object can only be manipulated by the Wallet object that "owns" it, because it is the only object able to send it a change of ownership (or fractional change of ownership) message. In order for the wallet to transfer any quantity of smallcoin ownership to another wallet, that receiving wallet must have the same verified message set (essentially a clone). Since the wallets are only able to communicate with genuine wallets, the messages can be sent ad-hoc from wallet to wallet, and the smallcoin objects just change themselves to change ownership. Perhaps this is maintained on a blockchain, but I don't see why the integrity can't be verified by the very nature of the smallcoin objects and wallet objects that are interacting.

 

What I meant by the gold analogy was give the smallcoin object an understanding of its own quantity. When it is transferred, it must transfer itself in a manner that maintains a conservation of quantity. Like when gold is manipulated in the physical world, mass is not generated or destroyed, simply transformed or separated.

 

These are just ideas for now, but I really think there's something to defining the owner and unit-of-account objects in a way where they no longer await confirmations of transactions, but rather, they only know how to accept and perform true transactions where quantities are properly conserved.

 

Happy Friday,

phil

 

On Fri, Mar 21, 2014 at 2:27 PM, Paul Baumann <[hidden email]> wrote:

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.

 



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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

PhilipGlover

I began to think this through afterward and I think I better understand the necessity now. I was trying to think of mechanisms for preventing the wallet fraud, but I couldn't see anything simpler than maintaining a blockchain. I was just trying to be a little too cute, there's no reason to not have one.

I still believe there is a space to try and create physically unique hardware to maintain the wallets objects. I see it placing another layer of security between the user and their own private keys. Perhaps this is similar to the work the Mycelium wallet team is working on, but I think it would increase the security for both the consumers and vendors who want better protection against double spending where you may want to perform offline transactions.

Maybe that's an OO opportunity, to tie real objects to virtual wallet objects. I'll think more in that. Thanks for holding my hand through that thought process.

phil

On Mar 24, 2014 7:54 AM, "Paul Baumann" <[hidden email]> wrote:

>> Perhaps this is maintained on a blockchain, but I don't see why the integrity can't be verified by the very nature of the smallcoin objects and wallet objects that are interacting.

 

What is to prevent someone from double-spending by copying their entire wallet of smallcoins and then transfering them to two different wallets?

 

>> Since the wallets are only able to communicate with genuine wallets

 

How would you know if a wallet is "genuine" or a copy of a genuine wallet?

 

You'd have to explain how you can avoid having an auditable ledger.

Paul Baumann

 

 

 

From: Philip Glover [mailto:[hidden email]]
Sent: Friday, March 21, 2014 18:31
To: Paul Baumann
Cc: Thomas Hartman; [hidden email]
Subject: Re: [vwnc] Bitcoin with Smalltalk
Importance: Low

 

Paul,

 

Thanks for trying to interpret my string of ideas, I think you're understanding me for the most part, but I think I may have even contradicted myself a bit along the way leading to some confusion. After trying to refine the though process a little further let me give it another go. My thought process is easiest to describe in an environment where all of the "coins" already exist, so I'm going to start from there, I'm sure a mining process could be developed to try and better encourage decentralized adoption.

 

Let there be a pool of all of the smallcoins - this Smallcoin pool is an initial, divisible object of a fixed quantity of coins. A smallcoin object can only be manipulated by the Wallet object that "owns" it, because it is the only object able to send it a change of ownership (or fractional change of ownership) message. In order for the wallet to transfer any quantity of smallcoin ownership to another wallet, that receiving wallet must have the same verified message set (essentially a clone). Since the wallets are only able to communicate with genuine wallets, the messages can be sent ad-hoc from wallet to wallet, and the smallcoin objects just change themselves to change ownership. Perhaps this is maintained on a blockchain, but I don't see why the integrity can't be verified by the very nature of the smallcoin objects and wallet objects that are interacting.

 

What I meant by the gold analogy was give the smallcoin object an understanding of its own quantity. When it is transferred, it must transfer itself in a manner that maintains a conservation of quantity. Like when gold is manipulated in the physical world, mass is not generated or destroyed, simply transformed or separated.

 

These are just ideas for now, but I really think there's something to defining the owner and unit-of-account objects in a way where they no longer await confirmations of transactions, but rather, they only know how to accept and perform true transactions where quantities are properly conserved.

 

Happy Friday,

phil

 

On Fri, Mar 21, 2014 at 2:27 PM, Paul Baumann <[hidden email]> wrote:

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.

 



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
Reply | Threaded
Open this post in threaded view
|

Re: Bitcoin with Smalltalk

Thomas Hartman
Authentication:

  Something you have.
  Something you know.
  Something you are.

http://www.cs.cornell.edu/courses/cs513/2005fa/nnlauthpeople.html

Mix and match. Which do you want?


On Mon, Mar 24, 2014 at 8:42 AM, Philip Glover <[hidden email]> wrote:

> I began to think this through afterward and I think I better understand the
> necessity now. I was trying to think of mechanisms for preventing the wallet
> fraud, but I couldn't see anything simpler than maintaining a blockchain. I
> was just trying to be a little too cute, there's no reason to not have one.
>
> I still believe there is a space to try and create physically unique
> hardware to maintain the wallets objects. I see it placing another layer of
> security between the user and their own private keys. Perhaps this is
> similar to the work the Mycelium wallet team is working on, but I think it
> would increase the security for both the consumers and vendors who want
> better protection against double spending where you may want to perform
> offline transactions.
>
> Maybe that's an OO opportunity, to tie real objects to virtual wallet
> objects. I'll think more in that. Thanks for holding my hand through that
> thought process.
>
> phil
>
> On Mar 24, 2014 7:54 AM, "Paul Baumann" <[hidden email]> wrote:
>>
>> >> Perhaps this is maintained on a blockchain, but I don't see why the
>> >> integrity can't be verified by the very nature of the smallcoin objects and
>> >> wallet objects that are interacting.
>>
>>
>>
>> What is to prevent someone from double-spending by copying their entire
>> wallet of smallcoins and then transfering them to two different wallets?
>>
>>
>>
>> >> Since the wallets are only able to communicate with genuine wallets
>>
>>
>>
>> How would you know if a wallet is "genuine" or a copy of a genuine wallet?
>>
>>
>>
>> You'd have to explain how you can avoid having an auditable ledger.
>>
>> Paul Baumann
>>
>>
>>
>>
>>
>>
>>
>> From: Philip Glover [mailto:[hidden email]]
>> Sent: Friday, March 21, 2014 18:31
>> To: Paul Baumann
>> Cc: Thomas Hartman; [hidden email]
>> Subject: Re: [vwnc] Bitcoin with Smalltalk
>> Importance: Low
>>
>>
>>
>> Paul,
>>
>>
>>
>> Thanks for trying to interpret my string of ideas, I think you're
>> understanding me for the most part, but I think I may have even contradicted
>> myself a bit along the way leading to some confusion. After trying to refine
>> the though process a little further let me give it another go. My thought
>> process is easiest to describe in an environment where all of the "coins"
>> already exist, so I'm going to start from there, I'm sure a mining process
>> could be developed to try and better encourage decentralized adoption.
>>
>>
>>
>> Let there be a pool of all of the smallcoins - this Smallcoin pool is an
>> initial, divisible object of a fixed quantity of coins. A smallcoin object
>> can only be manipulated by the Wallet object that "owns" it, because it is
>> the only object able to send it a change of ownership (or fractional change
>> of ownership) message. In order for the wallet to transfer any quantity of
>> smallcoin ownership to another wallet, that receiving wallet must have the
>> same verified message set (essentially a clone). Since the wallets are only
>> able to communicate with genuine wallets, the messages can be sent ad-hoc
>> from wallet to wallet, and the smallcoin objects just change themselves to
>> change ownership. Perhaps this is maintained on a blockchain, but I don't
>> see why the integrity can't be verified by the very nature of the smallcoin
>> objects and wallet objects that are interacting.
>>
>>
>>
>> What I meant by the gold analogy was give the smallcoin object an
>> understanding of its own quantity. When it is transferred, it must transfer
>> itself in a manner that maintains a conservation of quantity. Like when gold
>> is manipulated in the physical world, mass is not generated or destroyed,
>> simply transformed or separated.
>>
>>
>>
>> These are just ideas for now, but I really think there's something to
>> defining the owner and unit-of-account objects in a way where they no longer
>> await confirmations of transactions, but rather, they only know how to
>> accept and perform true transactions where quantities are properly
>> conserved.
>>
>>
>>
>> Happy Friday,
>>
>> phil
>>
>>
>>
>> On Fri, Mar 21, 2014 at 2:27 PM, Paul Baumann <[hidden email]>
>> wrote:
>>
>> 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.
>>
>>
>>
>>
>> ________________________________
>> 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