Topic: The swarm client proposal - Reminder: 15 BTC pledged so far, now worth 3255$! - page 3. (Read 12127 times)

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.

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.

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.

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 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.
Same here. Electrum and medium nodes should be just fine for the BTC economy for now.

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.

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.

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.

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

We are lucky, Intel is making Xeon Phi

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.

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.

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
 

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.

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.

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.

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

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.

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

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.

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.

Well it WAS pretty horrifying when I first thought there was a huge scaling issue with BTC, some of the numbers posted around here however indicate less need to worry.

While I agree it is not critical, I have heard it mentioned here and there.

Additionally as I understand it both the BTC cam site, SD and likely other businesses work with pretty small amounts. A penny is bearable (already 10 times what was said in that quote though) but if we reach paypal levels (the 35c) it does hurt like 50% of the current BTC economy!