The swarm client proposal - Reminder: 15 BTC pledged so far, now worth 3255$!

[Etlase2]

Micropayments over a digital currency are a lost cause, imo. 3nd party websites will pop up I'm sure that will handle microtransactions over the website and people can pay themselves out. They do not need to clutter the block chain. The smallest transaction requires just as much effort as the biggest, so the fee is always going to be somewhere that makes microtransactions very expensive.

[1715384185]

1715384185

[1715384185]

1715384185

[1715384185]

1715384185

[Mike Hearn]

My point about YouTube/Facebook etc is that it was originally believed to be impossible no matter how big your datacenter or rich your backing company. Technology improved fast enough that it became possible. For a hobbyist on a laptop? No. But possible? Yes.

The requirements for a VISA scale node are with todays hardware. Bitcoin is barely at 1-2tx per second now, let alone 4000. If Bitcoin ever reaches such traffic levels, the cost of running such a node will have fallen dramatically.

[Vitalik Buterin]

One of the selling points of BTC is micro transactions,

Not sure where you got that from.

Here's an example:

May 9, 2011 - Gavin Andresen:

For the record: bitcoin is not designed (and isn’t really appropriate for) micropayments.

Bitcoin transactions are broadcast across the peer-to-peer network, and received by all the nodes on the network. It isn’t designed to handle gazillions of tiny transactions; we estimate the network-wide cost of handling a typical transaction is about 0.1 US cents, so payments smaller than that DEFINITELY don’t make sense. If the cost of transaction processing is a significant fraction of the transaction value, then that’s bad, so bitcoin really only makes sense for transactions worth more than a few pennies (and most people define micropayments as sub-penny).

 - http://gigaom.com/2011/05/09/can-flattr-plus-twitter-make-micropayments-a-reality/#comment-622793

The term "micropayments" (or "microtransactions") can mean different things. In my experience, most people take it to mean payments in the $0.10-$2 range. For things that are even smaller, particularly automated protocol payments like one might use in a hypothetical incentivized mesh networking setup, I tend to use the term "nanotransactions".

[jevon]

Arbitrarily small probabilistic micropayments are possible:
https://en.bitcoin.it/wiki/Nanopayments

For most payments (like 999/1000), there is only data back and forth between the buyer and seller without posting a transaction to the network.

[Mike Hearn]

Indeed. You can also do micropayment-adjustments to a pre-determined party (or at least, you will be able to, once we re-activate nLockTime and get the new versions deployed).

https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

[Realpra]

Just visited the mining sub forum:

If miners start to choose to make smaller blocks to make sure they get propagated then the power of the network is not that important - you will STILL have scaling issues.

Heavier blocks are more likely to get "stranded" and as such orphaned even if they were first.

This could help push fees way up if bitcoin grows say 10 times more in a few years even if technically the network can handle it.

Probabilistic payments are a cool idea, but it has limits. I doubt many want to risk paying much more than 100 times more than they bargained for.

As it stands now fees will likely double along with network usage, so if SD doubles the fee will be ~1.5 cents$ and so on.


Now okay that's for SLOW txs you say?

Well a VISA merchant KNOWS he has been paid instantly; a BTC merchant pretty much HAS to wait until receiving a tx and likely at least 1 confirmation.
This means that some merchants will likely have to make users pay a fee if they want quick results.

Further such quick results would like be required exactly when dealing with micro payments - waiting 20 min. to get to read an article you paid 0.01 BTC for is not much fun... and a fee would take much of the profit.

[Mike Hearn]

VISA merchants don't get paid instantly, far from it. You can't really be sure you've got the funds for months as chargebacks can occur at any time, and besides, settlement occurs asynchronously.

[Realpra]

VISA merchants don't get paid instantly, far from it. You can't really be sure you've got the funds for months as chargebacks can occur at any time, and besides, settlement occurs asynchronously.

Yes I know, but its slightly safer than accepting a completely unrecognized tx if confirmation times/fees keep growing.


Also 1 cent is not a lot, but it is worrisome to me that we are already at that level for normal 10 min. confirmations. If BTCs current performance really is O(n) then that will be 0.1$ in less than 6 years time from now, assuming 50% growth of BTC:

1.5^6 = 11,4.

In 12-20 years it would be 1$ (more adjusting for inflation). BTC would be worth around 5 billion$ then.

Bitcoin then would not be a very big "company" but would be charging MORE than paypal on smaller payments.


As I said 12 years is no rush, but I think we should fix it before then before it inhibits our growth - BTC won't be widely adopted with fees above/near those of paypal.

If BTC is not widely adopted then bankers will not use it for backing or major transactions so you loose in both places.

[thezerg]

While bitcoin may have an important niche as a meta-currency in the forex markets, it will be competing against other unbacked currencies with a much longer history of value perception (i.e. gold, silver, USD).  So it may not in fact be terribly successful in this role, especially if there is no other market providing value stability.  Of course, its great value in the forex market is its ease-of-transfer... so it may have a niche even without value history.

But P2P micropayments could be a great underlying market niche for bitcoin since it is currently completely unserved by today's centralized systems (paypal, etc), even though as other posters have mentioned a centralized system is in theory more efficient.   Furthermore, it seems like there is some confusion as to what size the term "micropayments" really refers to; some posters seem to limit it to literally "micro" numbers; that is payments on the order of .000001 BTC. 

The real untapped market is probably "millipayments" to coin a new term; that is anything from 1BTC to .001 BTC.  The upper bound is really not 1BTC but whereever competing systems  cost starts becoming a significant overhead (Paypal's $0.30 + 3%).   The paypal fees today clearly include significant profit (or the USA STILL wouldn't have a ISS supply ship), but there is additional overhead associated with reversibility (chargebacks) and security.  Security of the BTC "cloud" is not the micropayment processor's responsibility, unlike balances carried in Dwolla and Paypal, for example.  So this overhead will ensure that any centralized, reversible payment system will not be able to compete with P2P cryptocurrency at some lower bound, from the perspective of the micropayment processor.

From the perspective of the entire network a payment may cost $.001 (see early posts -- a quote by Gavin), but it does not cost the micropayment service nearly that much.  This means that Bitcoin is currently the BEST micro/milli payment system from the perspective of the payment processor and transacting parties.  And it is silly to imagine that nobody will take advantage of this; we have this exact issue today with miners using rental agreements that include electricity to mine "profitably", even though from an overall perspective this mining might be a net loss.

Such a micropayment service could easily accept unconfirmed transactions at face value with some automated checks and balances to ensure that no anonymous user submits a million of them at once.  For example, accept at face value transactions with at least 1BTC in "change" -- that is, the originating account had at least 1 BTC in it -- but do not accept many simultaneous from accounts funded with microBTC.  This would ensure that a scammer would have to have an extremely large net worth to simultaneously run thousands of micropayment scams; and volume is necessary to make enough money to be worth the effort.  Or use proof-of-work as proposed to stop email spam.   It is unlikely to be time-effective for a scammer to carefully orchestrate a single double-spend attack for .000001 BTC given today's valuation of where 1 BTC buys about 2 gallons of milk.  This is essentially the same argument as the one describing the futility of picking up a penny.

So in sum, I believe that millipayments and micropayments are a very important area of innovation for bitcoin and that we can assume that there WILL BE a vast quantity of these payments in the future.  Let us rework (or overlay) the infrastructure now so that these payments are seen as valuable economic activity, not blockchain "spam".

thezerg
 

[Realpra]

So in sum, I believe that millipayments and micropayments are a very important area of innovation for bitcoin and that we can assume that there WILL BE a vast quantity of these payments in the future.  Let us rework (or overlay) the infrastructure now so that these payments are seen as valuable economic activity, not blockchain "spam".

Your post was a little confusing, but I can agree to that part.

I think Bitcoins could survive without the micro payments market, but if payments around 1$ and below start to become unprofitable even while there is still a miners subsidy that signals scaling issues.

+ Bitcoin would of course grow faster with minimal fees which paves the way for larger transaction/savings in BTC as well.

[Gabi]

This means a single core today can probably, with tuning and the block chain held in RAM but no special hardware beyond that, verify and accept about 80 transactions/sec (note the current rate is 4 transactions/min). This means a network node capable of keeping up with VISA would need roughly 50 cores + whatever is used for mining (done by separate machines/GPUs). Whilst building a single machine with 50 cores would be kind of a pain load balancing inbound "tx" messages over multiple machines would be very easy. Certainly a single machine could easily load balance all of VISAs transactions to a small group of verification machines which would then send the verified tx hash to the miners for incorporation into the merkle tree.

For receiving and handling all the "tx" messages, you therefore could build a rack of 12 4-core machines that would keep up.

We are lucky, Intel is making Xeon Phi

http://www.tomshw.it/files/2012/06/immagini_contenuti/38144/xeon-phi-02_t.jpg

50 cores, tons of computing power, it seems perfect for this!

Unless of course the GPU can be used for that with a similar speed.

[Realpra]

That's not the issue, the issue is that these super centers could become the only ones capable of running a full client.

With no one else doing ANY checks they could increase the block reward, delete any information your coins ever existed or raise the fees through the roof - name it.

Decentralization is better, its the whole damn selling point of BTC. P2P crypto currency.


How many super centers would there be? 10-100? 1000? Anything below 100 and the operators could agree on things you (users) don't like. Below 10 and the government shuts down BTC.


Maybe its not needed now, but the swarm clients time will come.

EDIT: Btw anyone want to pledge towards this project? I already pledged 15BTC. All your BTC will be worth zilch if this thing isn't done at some point

[MatthewLM]

I came to this topic after seeing this mentioned in another topic. Realpra would like someone to implement this idea, but they cannot if it cannot be understood. I did not understand it. The explaination needs to be completely changed to precisely explain the idea. The language used was confusing. For instance the word "similar" should not be used when describing something technical and precise.

Perhaps Realpra can research the bitcoin technology further and come up with a better explanation. If anyone has a good solution for distributed block-chain validation then I will read the proposal. I've thought about wether or not this is possible (In a practical way) myself but I have not come up with any solutions and so I am currently focused on implementing a somewhat advanced version of the SPV model.

[Realpra]

I came to this topic after seeing this mentioned in another topic. Realpra would like someone to implement this idea, but they cannot if it cannot be understood.

I am in fact in the process of understanding BTC tech better, but for a different project.

If there are any specific points I will elaborate.

The basic idea is:
Each client only actively watches a few addresses while blindly accepting the others in the block.
This allows only parts of the block branches to be sent/stored while every client doing verification.

Each client would decide how many addresses to watch from one to all in the blockchain (as the normal client).
Security is maintained as clients A communicate via secure non-hijackable channels (PKC) and B clients can report invalid transactions so that the entire network drops a bad block.

Clients can request/send info on specific addresses to avoid sending entire blocks.


For now I suggest people use electrum or something.

[MatthewLM]

This allows only parts of the block branches to be sent/stored while every client doing verification.

What you mean is that only particular transactions are looked at, such as maybe validating along the chain for particular outputs? You can't spread validation work for each bitcoin address as the bitcoin protocol allows for many transaction types and you cannot miss out non-standard transactions which do not use bitcoin addresses.

I was trying to figure out how clients could validate particular movements of bitcoin myself at one point, but there are so many issues with it, to create a reliable, efficient and secure solution may be extremely difficult, and may not be a simple as you think it would be. It may have issues, when you begin to think about it more closely, that make it impractical and perhaps worse than other scaling solutions.

I don't know. For now I'll continue working on what I am working on and possibly come back to this at a later time. It requires a significant investment in brain power.

[Realpra]

This allows only parts of the block branches to be sent/stored while every client doing verification.

What you mean is that only particular transactions are looked at, such as maybe validating along the chain for particular outputs? You can't spread validation work for each bitcoin address as the bitcoin protocol allows for many transaction types and you cannot miss out non-standard transactions which do not use bitcoin addresses.

Any transaction or script will ultimately affect two or more addresses (out/in). The swarm client would save any transaction data affecting an address it was watching including scripts.

Hence scripts might be saved by clients watching the sending address at first and at completion (escrow/mult sig style?) also the clients watching the receiving address.

Am I missing something even more exotic than that?

I was trying to figure out how clients could validate particular movements of bitcoin myself at one point, but there are so many issues with it, to create a reliable, efficient and secure solution may be extremely difficult, and may not be a simple as you think it would be. It may have issues, when you begin to think about it more closely, that make it impractical and perhaps worse than other scaling solutions.

I am usually pretty good at coming up with algorithms.

I had a vague yet decently defined idea 6+ months ago and now everything is as envisioned in my bachelors project. That was pretty advanced too.


BTC is moved if a block containing the movement is accepted by most clients. This means that as long as the swarm clients can tell by ONE fraudulent tx that a block is false they can all reject the block.

The data proving a block is invalid can be propagated by the swarm client that watched the (empty) sending address by just sending the txs/block branches pertaining to that movement.

The only way to trick a swarm client would be to keep it isolated from the reports from all the other clients that already know it's a fake block.
However this can only be achieved by cutting said clients internet connection - which would also prevent any benefit from the "attack".

Since signed TXs and block hashes cannot be faked the swarm client could operate in a SEA of attackers just fine without double spend attacks occurring as long as just ONE attacker doesn't know what txs the other attackers don't want sent.

Once the swarm client has information about a tx you can't force it to forget it or "unsend" it. Specifically I am here talking about the tx that says you already spent your money.

I don't know. For now I'll continue working on what I am working on and possibly come back to this at a later time. It requires a significant investment in brain power.

Same here. Electrum and medium nodes should be just fine for the BTC economy for now.

[doobadoo]

I think you should read this first, if you didn't already:

  https://en.bitcoin.it/wiki/Scalability

Many software projects that at first seem impossible to scale actually later turn out to be feasible. Examples: Facebook photo storage, YouTube, etc. Even at VISA levels of traffic it would be quite feasible for small companies or rich hobbyists to run full verifying nodes with todays technology, and tomorrows technology will be a lot better. There can easily be tens of thousands of such nodes and perhaps that's all you need, Satoshi certainly thought so before he left.

The idea that a supernode structure makes Bitcoin vulnerable to being "shut down by the US Government" is not realistic. It's not like BitTorrent has gone away, right? Bitcoin doesn't try and hide its traffic, so if a government wanted to make running nodes illegal they could easily do so regardless of how many nodes there are.

This is absolutely why all traffic between nodes should be encrypted, it should look similar to bittorrent or tor traffic.  Isn't it just some ssl/tls?  wouldn't this be easy?  And to further improve anonymity txs should be broadcast by a different node than the originating, perhaps a hop or two away?

Anonymity is supposed to be a big Bitcoin feature...and i know, i know, wait for the 0.7 release for the ability to run a node behind a hidden service..ya ya.  Still, ALL Bitcoin traffic should be indistinguishable from some other, heavily used p2p encryption...eg, packets should ape Bittorrent or Tor.

[Etlase2]

Anonymity is supposed to be a big Bitcoin feature...and i know, i know, wait for the 0.7 release for the ability to run a node behind a hidden service..ya ya.  Still, ALL Bitcoin traffic should be indistinguishable from some other, heavily used p2p encryption...eg, packets should ape Bittorrent or Tor.

From the little I've read and watched about this topic, hiding bitcoin traffic would be fairly difficult even if encrypted. The handshake process will be a dead giveaway, but if it is made to mimic another handshake process, it will still be nearly impossible to mask the data stream (400 bytes at irregular intervals, oh look it's bitcoin!), at least not without ballooning the amount of data required.

[doobadoo]

Anonymity is supposed to be a big Bitcoin feature...and i know, i know, wait for the 0.7 release for the ability to run a node behind a hidden service..ya ya.  Still, ALL Bitcoin traffic should be indistinguishable from some other, heavily used p2p encryption...eg, packets should ape Bittorrent or Tor.

From the little I've read and watched about this topic, hiding bitcoin traffic would be fairly difficult even if encrypted. The handshake process will be a dead giveaway, but if it is made to mimic another handshake process, it will still be nearly impossible to mask the data stream (400 bytes at irregular intervals, oh look it's bitcoin!), at least not without ballooning the amount of data required.

There are ways.  Adding Nonce data to randomize size, interval, etc.  But you are also assuming that some one (a person) is sitting there sifting thru your packets.  They are not, unless you specifically are under active investigation.   No no, there will be too many suspected bitcoin users.  They need to automate the process. They will use filtering and deep packet inspection to detect and block the traffic.  Throttling by some isps was the reason for encrypting bittorrent traffic.  (don't know how successful it actually is).  But certainly with current state of affairs Bitcoin could be just k-lined.  Probably will happen first in China, they are more obsessed than even the US government at controlling fund flows.

[notme]

Throttling by some isps was the reason for encrypting bittorrent traffic.  (don't know how successful it actually is).  But certainly with current state of affairs Bitcoin could be just k-lined.

Now they just throttle me any time I use a lot of traffic, no matter what it is.