Here's the relevant part of my post above highlighted for clarity:

In Ethereum, you have entities called contracts, where contracts have their own balances, and are activated every time you send a transaction (think: money with an optional message attached) to them. The contract has 16 computational steps for free to give it wiggle room to determine whether a transaction is even worth processing; after this, every computational step that the contract takes costs it 1x BASEFEE (or more for specialized data access or crypto ops). If the contract goes bankrupt halfway through the computational process, it just stops halfway through.


Actually, you can send a 0 ether tx to a contract, although that tx will still cost the sender a TXFEE.


Precisely; although with the proviso that the first 16 computational steps in contract execution are free, so if a contract is decently written you can't involuntarily send transactions to it to bankrupt it.


Here's an example also (assume BASEFEE = 1 ether for convenience)

CONTRACT: [ PUSH 0 JMP ], balance: 1000

The contract is pretty much the simplest possible infinite loop script; it's the equivalent of "10: DO_NOTHING; 20: GOTO 10"

Now, suppose that someone sends it a transaction with value 10 ether (this tx will cost the sender 110 ether due to the TXFEE):

TX: [ ADDRESS, 10, [], v, r, s]

Step 1: { Counter: 0, Index pointer: 0, Stack: [], balance: 1010 }
Step 2: { Counter: 1, Index pointer: 2, Stack: [ 0 ], balance: 1010 }
Step 3: { Counter: 2, Index pointer: 0, Stack: [], balance: 1010 }
...
Step 16: { Counter: 15, Index pointer: 2, Stack: [ 0 ], balance: 1010 }
Step 17: { Counter: 16, Index pointer: 0, Stack: [], balance: 1009 }
Step 18: { Counter: 16, Index pointer: 2, Stack: [ 0 ], balance: 1008 }
...
Step 1025:  { Counter: 16, Index pointer: 0, Stack: [], balance: 1 }
Step 1026:  { Counter: 16, Index pointer: 2, Stack: [ 0 ], balance: 0 }
Step 1027: ERROR NOT ENOUGH FUNDS HALT

The contract now has a balance of 0 ether, so if someone tries to send that transaction again, the second time around execution will stop at step 17 rather than 1027.

You're (very understandably ) coming at this from too much of a Bitcoin perspective, where scripts are attached to transactions and transaction outputs and transactions can either pass or fail. That's not how Ethereum works. In Ethereum, you have entities called contracts, where contracts have their own balances, and are activated every time you send a transaction (think: money with an optional message attached) to them. The contract has 16 computational steps for free to give it wiggle room to determine whether a transaction is even worth processing; after this, every computational step that the contract takes costs it 1x BASEFEE (or more for specialized data access or crypto ops). If the contract goes bankrupt halfway through the computational process, it just stops halfway through. Here is the critical part: unlike is the case with Bitcoin, here the transaction does not "fail". The transaction still succeeds; the contract just ends up sitting there out of gas halfway through some long calculation instead of doing anything interesting. If you send a second transaction to the same contract immediately after, it will halt right after the 16 step grace period (or maybe more if the second transaction is sending some non-negligible amount of ether to refill it).




Okay, time for me to put my armchair econo-socio-politico-philosopher hat on.

We're not trying to be a corporate controller. You may notice that unlike Freicoin, Devcoin and the like, the Ethereum organization is NOT collecting any kind of tax or issuance share forever; there is only a small one-time fundraise/premine at the start. This essentially sets in stone what I have come to realize is an important principle in business and social organization: small organizations, like startups, usually have to be dictatorial and have one or a few dominant players pushing a coherent vision with appropriate incentivization to help the process along. In the long term, however, structures that aim to be basic institutions of society (currency being one of the most important) should be controlled by no one. I feel like this compromise approach well represents the feelings of the Bitcoin community. The problem we have today is that organizations either try to either start decentralized, and often unfortunately fail, or start centralized, and then get drunk with power (or get co-opted by entities that are already drunk with power) and never bother actually implementing the decentralization step.

We do spend a lot of time thinking about exactly how these new decentralized structures can help either augment or replace existing systems, and how they fit into the categories of standard economics. At this point, we are still very much in the speculative fiction stage, but perhaps you might find these interesting:

http://bitcoinmagazine.com/9435/markets-institutions-currencies-new-method-social-incentivization/
http://blog.ethereum.org/2013/12/31/bootstrapping-a-decentralized-autonomous-corporation-part-i/
http://blog.ethereum.org/2013/12/31/bootstrapping-an-autonomous-decentralized-corporation-part-2-interacting-with-the-world/
http://blog.ethereum.org/2013/12/31/bootstrapping-a-decentralized-autonomous-corporation-part-3-identity-corp/
http://bitcoinmagazine.com/6528/what-proof-of-stake-is-and-why-it-matters/
http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/

What I like about the Ethereum community so far is precisely the level of interest in economic issues and willingness to look for solutions with a fresh eye that I'm seeing. We are all committed Bitcoiners, and believe in the principle of decentralization; however, at the same time we understand well why centralized systems have come to exist and the positive role they have often served in pushing humanity forward even while committing those evils of which we are all very aware. Thus, the emphasis is precisely on figuring out what the benefits are that centralization brings, and seeing if we can come up with incentive structures that provide most of the benefits without most of the drawbacks. A good analogy here is data structures in computer science. We have arrays, where a 1000-item array takes 1 step to modify or access a value but 500 steps to insert or delete, and we have linked lists, where a 1000-item list takes 500 steps to access a value but only 1 step to insert or delete. However, more recently we invented the concept of trees, where you can have a 1000-item tree where inserting, modifying, accessing and deleting all take no more than 10 steps -  a compromise that gives us nearly the best of both worlds. Those are the kinds of cleverly rigged and elegant solutions to problems that we are trying to seek.

You're asking for a dev resume? Here you go then:

http://github.com/vbuterin/pybitcointools
http://github.com/vbuterin/node-sx
http://github.com/vbuterin/bitcoinjs-lib
http://multisig.info
http://github.com/ethereum/pyethereum


http://ethereum.org/ethereum.html , the section on "applications"

As for PoW/PoS, we are agile, we can use hybrid PoS/PoW if we want.

Our prototype PoS algorithm, while not perfect, is one of the few that is immune to nothing-at-stake and computation/stake tradeoff attacks:

http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm

Also, Ethereum script may be "hardcore", but the CLL is not; it's basically stripped-down Python. We'll release a CLL -> Ethereum script compiler soon, watch out for that.

Conference, Alpha Testnet and Fundraiser Updates

January 29, 2014 - By Team

Ethereum received an incredible response at the Miami Bitcoin Conference. We traveled there anticipating many technical questions as well as a philosophical discussion about the purpose of Ethereum; however, the overwhelming amount of interest and enthusiasm for the project was much larger than we had anticipated. Vitalik’s presentation was met with both a standing ovation and a question queue that took hours to address.

Because we intend on providing an equal opportunity to all those who want to be involved, and are reviewing the relevant logistical and regulatory issues for a fundraiser of this scale, we have decided to postpone the Feb 1 launch of the fundraiser. We will make the announcement of the new fundraiser launch date on our official website: Ethereum.org.

The Ethereum project is also excited to announce the alpha release of the open source testnet client to the community at the beginning of February. This will give people an opportunity to get involved with the project and experiment with Ethereum scripts and contracts, and gain a better understanding of the technical properties of the Ethereum platform. Launching the testnet at this date will give those interested in the fundraiser a chance to better understand what the Ethereum project is about before participating.

The testnet will include full support for sending and receiving transactions, the initial version of the scripting language as described in our whitepaper, and may or may not include mining. This will also be the first major cryptocurrency project to have two official clients released at the same time, with one written in C++ and the other in Go; a Python client is also in the works. A compiler from the Ethereum CLL to Ethereum script will be released very soon.

A note on security

The fundraiser will NOT be launching on February 1st and any attempt to collect funds at this time should be considered a scam. There have been some scams in the forums thus please use caution and only consider information posted on Ethereum.org to be legitimate. It is important to reinforce to all that only information released and posted at Ethereum.org should be trusted as many are likely to impersonate us.

1. We will have transparent accounting
2. Ethereum is 100% open source. If the community gets angry at the way we handle the funds, they can release a fork and delete whatever portion of the issuance they don't like out of existence. We are thus very aware that we have to tread carefully here.

Also, over two years, we will be transitioning the Ethereum org itself into a DAO, so at some point its reserve holdings will also be maximally trust-free.

Fundraiser participants are not locked down. Only the premine is locked down.

> Could a script could still act as a thumbnail browser and download the images from a Tor server if a cryptocurrency payment was made to an address?  

Scripts can't download anything, so no.

> I don't know a lot about web browser security, but this does not make me feel safe.  Exploits are demonstrated often that can break out of the chrome browser sandbox to claim the bug bounty.  There is going to be one hell of a reward for finding an exploit and breaking out of the ethereum sandbox.

I'll avoid talking more about the legal questions at this point; I am not a lawyer, and we are talking with people who are who are in the process of crafting our legal positions.

Most critical vulnerabilities that we hear of don't actually break out of the sandbox; they are actually of the sort where Javascript code from one website manages to get executed inside of another webpage, and sends user data off to some third party server. There is no equivalent of that here. As for the vulnerabilities that do break into system memory somehow, I think our main defenses will be simplicity and abstraction. We have less than 60 instructions, and there are no operations that affect memory directly; everything is done by making database calls and modifying 256 bit integer objects. Our language has no power, even in theory, to handle input, output, HTTP requests or file system accesses; it's all purely internally focused. If we decide that it's necessary, we also have stronger options  like running the scripts with a zero-permission user or even inside a virtual machine.

> Hasn't the Electrum model worked for Bitcoin?

Yes, it has. But I describe in my whitepaper why it doesn't work for protocols on top of Bitcoin.

> Is there a big issue with just querying a bunch of supernodes to see if they all give the same result?

That is potentially very problematic because it breaks down the no-trust property; instead, you're getting data from a small pool of centralized entities. It's possible, and people do it with blockchain.info, but it somewhat weakens the whole attraction of a cryptocurrency.

> How many years from now should we predict that the blockchain size will become irrelevant? 

That's an interesting question that I don't know the answer to. Perhaps if that happens the blockchain size will simply keep on growing, as people keep putting more and more memory-intensive applications on top and reach an equilibrium. In the medium term, I personally am more worried about the possibility that Ethereum's disk and computational load will be too high; I think that is the more pressing question that we at the Ethereum team are more focused on.

> What will be the effects of ethereum blockchain size growth several orders of magnitude greater than Bitcoin?

I don't think the blockchain will be that large. There are ways to combine Ethereum with off-chain protocols to mitigate most of the issues if people do want to put terabytes of data into Ethereum-based systems.

> Is it reasonable to think the client can be sandboxed?

The security model for Ethereum is similar to that of web browsers with Javascript; we'll design our sandbox accordingly.

> What will be the effects of illegal contracts? An assassination market, for example?  Will the Silk Road be able to run on ethereum? 

Theoretically those use cases are possible, but it is important to point out that you can crowdfund assassinations and create a decentralized Silk Road marketplace with Bitcoin too, even directly on the blockchain using assurance contracts. So the regulatory challenges there are fairly similar to BTC, although we do realize that the legal status of second-generation cryptoledgers is less clear; that is why we are interested in working with CODA.

> Will a database of child porn be able to be stored?  If there is child porn stored on the blockchain that is easily accessible, will it be legal to store the blockchain in any country? 

Just like Bitcoin, the memory fees are prohibitively high to store a JPEG.

> What will be the effects of running all the clients over Tor by default?  Can a 60s block time with huge blocks work over Tor?

Maybe. Wait for the testnet and try it yourself.

> [ Satoshi's arguments ]

The nice thing about having a Turing-complete scripting language is that you can integrate many interesting models for how one currency can be integrated into another:

(1) The sub-currency can be fully stored as a contract (space heavy, time heavy)
(2) The Merkle root of the sub-currency state tree can be stored in a contract, and the leaves off-chain. Each update to the tree is validated by the contract (space light, time heavy)
(3) Two blockchains, but where the Ethereum chain includes an SPV client of the other chain (space light, time light)

If one way of doing things is too inefficient, we can always fall back on other ways.

Welcome to the New Beginning

When the grand experiment that is bitcoin began, the anonymous wizard desired to test two parameters- a trustless, decentralized database enjoying security enforced by the austere relentlessness of cryptography and a robust transaction system capable of sending value across the world without intermediaries. Yet the past five years years have painfully demonstrated a third missing feature: a sufficiently powerful Turing-complete scripting language. Up until this point, most innovation in advanced applications such as domain and identity registration, user-issued currencies, smart property, smart contracts, and decentralized exchange has been highly fragmented, and implementing any of these technologies has required creating an entire meta-protocol layer or even a specialized blockchain. Theoretically, however, each and every one of these innovations and more can potentially be made hundreds of times easier to implement, and easier to scale, if only there was a stronger foundational layer with a powerful scripting language for all of these protocols to build upon. And this need is what we seek to satisfy.

Ethereum is a modular, stateful, Turing-complete contract scripting system married to a blockchain and developed with a philosophy of simplicity, universal accessibility and generalization. Our goal is to provide a platform for decentralized applications - an android of the cryptocurrency world, where all efforts can share a common set of APIs, trustless interactions and no compromises. We ask for the community to join us as volunteers, developers, investors and evangelists seeking to enable a fundamentally different paradigm for the internet and the relationships it provides.

Who is Behind Ethereum?

Our primary core devs are:

• Vitalik Buterin → Inventor of Ethereum, protocol developer and researcher
• Gavin Wood →Lead C++ developer
• Jeffrey Wilcke → Lead Go developer

Primary non-development members include:

• Anthony Di Iorio → Founder and Executive Director of the Bitcoin Alliance of Canada, Bitcoin Decentral, KryptoKit
• Mihai Alisie → Founder of Bitcoin Magazine and Egora
• Joseph Lubin → Software engineer, Quantitative Analyst
• Stephan Tual → Founder of Ursium, Communications

A more extensive but non-exhaustive list of team members can be found here.

Our ether sale is available at http://ethereum.org ; the site contains all needed instructions.

The Next Step: Some Links

Welcome to the Ethereum Ecosystem:

• http://ethereum.org/
• http://ethereum.org/ethereum.html
• Enjoy the Code: https://github.com/ethereum
• Whitepaper: https://ethereum.org/pdfs/EthereumWhitePaper.pdf
• Yellowpaper: https://ethereum.org/pdfs/EthereumYellowPaper.pdf
• Blog: http://blog.ethereum.org
• Reddit: http://reddit.com/r/ethereum

Contact Us:

General Queries
info@ethereum.org

Our updates:

1. The problem that I have with scrypt or SeqMemoHash is that they are not memory-hard enough; they are just as memory-hard to verify as they are to compute, which puts a natural cap on how high the parameters can be tweaked. The reason why I came up with Dagger in the first place was to create a PoW that is memory-hard to compute but memory-easy to verify, since you only need a small amount of memory for one nonce, so that you can tweak up the memory requirement per thread to an extremely high value.
2. We did make a simplication and improvement to Dagger (basically, we linearized the tree, so a node always theoretically can depend on the node right before it); this should mitigate this attack somewhat, and parameter tweaks that sacrifice some of its memory-hardness to compute or memory-easiness to verify can be used to mitigate the attack further as much as necessary, in the limit turning Dagger into yet another Scrypt clone.
3. We are actively researching proof of stake, and I came up with Slasher as a proof of concept next-generation PoS algorithm; we may use PoS in combination with PoW.
4. (MOST IMPORTANT) We will actually be holding a proof-of-work contest, where research groups from universities will be invited to come up with ASIC-resistant proofs of work and panels of judges will determine winners. We will have funds to pay substantial prizes, so we hope to attract a large amount of interest. Proof-of-stake, proof-of-burn and proof-of-excellence based submissions will also be welcome in some category.

Very interesting work, thanks for the paper. Provably fair mixing will likely be the next major step.

As for fees, I would recommend that we just go ahead and standardize 2^k satoshis for all k as mixing sizes. This also might optionally be used to remove the need for fee randomness, since we can just ask a user to provide 51 return addresses (or, perhaps more appropriately, a bip32 pubkey) and return the precise amount sans fees in the standard-sized chunks.

Hey all, Vitalik Buterin, founder here.


Thanks a lot tacotime for making the thread and representing us. I actually did just formalize the PoS algorithm I had briefly sketched out this morning: http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm .If we get real overwhelming demand to use proof of stake, we will use something like this or something better, but that's not really likely IMO. An interesting idea there would be to also add some kind of proof-of-excellence based distribution model (eg. we'll put 10000 trillion ether into a contract which gives ether to people who solve very hard math and CS problems like integer factorization, AI board game algorithms, etc) so we still have some more issuance over time and aren't 100% premined.

Now, to get to the main point, the issuance model.

First, as mentioned by LeoC, proof of burn is a non-starter for our use case, because PoB cannot be independent. That is to say, with PoB an Ethereum client would need to also have a Bitcoin blockchain and would be dependent on the Bitcoin blockchain for validity checking. I absolutely do not want to have external dependencies in Ethereum - with the obvious exception of people creating SPV clients inside of contracts, which I think is a really cool idea with amazing potential for cross-chain atomic swaps, two-way pegs and the like.

Second, and more importantly, while I do understand the sentiment that cryptocurrency algorithms should be neutral and privilege no specific parties I would like to contest the claim that the concept of neutrality in the context of issuance is both (1) possible and (2) desirable. When you're putting BTC into the Ethereum fundraiser, you're financially empowering and incentivizing an organization that has produced substantial real results already, and is pledged to developing the Ethereum protocol. When you're putting BTC into a proof of burn, through the deflation effect you're effectively donating your money to large BTC early adopters.

When we talk about neutrality and fairness, what we really mean is that we want the currency supply to be distributed among as many large and diverse constituencies as possible. And this is actually the reason why I came up with Ethereum's compromise distribution model. With Bitcoin, the only way to get BTC was mining, and so BTC privileges the class of people with computing power. With Mastercoin, it was buying into the fundraiser, privileging the Bitcoin-wealthy. With Ripple, it's working for Ripple Labs or getting a bit at a giveaway, privileging the founders. With Ethereum, there are many ways to get ether: you can participate in the fundraiser, you can participate in the Ethereum project and receive salaries or bounties, you can mine, and we may potentially even end up doing a giveaway or two. This actually increases fairness compared to the pure mining model, since different groups of people are privileged in each of these categories (people with money, people with hardware, people with connections and development skills, etc) and all of these have a chance.

With regard to the "founders get some for free" factor, what people need to understand is that every currency, including BTC, QRK, MSC and Ripple, so far has privileged its founders in some fashion. The only difference is that in some cases the privilege is more subtle than in others. With Bitcoin, Satoshi got his 0.25X by mining it for a year when nobody else had heard about Bitcoin yet. With MSC, JR got his by running a fundraiser relatively quietly on Bitcointalk and then targeting media attention only after it was over. We are not seeking any avantage through obscurity; we will be targeting the limelight from before the first day that the fundraiser launches.

Ultimately, our ideology with regard to the distribution long-term is this. We believe that centralization and decentralization both have their value, and must be used at the appropriate times. Startups, in practice, generally have to be dictatorial. However, institutions that are at the base level of society should ideally not be controlled by anyone. To that end, the way that we are structuring both the organization and the issuance model is that we will have a large amount of influence at the beginning, but that influence will quickly decay over time as the years progress. Once we release the coin, we will inevitably immediately lose control, and over the next one or two years we even hope to turn the Ethereum organization itself into a DAO, sustaining itself through VC-like investments with ownership spread among thousands of people in the community. It's the same with the profit structure; yes, if Ethereum succeeds, we will profit handsomely, and fundraiser participants will profit handsomely. However, because we have permanent linear inflation, this profit is a one-time fact whose importance in the system will diminish to zero over a sufficiently long period of time. As T approaches infinity, ether becomes zero percent premined. Satoshi, on the other hand, has up to 5% of all BTC forever.

All in all, we believe that we have come up with a very interesting issuance model that combines together the benefits of all of the various models in small doses; we have Ripple-style premining, Mastercoin-style fundraising, but ultimately Bitcoin-style mining dominates over the long term, eventually coming to eclipse every other component of the issuance. It is ultimately up to the community to decide whether or not this issuance model is valuable.

Now, to clarify some facts:

* The founders will not be getting any BTC from the pool. We may get some not particularly high wages to live on, but our financial interest in the project is heavily concentrated in the value of our premine share.
* The founders are not getting 25%. The founders are getting 12.5% after one year when those funds actually become accessible, and the percentage will rapidly dwindle due to supply expansion, becoming 6.25% after 5 years. I'm sure that there exist five people today who together own 6.25% of all bitcoins, and Satoshi alone likely has that much. In Mastercoin, three people have 25%.
* The BTC from the pool will be going entirely to the organization, and we will start using it to pay expenses even as the fundraiser is running in order to get development moving quickly. We have plans on how we can spend money all the way up to $25 million; the higher-end expenses consist of things like Bitcoin Decentral-style incubators, a large amount of funds into cryptocurrency scalability research, funding very high-quality interfaces, decentralized exchanges, and other such infrastructure, and even funnelling money into projects that might work alongside Ethereum (eg. Bitmessage, KryptoKit, OpenTransactions)
* We are not trying to be a highly powerful HFT exchange. We are trying to be a generalized workhorse that can do anything. Identity systems, decentralized Dropbox, sub-currencies, you name it. HFT can be done through either a dedicated chain (eg. BitShares can release an Ethereum contract containing an SPV version of the BitShares blockchain and use that to allow units to move back and forth between the two blockchains, and then do HFT on their own chain) or using a semi-centralized system like OpenTransactions
* We are going to release clients in 3-4 langugaes, likely Python, Go, C++ and NodeJS. The main reason for this is to avoid monoculture from day one and to ensure consistency since it's very unlikely that the same bug will appear in all four.
* We will not put Zerocoin into Ethereum. But what you can do is set up a Zerocoin-based mixer as an Ethereum contract.
* We have not figured out how to do 100% trust-free fiat. The closest we've gotten is doing contracts for difference off of voting pools of price feeds. But even that is a massive improvement over having to trust an issuer.
* We will likely use 3-of-5 multisig to hold our funds. We will be the first cryptocurrency fundraiser that we know of whose exodus address actually has a 3 at the beginning.

We will release the source code and settle on a license soon. And sorry to disappoint, but we do use blockchain.info. No way around it at this point (well, we could switch to the Obelisk pass-through I have set up, which would technically be a 1st party service and not 3rd party, but given the nature of internet protocols we can't just hook up to the network directly).

Yes, chrome only now. This is still a very new project, and we with be rolling out a Firefox version in a few weeks then Safari and others some time after.

TORONTO, ON--(Marketwired - Jan 5, 2014) - KryptoKit (http://www.kryptokit.com/), the easiest and fastest way to handle Bitcoin transactions, today announced that three of the biggest names in the Bitcoin space have joined the startup in ownership roles. They are Roger Ver, Erik Voorhees and Vitalik Buterin.

Known in Bitcoin circles as "Bitcoin Jesus" for his active efforts in evangelizing and promoting the digital currency (including placing ads for Bitcoin on highway billboards and handing out bitcoins for free), Ver is CEO of MemoryDealers.com and a serial seed investor, having helped such startups as the Bitcoin Store, BitInstant and Blockchain.info.
Voorhees is co-founder of Coinapult, a company which currently specializes in allowing users to send bitcoins via SMS and email, but will soon considerably expand its range of offerings. He has worked as marketing director at BitInstant and is a co-founder of FeedZeBirds, a Bitcoin-based Twitter advertising platform, and Paysius, a Bitcoin payment module.

"We at KryptoKit are thrilled to welcome these important figures from the Bitcoin world onboard to form our amazing team," said Anthony Di Iorio, the company's co-founder along with Steve Dakh. "Roger and Erik are probably two of the top Bitcoin spokespeople in the world and will be working with us on business strategy and other areas."

Buterin is the cofounder and head writer at Bitcoin Magazine, and is also involved in a number of Bitcoin software projects including pybitcointools, multisig.info, the Bitcoin private key secret sharing utility btckeysplit and a fork of BitcoinJS. He is also a heavy supporter of "cryptocurrency 2.0" applications such as user-issued currencies, on-blockchain identity systems and decentralized exchange, and is now actively working on developing an upcoming next-generation cryptographic consensus network known as Ethereum.

"Vitalik rounds out what is becoming a very diverse and capable team," said Dakh. "As one of the top developers in Bitcoin, he will be a huge asset as we continue to develop and perfect our backend and programming."

KryptoKit recently unveiled its plug-in at the Inside Bitcoins West conference, Dec. 10 to 11, in Las Vegas, Nevada. It currently has a five-star rating in the Chrome Web Store.
For more information, please visit http://www.kryptokit.com/.

About KryptoKit

KryptoKit is a Toronto-based company specializing in encryption and digital currencies. One of the company's founders, Anthony Di Iorio, is also the founder of Toronto Bitcoin Meetup (http://www.meetup.com/Bitcoin-Toronto/) and Bitcoin Decentral (http://www.bitcoindecentral.ca) and is the Executive Director of the Bitcoin Alliance of Canada (http://www.bitcoinalliance.ca/), a non-profit dedicated to raising the awareness of bitcoins among Canadian consumers, merchants and policy makers to promote the adoption of Bitcoin and other virtual currencies.

The Bitcoin Alliance of Canada has no formal association with the Bitcoin Foundation.

FOR IMMEDIATE RELEASE

PRLog (Press Release) - Dec. 19, 2013 - The Bitcoin Alliance of Canada (BAC) has become aware that an applicant has applied to the Canadian Intellectual Property Office (CIPO) for the “BITCOIN” word mark in Canada. This application has not been granted by CIPO.

We oppose this application. Bitcoin is, on its own, purely descriptive and not distinctive, and this application covers wares and services that go to the heart of the bitcoin protocol. We don’t object to trade-marks that help consumers differentiate among competing products and that protect producers’ valuable investments in reputation. However, the word “bitcoin,” all by itself, is a word that should be left in the public domain and free to the public to use. We believe that registration of this trade-mark in Canada would potentially inhibit the ability of Canadians to use this innovative new technology, stifle innovation, and impose unnecessary costs on Canadian merchants and consumers.

No other governmental authority of which we are aware has granted a trade-mark in respect of this single word with the breadth of wares and services included in this application.

Therefore, the BAC has drafted an open letter to CIPO regarding this application. The application can be found here. We trust that CIPO will do its usual great work and seriously consider the legal standard for registration under the Trade-Marks Act. Intellectual property law should protect and foster true innovation—not become a redoubt for trolls and those trying to subvert the inventions of others.

About the Bitcoin Alliance of Canada

The BAC is dedicated: to raising awareness of bitcoin among Canadian consumers, merchants, businesses, regulators, and policy makers; to promoting bitcoin adoption in Canada; to further Canadian and international study and research in bitcoin and other virtual currencies; and, to promoting Canadian participation in international partnerships, associations, and other efforts to promote, study, research, and discuss bitcoin and other virtual currencies.

About Bitcoin

Bitcoin is a digital currency and protocol that enables instant peer-to-peer transactions and worldwide payments for almost no processing fees. Bitcoin uses technology to operate with no central authority; managing transactions and bitcoin issuance is carried out collectively by the network. Through many of its unique properties, Bitcoin allows exciting uses that cannot be covered by any previous payment systems. The software that the Bitcoin network runs on is a community-driven, free, open-source project released under the MIT license.

For more please contact the Bitcoin Alliance of Canada at (416)-831-9593, or email info@bitcoinalliance.ca

Contact
Bitcoin Alliance of Canada
4168319593
***@bitcoinalliance.ca

What do you mean a "message in the transaction"? Right now there is no standard way to encode data in a transaction aside from OP_RETURNs, which we specifically listed as an option. If you're thinking about those messages that blockchain.info shows, they're a proprietary overlay backed by BCI's database, not anything in the Bitcoin network.


We got a lot of similar feedback, and we decided we'll listen. We got rid of the COLGEN address part, and replaced it with an output to the 1111111111111111111114oLvT2 address (which is cryptographically unspendable by anyone and so neutral). I still like the "marker address" idea because it lets light clients easily search for geneses on BCI by going to http://blockchain.info/address/1111111111111111111114oLvT2, but I think doing it this way removes the centralization. We do want to make a premium color system, but we will set that up as a BitcoinX project independent of the underlying colored coins framework.

Also, I simplified the paper somewhat over the last few days, including making the tagging-based coloring algorithms simpler. The property that colorvalue = value - padding or zero is now true for all colors, for example.

You absolutely do need a price feed, centralized or decentralized somehow (eg. proof of stake voting), in order to do any of this. The problem is that the network has no way of "knowing" about the real world; there is no term in cryptographic functions to represent physical US dollars. Thus, we have the following problem. Suppose that you had some kind of instrument that reflected the price of USD without relying on any kind of price feed. Now, suppose that due to a market fluctuation the price of this instrument drops to 0.99 USD. Presumably, people would buy up this instrument seeing it as undervalued, and thus raise the price back up to 1 USD - that's the self-fulfilling prophecy for which the designers hope. However, the problem with self-fulfilling prophecies is that they go both ways. What if the price of this instrument drops to 0.96 USD, and some investors get a different idea: that the price drop is a sign that the link between the instrument and the USD is broken, and it will only drop further? Then, they sell, and the price of the instrument might drop to 0.93 USD, then 0.9 USD, then more and more people will realize this fact, and the price of the instrument will drop further. Unlike Bitcoin, however, it will likely never recover. Bitcoin can restabilize at a lower price target, and many times did. The USD instrument cannot stabilize at anything but 1 USD, so if it's not at 1 USD it goes to zero.

So these "magic"-based price targeting mechanisms will undoubtedly be stable for a while, but the first black swan event will wipe half of them out in an instant. This is why you need external, hard data on prices.


If people think this is a concern I could write a spec for proof of stake voting on price feeds to require larger collusions to significantly manipulate prices.


How is it not a CFD? It seems to follow the examples here pretty closely. In any case, it may be different in some technicality, but precise definitions aren't important; what is important is what it lets you easily have an arbitrary position in a market with an arbitrary margin if you can find a counterparty.


This is interesting; we could definitely do it.