Bitcoin Forum
June 23, 2024, 10:21:52 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 46 »
741  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 25, 2012, 02:41:59 PM
Over in the altchain section I announced a crowd funding campaign for a demurrage currency. If we reach our goal, one of the things we will do is fully implement etothepi's proposal, either in Armory or the official client, and back-port the changes to Bitcoin.

Although relevant, I don't want to spam the forum, so this will be my only cross-post regarding it.
742  Alternate cryptocurrencies / Announcements (Altcoins) / [ANN] Freicoin: demurrage crypto-currency from the Occupy movement (crowdfund) on: June 25, 2012, 02:20:42 PM
We're asking for your help in creating a new crypto-currency, once with real value and lasting benefits. The idea of a demurrage currency has been raised before on this forum, but for those unfamiliar the idea is simple: apply a continuously-assessed fee to all accounts (4.4% APR, in this case), and distribute the proceeds from that collection to the miners.

Why on Earth would anyone want their money to lose value? The rationale is to separate money-as-a-store-of-value, a purpose Bitcoin serves very well, from money-as-the-medium-of-exchange, for which inflation/demurrage has significant benefits. These two functions are inherently at odds with each other, and there exists a rational economic theory put forth by Silvio Gesell a century ago which says that separating the two will cause (through economic self-interest) a lot of the ills of the current financial system and its effects on society to be fixed.

We're putting forth a proposal for a new crypto-currency with integrated demurrage and a few key improvements to the client (including trust-less block-chain pruning), which will be back-ported to Bitcoin as well. You can read the full details below.

To be clear, this is not a competitor to Bitcoin. Should Freicoin be successful, Bitcoin will retain its critically important role as a long-term digital store of wealth. Should it fail, that would only validate arguments for a deflationary rather than an inflationary/demurrage currency.

We've been working on prototypes and proof-of-concepts for these and other features over the past year, but unfortunately the demands of full-time jobs, family, and other commitments has meant progress occurring at a relatively glacial pace. We're seeking your help to make this currency and associated Bitcoin improvements happen A.S.A.P. We've created an Indiegogo campaign, and are of course accepting bitcoin donations as well, at the following receiving address:

Donation address: 1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j
Contribute with fiat: Indiegogo Campaign

GOAL: $28,000 USD

Here's the text of the campaign (geared towards those who may not have heard of Bitcoin), followed by the pledge rewards and a FAQ:


Freicoin is a decentralized, distributed electronic currency designed to address the grievances of the 99% movement and correct the excesses of the 1%. Whereas inflationary currency like the U.S. Dollar or Euro are controlled by central bankers under rules that benefit the establishment, Freicoin would be completely decentralized and self-regulating, with fees on stagnant or hoarded money (demurrage) paid in proportion to those community members who contribute work to secure the currency. It is an opt-in alternative currency to be used first by Occupy-supporting businesses and supply chains, then spread to the surrounding community across the globe. It includes a downloadable client for Mac OS X, Windows, and Linux, and an electronic network for transferring funds denominated in Freicoin world-wide.

Why

Demurrage currencies like Freicoin align incentives of bankers and financiers with the priorities of working class, forcing the wealthy through their own self-interest to invest in growth, jobs, and ventures with long-term thinking. An economy based on demurrage currency would not fall victim to to the same greed, excess, and short-term thinking that led to the 2008 crisis and financial collapse. Freicoin would instead continuously stimulate global growth through reinvestment, and dis-incentivize the hoarding by the 1% that caused the “credit crunch”.

The current systems of money, including the U.S. Dollar or Euro, are and always have been used to store value--money seen from the point of view of the holders, the wealthy. Freicoin emphasizes instead the view to that of the producer, the proletariat, the 99%: money as a means of buying the goods and services necessary to sustain life. These are contrary purposes--money cannot function properly as, nor should it ever be both a means of saving and exchange; it cannot be both accelerator and brake at the same time. Indeed, this confusion and conflict over the purpose of money is what led to the financial collapse of 2008 and the extended recession that followed.

Demurrage forces the entire stock of money to circulate irrespective of the desire of the wealthy to accumulate and store; banks, financiers, and corporations can no longer hoard money waiting for higher interest rates or a more favorable investment climate as the demurrage acts as a tax on stagnant money. Money is eternally losing value, so the incentive is to spend it as quickly as possible on the necessities of life or to invest in longer-term ventures that also provide stimulus for a growing economy, typically creating real jobs in the process. Real money becomes a sort of “hot potato” that is passed around as quickly as possible, in a virtuous cycle of investment. No longer are there incentives for financiers to withhold credit from those in need simply to what for fairer economic winds.

For the 99% who live paycheck-to-paycheck, the loss from demurrage is minimal and would be compensated for in wages and pricing. For those who manage to accumulate some savings and for the 1% who receive much more income than they reasonably spend, they can either save real wealth (gold, silver, Bitcoins, real estate, artwork and fine wine, for example) and accept the obvious limitations of wealth saving (loss, storage, rot, fire, etc.), or they can loan it out to borrowers at what ends up being near-zero basic interest. With sustainable near-0% interest loans the order of the day, businesses will boom and the economy will grow in a virtuous cycle.

How

For the past year we have been working in our free time to produce a proof-of-concept prototype based on improved and expanded Bitcoin technology. The prototype is a re-implementation of a generalized form of the Bitcoin protocol which makes possible advanced features like demurrage, multiple currencies existing side-by-side (Bitcoin and Freicoin), and other improvements for future scalability. Extensive unit tests demonstrate the validity of this core component.

  • What is Bitcoin? Bitcoin is a decentralized, peer-to-peer internet currency secured by strong cryptography and an open-source development process, and the foundational technology underlying Freicoin. Bitcoin enables anyone in the world to send funds to anyone else with minimal, fair fees on both consumers and merchants. Bitcoin is democratic in that everyone who uses the currency takes part in securing it (making sure the rules are followed and there is no fraud) by running a software program on their computers; they are proportionally compensated for this effort by collecting transaction fees, and in the case of Freicoin, demurrage. For more information about the benefits that come from basing Freicoin on Bitcoin technology, see the Bitcoin advocacy site We Use Coins.

What remains to be done, and what this campaign will fund is the following:

  • Implementation of a block-chain pruning technology, reducing storage requirements and startup time and eliminating a major impediment to wide scale adoption of Freicon (and Bitcoin, for that matter).
  • Re-purposing of Armory, the most advanced and user-friendly Bitcoin client, to work with Freicoin in addition to Bitcoin.
  • Public-facing website and always-on “seed node” to help new users download the combined Armory/Freicoin core software and get connected for the first time.
  • Initial “merged mining pool”--a service for Freicoin users to help secure the currency and receive rewards/compensation for that service.
  • A Bitcoin/Freicoin exchange to enable supporters to convert existing funds into Freicoin (by first buying Bitcoin and then Freicoin).
  • An animated film explaining what Freicoin is, what it does to fix the problems of the financial system, and how people can get involved in using and promoting it.

Once the above objectives are reached, Freicoin will be ready for adoption by Occupy groups and supporters, and other like-minded groups. The work can then begin to get Freicoin adopted as the first “global community currency”. As a peer-to-peer application, once completed Freicoin can be used by anyone in perpetuity without any required ongoing maintenance.

At the completion of this project Freicoin will be ready for individual communities to adopt, for businesses to accept as payment and for consumers to use. The initial freicoins will be in the process of being generated and fairly distributed to community members who participate in securing the network.

This campaign will directly pay for hardware and server time cover the first year of operations, materials used in the logo, branding, film, and initial marketing, and to keep the basic necessities of life as we decline contracting work to focus on Freicoin.

Join us and be a part of the reformation of global finance!

GOAL: $28,000 USD

Fiat donations: Indiegogo Campaign
Bitcoin address: 1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j

$1
BACKER
Everyone gets access to the project upon public release, and a chance to participate in the creation of a new global economy.

$10
SUPPORTER
Our heartfelt thanks and your name in the credits of the official client.

$30
PHILATELIST
Receive a custom post card designed by the developers and sent from Silicon Valley with a personalized message of gratitude.

$80
T-SHIRT!
A beautiful silk-screened “Occupy Freicoin” T-shirt (add extra $10 shipping to Canada and $15 to other non-U.S. destinations).

$150
IMMORTAL
You will be immortalized in the genesis block of the Freicoin block chain, where your name or short message will be preserved forever in the historical record.

$500
FOODIE
Dinner with the developers, their family, and other backers in the Silicon Valley/S.F. south bay-area (transferable if you know someone who lives or will be in the area at the appropriate time).

$750
ACTOR
Cameo appearance in the animated film introducing, explaining the Freicoin project and how to get involved.

$1,500
VISIONARY
Membership in our advisory circle--a group of visionaries that will meet (virtually) approximately once a month to be informed of our current efforts and from which we seek ideas and inspiration.

$3,500
SPONSOR
Membership in our advisory circle as well as recognition as official sponsor of the Freicoin project. Your logo, business name, or other mark belonging to you will be featured prominently on the official public-facing Freicon website.

What is “Freicoin”, and how does it work, really?

Freicoin--literally “free money” in German--is based on the principles of economist Silvio Gesell's Natural Economic Order. Freicoin is an electronic currency managed through a self-regulating, distributed electronic network based on Bitcoin technology. The network enforces a continuously assessed 4.4% APR fee on all account holders. This fee acts as a tax on stagnant money, driving up the rate at which money flows through the economy and acting as an economic stimulus, and discouraging unproductive hoarding by the 1%. The proceeds of the demurrage tax are repayed transparently and proportionally to the community members who donate computer time to running software that regulates and enforces the rules of the network.

Besides providing a virtuous cycle of rewarding positive long-term investments, demurrage currencies also reduce interest rates to near-zero (hence the “free money”), providing further job-creating stimulus and helping to reduce the magnitude of the boom-bust business cycle.

Where can I learn more?

Here are some resources:


You've based it on Bitcoin technology. Is this a competitor to Bitcoin?

Absolutely not! The two serve quite different purposes. The properties of Bitcoin make it analogous to precious commodities like gold or silver, and it will always function as a useful store of value. Freicoin, on the other hand, is meant to be used as a medium of exchange only, kept on hand just long enough to provide a cash-flow buffer. The demurrage fee encourages recipients of Freicoin to put their money to use as soon as possible in an exchange (even by buying bitcoins, for example), whereas the deflationary nature of Bitcoin rewards hoarding and serves a different purpose as a long-term store of value.

How is this different from that other Occupy currency?

There have been a couple of monetary reform ideas floated by members of the Occupy movement, but most likely you are referring to “OCCCU”, another demurrage currency created by students at the Vorarlberg University of Applied Sciences and presented to members of the Occupy movement at Davos in January, 2012.

OCCCU's provision of “basic income” and the assessing of demurrage fees is accomplished by means of centralized regulators, the currently faceless OCCCU “general assembly”. This is hardly an improvement over the current system of centralized banking; as the great poet Pete Townshend once said: “meet the new boss, same as the old boss”. It is our firm belief that real monetary reform will only come when the system does not require trust in any individual or organization, and when all operations are made transparent. Freicoin accomplishes these goals with distributed self-regulation and automatic distribution of the demurrage pool on a fair and proportional basis.

Who are you?

There are three of us that have come together to make this possible: engineer Mark Friedenbach, designer Aaron Blumenshine, and project manager Matt Everingham.

In his day job, Mark is a application developer at NASA. He builds large data visualization applications as well as web and database backends. Aaron is an accomplished and award-winning photographer and graphic designer. Matt is an aerospace engineer and project manager, also at NASA, who has designed and built a series of low-cost exploration rovers controlled over the internet.

We became aware of Silvio Gesell and demurrage currency through our research into Bitcoin, and for the past year we have been developing the prototype and proof-of-concept mentioned above in our free time.

Will it be open-source?

Absolutely. In fact, the transparency provided by an open-source client is essential to the basic ideals of Freicoin and the Occupy movement. That said, it will certainly be possible to build closed-source software and businesses on top of the open-source Freicoin core.
743  Alternate cryptocurrencies / Altcoin Discussion / Re: Nurturing AlternaCoins on: June 25, 2012, 07:53:19 AM
Gavin, here's an idea: generalize the official client to handle multiple coins from the same codebase, or otherwise make it less difficult to maintain patches between codebases.

People will work on whatever scratches their itch. The onus is on you, the core developers, to make the development process receptive to incoming talent.
744  Bitcoin / Development & Technical Discussion / Re: Roadmap to 1.0? on: June 23, 2012, 06:08:05 PM
There was talk about using TPM modules to firewall access to private keys. That would help significantly, but I don't think this has advanced to an actual proposal yet.
745  Bitcoin / Development & Technical Discussion / Re: SQL block database: about nested sets on: June 22, 2012, 05:20:13 PM
I wrote/improved-upon a nested-set implementation in Python using SQLAlchemy for this exact purpose. It's hosted on github.

It'll probably not be worth the effort to integrate it into your perl library directly (being in Python and on top of SQLAlchemy, etc.), but you can port it, or maybe you'll just find it a useful reference as you write your own.

EDIT: I suppose the codebase might be intimidating to someone who not versed in Python or the SQLAlchemy framework. You'll find the insertion/update/deletion code in 'sqlalchemy_tree/orm.py', and the higher-level methods for manipulating the tree in 'sqlalchemy_tree/manager/{class_,instance}.py'.
746  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 22, 2012, 07:21:48 AM
Maybe this will help: the trouble is when Satoshi released Bitcoin 0.1 and the whitepaper, he came up with this idea for a version of the client that only kept block headers and skimmed for transactions it cares about. It's become known as SPV--Simple Payment Verification--or a “lightweight client” and has a weaker trust model than a full verifying client.

We are not discussing that in this thread. What's going on here is the creation of a full-featured “thick client” which doesn't require the entire block chain history and could conceivably be run even on low-memory and embedded devices as bitcoin scales up. You can have your cake and eat it too.
747  Bitcoin / Development & Technical Discussion / Re: Stratised chain-services are secure on: June 22, 2012, 01:15:54 AM
Assume that you connect to n chain-services controlled by different organisations/individuals.
Show me why that is a valid assumption in a hostile environment, please.
748  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 22, 2012, 01:14:11 AM
Quote from: etotheipi
On the other hand, I was hoping for a structure that wasn't too complicated, and both RB trees and Patricia tries have complicated implementations (even though the concepts behind them are fairly simple).  But if we're going to have to go with something complicated, anyway (to limit worst-case speed and time performance), then I'd have to vote for Patricia trie or variant.  Not only is it O(1)... someone brought up the very good point that updates to the tree can mostly be parallelized.  That sounds like another good property of a tree that's going to have very high update rates...
The 2-3-4 tree (aka B-tree of order 4) is really the only one I would consider in this circumstance. RB-trees are actually a special representation of 2-3-4 trees, but the implementation choices in balancing an RB-tree don't exist for 2-3-4 trees (for a given 2-3-4 tree there can exist more than one RB-trees that “encodes” that structure, but not vice versa). A higher order B-tree would also work, but then you would be trading increase CPU time for decreased I/O, which doesn't fit this application.

That said, the ability to parallelize prefix/radix tries is a very good point. You might win me over to that side yet... but if self-balancing trees are to be used, the 2-3-4 tree has some clear benefits over others (KVL, RB, etc.).


To the other posts... why would you ever need to rebuild the tree? I don't understand the purpose. If you are using a self-balancing structure then it stays balanced “for free”. And under what circumstance would you have all the transaction data, but not an existing tree structure or the block chain from which you can order the updates?
749  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 21, 2012, 05:44:05 PM
@etothepi, what about non-standard transactions? Including IP, P2SH and future contract formats. Not all outputs can be reduced to an address. We've been speaking loosely about a tree of “addresses” but it would really have to be a tree of output scripts, so it's not going to be possible to limit search-string length for the prefix trie.
750  Bitcoin / Development & Technical Discussion / Re: Symbolic link for blockchain on Linux on: June 21, 2012, 08:29:52 AM
@kneim, I saw similar issue pop up elsewhere. Almost guarantee that running with '-detachdb' will solve the issue.
751  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 21, 2012, 08:00:53 AM
I am the one who originally suggested the 100 block interval... but I don't think I said that updating the meta tree only every 100 blocks is what should be done.

Rather, the meta tree should be rebalanced every 100 blocks, and between then, nodes should be added and deleted using methodology that avoids (procrastinates) having to recalculate the hashes for most or all the nodes in the tree any time there was a change.  Otherwise, every incoming transaction will have a huge CPU time burden that's not sustainable.  Rebalancing the tree is much like rebuilding a database index.
I'm not sure I follow. Updating any tree (balanced or not) is a constant-time operation. Updating any Merkle-tree (balanced or not) is log(N), although you can save a little effort by marking updated nodes as dirty and only updating Merkle hashes at the end. Rebuilding a database is N*log(N), a different beast. Anyway that's beside the point. Updating a balanced Merkle tree shouldn't be any more complex, algorithmically, than leaving it unbalanced. Unless I'm missing something; am I?

Sorry to be slow, but I don't see the gain here.  If a lightweight client is going to trust that a metablock that's been merged into the chain is truthful (because it's been built into a block), then it can just as reliably trust that a transaction that's in the chain a few blocks back is valid, because it's been built into a block.  There's no need for it to keep anything.  The only real advantage here seems to be that it saves miners from having to have a hard disk, and it seems like a lot of engineering to do that.

Quite possibly I'm missing something, in which case it would probably help for someone to step back and explain the aims and benefits.
Wrong problem. It saves the lightweight client from having to download, verify, and keep track of any of the block chain at all, except for those parts the user cares about (their own unspent outputs, for example).
752  Bitcoin / Development & Technical Discussion / Re: Symbolic link for blockchain on Linux on: June 20, 2012, 09:27:17 PM
Have you tried a hard-link (remove the '-s' from 'ln')? Also, make sure the client is configured to disconnect the database on shutdown (this is no longer the default behavior).
753  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 20, 2012, 07:38:46 AM
Can compression be used as an intermediate step along the way.  That is, is the blockchain stored on the disk in an efficient manner?  Also, why do noobs have to dl the whole block chain from peers?  Its soooo slow.  Couldn't each release come along with a zipped copy of the blockchain up to the date it was released, along with a hard-coded hash of that block chain up till then with a built in check.  That way the user can just dl the whole shebang in one swoop.

These of course are not permanent measures but maybe as interim fixes for now.
Most of the sync time is spent doing ECDSA verification and disk I/O. Compression would actually make the problem worse. Packaging the block chain up to the latest checkpoint isn't a bad idea, but won't improve the situation as much as you probably think. The client would still have to verify the block chain, which means hours on end of 100% CPU utilization.

The real solution is to develop a way to avoid verification of historical data without compromising the security that verification provides. That's what this thread is about.
754  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 18, 2012, 10:45:07 PM
SPV nodes keep copies of all of their own transactions, so they should always know when outputs they own are spent. They don't need to query the network for this information.
What if you have the same wallet on two systems?
755  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 18, 2012, 05:19:18 PM
It might then be properly called a "meta chain" rather than an "alt chain".
That's much better terminology. Thank you.
756  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 18, 2012, 01:07:17 AM
Conceivably you could run an even lighter client that just implicitly trusts the head of the alt-chain. Such a client would rely upon honest miners doing the work of verifying the alt-chain, and not actually perform such checks itself.
757  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 18, 2012, 12:17:43 AM
Quote
The counter argument is that you will never find yourself in this position:  you are either downloading and processing the whole chain, in which case you have no problem replaying the incremental updates.  Or you download from some checkpoint, in which case you can still replay the insertions and deletions from that checkpoint with minimal effort.
Correct. So why does it matter? I'm not sure why it's “inelegant” either, since as you point out there is no use case for recreating the tree from only an unsorted list of outputs anyway.

Quote
A couple months ago when I first theorized this idea, I had a very good good reason for believing that you needed to aggregate the unspent-TxOuts (UTXOs) by address/script.  If you didn't do it, bad things would happen.  Unfortunately, I don't remember what those bad things were!  It's entirely reasonable that I mis-applied some logic in my head and decided I needed an unnecesssarily-complex data structure to achieve security.
If nothing else, it is certainly convenient to pull in all the unspent outputs for an address without having to go all over the tree, as you can under your approach. That's a very common use case, so it would make sense to optimize for it.
758  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 17, 2012, 11:32:21 PM
As others have mentioned, a self-balancing binary search tree would solve the only real technical issue here. Red-black trees would work fine, or their generalized parent structure the 2-3-4 tree (B+tree of order 4), which would provide a conceptually cleaner implementation and serialization format.

Overall, great work. I can assist you in implementing it.

There is one problem, though it may be part of the materials you already referenced:  the tree must be constructed identically by all parties, and from any state.  And all binary-tree structures are insert-order dependent, unless you're storing them in some sort of trie.  Specifying an insert order doesn't work, because someone constructing from scratch doesn't know how someone updating from a previous tree will insert them.  But I wouldn't want to go to a basic trie, due to the space inefficiency.  Something like a Patricia tree/trie would probably work, but it's very difficult to implement (correctly) and there's not a lot of existing, trusted implementations out there.
(EDIT: Sorry, this is basically what socrates above. I should have read the whole thread first:)

This is a non-issue; simply specify the order of insertion/deletion. For example: “Process blocks in order; for each block process transactions in order; and for each transaction first delete all inputs (in order) from, then insert all outputs (in order) into the alt-chain Merkle tree”. You might have to throw a special case in there for transactions that have as input the output of a transaction that occurs later in the same block (is that even allowed?).

Why (and how) would you be creating a tree from scratch without either access to the blockchain or the tree in the last alt-chain checkpoint?

Quote from: etotheipi
Consider 10 unspent-TxOuts, {0,1,2,3,4,5,6,7,8,9}.

You and I are both constructing the same binary/red-back tree, except that you are starting from scratch and I am starting from a tree where elements {0,1,2,5,6,9,13} are part of the tree.  

I have to add {3,4,7,8} and remove {13} from my tree.   You just add all 10 elements in a specified order.  

We're going to get different roots.  I technically know how your tree would've been constructed, but I might have to start over and reinsert everything from scratch if I wanted to make sure my tree structure matches yours.  

That's what I mean about "commutative computation" -- we need to make sure that regardless of whether you're starting from scratch, or updating an existing tree from any point in the past, that you'll get the same answer.

No, that's going in the wrong direction. Updates to the blockchain occur in atomic operations: blocks. Simply mandate that trees are constructed/updated according to the canonical ordering provided by the blockchain. If you insist on creating the search tree from scratch, simply replay the blockchain inserting and removing in the order specified therein. Or you can start from the tree of the last found alt-chain checkpoint, and replay insertions & deletions from that point forward.

Yes, order of operations matters, so standardize an order of operations.
759  Bitcoin / Development & Technical Discussion / Re: Building A fully decentralized, automated, and anonymous bitcoin exchange! on: April 08, 2012, 02:09:53 AM
MintChip provides p2p transactions between accounts denominated in Canadian dollars (or a few other national currencies).


What, if anything, does that have to do with bitcoin or exchanges? Am I missing something here?
760  Bitcoin / Bitcoin Discussion / Crowdfunding will be legal in U.S. after Thursday, 5 Apr 2012... on: April 03, 2012, 06:52:41 AM
...when Obama signs the Jumpstart Our Business Startups Act. Anyone will be allowed to buy stock in early-stage startups, up to a certain limit. It will also ease a bunch of other restrictions, including letting companies advertise online that they are seeking investment.

Needless to say, this will help a lot of early-stage Bitcoin startups.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 46 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!