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.

Its called SSL I think.

Say I store the public keys for:
1. My friend Bob.
2. Guy who posted his key on a forum.
3. MtGox.

Since I am lazy that's it.

You send me invalid money and I check those nodes.

It now either becomes apparent that someone is blocking my connection OR one of them will likely NOT be colluding with you.

You can fake IPs but you have no way to fake that you have their private keys for my encrypted communication so my client will just display "You are under attack!!!".

I mean what customer/merchant would wait days to know whether payment was made or not?

edit: A swarm client would run on a smartphone and act as a full node btw.. Could even mine a bit in a pool.

What determines the max size of a block?

Won't we need to increase that?

My solution is basically trust that 1 guy out 1000 is honest - or run the client you are today with massive lag/huge fees.

I think you misunderstand, you don't need to connect to a TRUSTED node per say just ANY node that is not colluding with the attacker.

ANY will do. Could even be a different ATTACKER that didn't know what the FIRST attacker wanted hidden!

As for secure communication that is pretty standard, BTC should have it already if it doesn't.

Read above.

.
That would be DAYS in confirmation time in the beginning, who would use that to any great extent?

You would be relying on SOMEONE checking that all those 6 logs are complete and then what? REPORTING it if not? Dumping the entire chain?
What miner would do that for an alt chain log?

As for reporting, yep you just arrived at part 1 of my solution, welcome.

Except its pretty easy as a website delaying anything significant (sending money/products) say 10 minutes. That pretty much destroys any double spend attack I have heard of.

Sure you could steal a micro-payment unlocked article that I would unlock with 0-conf. but then after 10 minutes I would ban your IP forever/call the cops and have lost a total of 0.01 BTC.

He can't control you if you choose to connect to say the mtgox node or some other trusted* node via public key encryption.

The attacker would be unable to understand such secure messages - provided you have a known good public key to write to.

(* Not really trusted, just ANYONE who doesn't realize what txs the attacker want withheld.)


So that is basically a fork right? My solution doesn't have that.

Anyway what if I am a miner and I include a signature of a incomplete log in my base?

The ONLY way to tell my log was incomplete would be to download the entire chain.

A swarm client would be instantly useful and has similar/same programmatic complexity as this.

Heck mining pools might be richly rewarded by adopting swarm clients. (by being able to have larger pools/more txs/fees in a block)

I was lucky enough to put it there as a miner, so the signature has been merged mined, all inside txs are valid - I just didn't include the one where I moved a bunch of coins.

Only way to oust that is checking the entire chain yourself.

I think with every miner motivated to do the above attack my solution is safer.

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.

My solution already has this in it in by looking at branches.

Each node would be able to choose the depth of the merkle tree at which it wanted to verify.

All nodes could choose different points.

My solution did not seek consensus, as I said once you have the branches with transactions linked to the main hash you KNOW they are true.
Even if 90% of the network is withholding the "spent it all" transaction you would easily be able to get it from just ONE honest node.

How is the alternate merkle tree even safe with no/little mining? I could make a false log, sign it with minimal mining or put it in the blockchain (both easy) and fool you all right?

That only works if the phone book is complete - what if you are not sent the most up to date altchain/log-block? What if I send you false ones?

My solution had further advantages as NO ONE would need the full block - a big advantage as miners can't run lite nodes as it is.

My solution also solved propagation time problems blocks have today - this solution would not as it relies on the normal blockchain.

All of this without forking or merged mining.

Nice, didn't see that!

I'm not too worried about double spends; the time frame you have to run away with your product, the loops you have to jump through and the small amounts people will only accept with 0 confs... just not worth it.

Once you cut down on the section of the blockchain you need to download while still verifying, you have essentially a swarm node.

I suggested something very similar in my thread about pruning not being enough.

However if you create a tx log instead of a merkle tree then you break compatibility, since the "root hash/log signature" will be different.


My proposal used heavily pruned merkle tree sections to send individual transactions without trust and had no forking.

You would check a new address really had funds by asking the network for the branches concerning just that address.

Even if the majority of nodes withheld information you would only need one honest node to get the complete picture in a short download.

I developed a theoretical concept for a swarm client, that would likely solve this issue.

Basically blocks are split up into branches so that no clients have to propagate, store nor confirm a full block.

It's over in the development discussions.

He is right it's a bit much, who mines solo these days and how many small pools were created/gained traction in such a short time?

Abandon ship people - abandon ship!


Nah even if its an 51% attack it shouldn't hurt us too much.

Nifty, but why?

Even the oldest BTC client can send and receive BTC as I understand it.

Sure they aren't all safe and they may crash, but we can assume their users to some extent have taken their precautions.

What if the attacker hacks your admin passes/signatures or in another way corrupts the process?


Just not worth the risk to save 2 seconds in the update process (doing it yourself with a mouse click).

Wouldn't work:

1. They would quickly drive up the price to thousands of dollars per BTC and themselves run out of money before getting all the BTC.
2. A single satoshi left could run the world economy with a minor minor update to the client allowing more decimals.

I think he meant an update button was okay, but that you ACTUALLY had to press it yourself and that major updates were a no-go, no matter what.

Really don't like that:

ONE break in or rogue programmer at the dev team HQ and all trust in bitcoin is destroyed + we loose millions.

Thanks, but no thanks.

Might be the recent media blitz/EU fears.

Still I expected collapsing down to 5.4 and some quiet, not 6 point crazy.

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.

True, but ideally I would like BTC to be available to all.

Very true, it would likely be the biggest update to bitcoin ever, but it would also one of the few needed. (scalability has been talked about for a while)

The changes I suggested are mainly in communication and data handling so if there is a bug it should hardly do more than crash that client.

Additionally all the F-nodes would keep going entirely unaffected by S-nodes - no fork and all.

(Also quote was meant towards a slightly different solution model, still good 2112/Matt)

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!