One can of beer is good for three dozen tries.

Get a ten six packs next to your computer.

You are fixed up.

That's true within a certain numerical range.

For example if Traffic = 100 and the range is Traffic = 25 up to Traffic = 500.

But it does not work for surge conditions and exponential adoption.

With bitcoin we have literally Traffic = 3/second and Desired Traffic = 25,000/s

Saying things doesn't make them true.

The algorithm for the LN does not look AT ALL like it would lead to more centralization. It looks like the exact opposite of what a banker would like to see.

If this is not true please show how and why.

This is certainly true, however we can use eighth grade math to figure how transaction speed and volume scale with a simple change of block size.

Just pick a desirable range for future volume, and ask how do we get there. Let's take 100x current or 300 transactions per second.

It is not required to test solutions which will fail at 2x or 4x current volume.

With coin control you can pick one or two inputs, instead of having a random group of who knows how many. I think it's still better because you could avoid some dust and manage it's creation.

Assume you have these amounts of BTC in addresses

0.000001
0.0000001
0.00000001
0.1
0.01

You wish to transact 0.15.

The program picks the first four, eliminating some small amounts and leaving after fees maybe 0.0488.

Fees on the first three are in excess of value. With coin control you would select only the fourth number, 0.1 and have the smallest transaction.

Consider it a test, probing for weakness of the BTC algorithm and implementation.

This will not stop. This is only starting.

This thread is on methods of minimizing cost of transaction with bitcoin. Even if other coins are used for low dollar transactions you still move funds btc --> alt coin.

Yes, Bitcoin Core, Electrum, Armory. Many others. But many do not allow it, and do not allow "coin control." The lack of these essential features introduces inefficiency into jacks up your costs.

That's pretty well stated. However, Satoshi certainly did have a vision, and it was of people being freed from the chains of debt based fiat currency.

As for the details involved in navigating to that point, I don't really care if people "believe" one block size or another. It doesn't matter at all what they believe.

These are simple issues of mathematics and database theory. Any questions can be answered with eighth grade math.

I can't make it any clearer than that. No stopgate or temporary solution will work because of the huge variance between normal and surge conditions in the transaction flow.

Don't waste your time.

Claiming?

What part of "increasing block size is not solution" do you not understand?

This is a very good suggestion.

Over time a large number of "change" transactions can add up in a wallet. If the amounts are lower than the corresponding fee, the value is effectively lost. And in the aggregate that's a great deal of money.

But if a person waited until the right moment and then consolidated, that would work. Sort of like waiting for the right tides to push your boat out.

Lightning network can proceed and should proceed ignoring all regulations.

As did bitcoin.

Registering for person to person movement of virtual currency?

Get real.

In a world of cars and freeways, Bitcoin is a two lane country road.

LN is your flying car.

ALL HAIL THE NIGERIAN EMAIL SCAM APPLIED TO BLOCKCHAIN FORK!

No.

But if the amount you send must be "gathered" from six or eight addresses in your wallet, this creates a transaction with many inputs and one or two outputs. It's longer, and the miner fee is based on length of the transaction.

So then it would be a higher fee.

First of all, establish that the size=65643 is actually correct.

Do you know how to do that?

This is a major subject. I am going to consolidate good suggestions back into this first post.

Ways to lower fees.
A) Use wallet that allows coin control and always pick your coins to create smallest size transactions.
B) Use segwit addressing.
C) Don't use wallets that don't allow you to set your fee.
D) If you have several people to send BTC to, generate one transaction with several outputs instead of several separate transactions.

I know these methods work. What secret tricks do you have that you can share?

SFR10
1. Refrain from withdrawing small amounts of BTCitcoin (less dust inputs).
2. Clean the intended address from any dusts left (send everything to another address with minimal fee [not suitable at the moment, due to ongoing network congestion]) then send everything back to the address it came from (or just use the new address, in case different wallets are being used) (you can use accelerators to help speed it up).
- Works best when recommended fee is around 200 satoshis/byte and when network isn't congested.

HAPSHETSUT93
One of the reasons why some people encounter very high fees is fragmentation of UTXO's, which happens when you receive coins very often, and as the result fees for moving the whole balance can be pretty high because of large transaction size. There are two things you can do to avoid it - first, try to send coins to your wallet less frequently - if you are mining or trading, don't withdraw small amounts every day. Second, transaction fees are pretty volatile - sometimes they can be very high for weeks, but in other times they can be less than a dollar. When transaction fees are cheap, use it to consolidate your UTXO's by moving all your coins to a single address.

Mac OS X 10.13.2

Electrum 3.03
Electron Cash 2.9.4
Electrum-LTC

Seem to happily coexist.

That's huge.

I have both on a Mac OS X, and don't have problems. But you are right to think that anything that might go wrong, probably will.

What I suggest is you find a key that had funds (preferably a very low amount) on 8/1/17, then be sure it has no funds today, if it does move them out. Transfer the private key for that key pair into the electron-cash wallet.

Just do one key and get it right.

Then you'll be confident to do some more, right?