Topic: Deleted (Read 1183 times)

That's not true. There are already merchants that use Bitcoin as an "everyday currency" with processors such as BitPay. For transactions with a value of the price of a fine dinner for 10, or a typical purchase at a book store, it is only necessary to wait until the transaction is accepted by the network -- it doesn't need to be confirmed in a block, as long as it contains a reasonable transaction fee (and the processor will make this determination and front the risk of a double spend).

The problem with using multiple altcoins is that each altcoin has a different price. Altcoins are still just as volatile as Bitcoin, so they do not work like sidechains. Sidechains are kind of like altcoins, but those sidechains don't have their own tokens per se, but rather use ones from altcoins and Bitcoin. Since the transactions on a side chain are tied to the main currency e.g. Bitcoin, then the volatility problem isn't there with respect to Bitcoin. But with altcoins, there is a problem with volatility since the prices of those altcoins tend to change dramatically.

Actually, there's nothing to stop anyone keeping merkle-tree'ed txns that can be linked to the blocks, for proof reasons etc..

it changes bitcoins security model and makes some usecases impossible. not sure if i like it or not. but i certainly dont think that its possible to make such huge change to bitcoin at this point.

For me, only the balances matter..

you would still need all transactions to verify balances so i dont see a benefit in only storing hashes in a block.
how are old transactions distributed?

edit: utxo is enough to verify balances but you dont see how those balances where built.

If you only put the hash of the txns in block a 1MB block could have (roughly) 1,000,000 / 32 = 31250 txns (hashes) in a block. You wouldn't even need to make the blocks bigger. 1MB would be loads. The txns sent out earlier will already be stored at all the nodes, and the delay propagating them doesn't matter anywhere near as much. You only need to have them all together once every 10 mins. (you may lose the last few txns every 10 mins, but most would be there just fine)

I understand that you can run a full node pruned soon.. BUT only after you have downloaded from a non-pruned node. We need it to run without needing non-pruned nodes.

I said I would not comment on that part. I was talking about the 'solution' under your second point. Just because it can be played with, that does not mean that it would have the same level of security/not cause other problems.

Have you not read my post? I'm not saying that one can do it right now. You've calculated 6 (blocks per hour at 1MB) x 24 (hours a day) x 30 (days on average) and have gotten a correct number. However, I have no idea why we are talking about the current amount of traffic when the vital information is the traffic that we're going to have, should a increase happen. Increasing it to 8 megabytes would result in 34.5 GB of downloaded traffic, but what about node owners?

Well, it could be a little while yet.  Wallet software and GUIs will need to be updated to support it first.  I'm still a little fuzzy on how the matchmaking actually works between buy and sell orders over different chains, but it's definitely possible because ACCT has already been successfully accomplished between two altcoins.  Would be nice if it's ready this year, but early-to-mid 2016 seems more likely.  Speculators should definitely be looking at altcoins which are ready to support it.

Eh.. Gonna have to disagree with you here.

What about my understanding of sidechains are you saying is wrong ?

Propogation can be 'played with'. That's why I mention only putting the hash of txns in the blocks. They will already have been sent through the network beforehand anyway. There are other techniques also.

As for the pruning - You CANNOT run a full pruned node without first downloading from a non-pruned node. This is what I am saying..  We should all be running in this new pruned mode.

The WHOLE of bitcoin can fit into 2 GB of disk space and 4.3GB of network traffic a month (at current block size). That's childs play.

I have to agree with point 1, and I won't comment on point two. The rest what you wrote implies that you have a limited understanding of the underlying problem of big blocks (exact number is debatable; problem exists even at 1MB). You should be able to run a full (pruned) node pretty soon (possibly in the next version unless they have delayed it). This makes it easier for node owners and helps more people run nodes indeed. However, this does nothing to help the current 'problem' that we are facing. It seems to me that people who have not studied IT/engineering/etc. have a hard time understanding propagation delay. Storage is not so much of a problem as are orphan rates and propagation delay.

There is no silver bullet..

1) LN only works when you transact with someone more than once. AND you have to lock up all the funds you might wish to use before hand. It's cool but certainly not as nice as just using btc straight up. My weekly poker group will love it though.. 

2) Sidechains do not get the security of the main chain.. They have to run on whatever the side chain dictates. POS / POW / Delegated etc . That's how the exchanges are currently using their sidechain from blockstream (fully delegated). So unless you want to use a new POW / less secure / not-decentralized / POS variant / DPOS etc etc side chains are also not a 1to1 alternative to using btc straight up. Obviously the 2 way peg is nice, but as DooMAD has already mentioned we are about to see full atomic cross chain transfers between BTC to alt coins very soon (which will be JUST AS SECURE as a sidechain and trustless to boot) so that's not something overly special either..

There is only 1 solution I can think of..

We need to 'prune' bitcoin properly. Then running a full node will be something you can easily do on your phone. Seriously.

Mentioned it here, https://bitcointalksearch.org/topic/m.13119659


Then this whole 'big block' issue will become a non-issue. And we can all keep using Bitcoin the way we want to use it. Directly.
 

In this altcoins scenario you basically have to constantly pay exchange fees to the cenralized exchanges - pretty bad and ineffecient idea. As others said, sidechains at least solve these unnecesary exchange fees.

So I pretty much doubt your altcoins scenario is economically possible, I mean in the long run the more effective solution most of the time wins, so people will choose not to pay the exchange fees if there are cheaper solutions.

That's pretty much the same thing which confirms my initial point. People are too paranoid that they'd even completely turn their backs to the people who have helped Bitcoin survive for such a period of time (security flaws not available to the public).

Mandatory by the user? Not necessarily. If someone wants to help everyone they're going to pay the initial fee (if its that is their business model) and the users would essentially not have to worry about it.

Yes they do. You're missing the vital piece of information that I've provided. Sidechains are not the proposed solution to the "block size problem".

What corporation? Sidechains is open-source code.

Sidechains are effectively altcoins. Not in the sense that we're accustomed with but their respective units are definitely not bitcoins. It's semantics but the distinction needs to be made.

What's interesting and new is they can be cryptographically pegged to Bitcoin and exchangeable back and forth natively from the protocol.

Still waiting for Antpool and a few others to update so the softfork for BIP65 can reach activation and OP_CHECKLOCKTIMEVERIFY can be used.  Once that's done and a few clever coders update some wallet software, you'll be able to trade/convert directly from one blockchain to another without using a third party.  There's definitely a role for altcoins to play in future.

I think your core premise is flawed.

It seems to me that most in the community want Bitcoin to be a good form of money - and a good form of money is BOTH widely accepted / fungible / divisible / easily transferable ("everyday currency" features) AND durable / price-stable ("good store of wealth" features).

The two general quality sets are not mutually exclusive and a refined Bitcoin implementation can arguably do both with no need for running two blockchains.

I also think that you're confusing the investment function with the monetary function - which is to be a store of value / accumulated wealth.  The investment function is not about storing wealth.  You invest to increase wealth, and you take risk to do that.  The whole point of investment is taking risk and thereby capturing the return which is commensurate with the level of risk that you're taking.  If you simply want to store your wealth (accumulated value / excess productivity) then you don't actually want to take risk, you want stability of value.

Most current forms of "money" are poor stores of wealth because they have a near-zero marginal cost of production and will therefore be produced until they have no value - which is to say that they only become price-stable at near zero.  The point of central banking is to control that production via cartelization, but ultimately central banks can only really delay the endgame of the market value of the currency declining to its marginal cost of production.

Bitcoin potentially solves the "store of wealth" problem by having a significant marginal cost of production built into its protocol.  And if it can manage to become widely accepted then its volatility (risk) will decline substantially and it will cease to be a good/bad speculative investment vehicle leaving the door open for it to become a very good store of value.  The issue remains as to how it can solve its own "everyday currency" problems (in the specific BP101 case - easy transfer-ability) and that's what the current debate over block size is about.  Folks have different opinions about how transfer-ability might be threatened by either:

1. Large block sizes and the bandwith required to process them (and how that effects decentralization which might potentially effect transfer-ability) and...
2. The ability of the current protocol and fee structure to manage a large overflow of unconfirmed transactions in the Mem Pools of the various network servers.

Personally I have some non-trivial concerns about 1 and absolutely no faith in 2 so kicking the can down the road by increasing block size A LITTLE while the community develops a better long-term solution makes sense to me.  The problem with XT is that it increases the block size a LOT (thereby substantially increasing the risk of issue 1) and does nothing to solve the bandwidth/decentralization problem that will (hopefully) eventually affect XT as well.  It would seem that the proponents of XT either believe that cheaply available bandwidth will outpace the growth of Bitcoin over the intermediate term or that they don't really share the same concerns about centralization of payment processing that I and a lot of the community do.  

>

If you want to call them altcoins then go ahead, I won't be stopping you. Sidechains are not the same as altcoins even though they seem similar. If you can't comprehend how the two way peg could work then I can see the reason why. You've made a thread about sidechains a few months back, have you learned nothing from it? If we are going to pick a solution between altcoins and sidechains  then it is pretty much obvious which one is better. Sidechains can provide every benefit that altcoins have and decrease the risk that comes with them (scams, premine, viruses, devaluation, etc.).

---

---

However, my post was not about sidechains only. Sidechains are not the proposed solution (Luke-jr said on IRC), so people need to stop thinking badly of Core developers because they are involved in a Company. I'm not even sure what particular benefit made you think that altcoins are good? Anything that they have, can be implemented in Bitcoin. If you think that, explaining what Bitcoin is and how to use it is complicated now, good luck telling someone that they need to use 20 coins. We should be trying to make the system as simple as possible, not the other way around.

Your division with Camp1 and Camp2 is a bit simplistic, but it's a quite true that the solution already exists. Nobody expects anyone to pull a rabbit out of a hat. The different solutions are all well known and well debated. The only question is which one will win.