Bitcoin Forum
May 13, 2024, 08:37:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 72 »
1  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 09:58:46 PM
That's quite a far flung theory.  One reason highly its unlikely is because Blockstream and core devs want to scale bitcoin in the exact opposite way that Satoshi recommended.
This is wrong in every way.  Payment channels was Satoshi's idea, and it was implemented in Bitcoin 0.1.  Unfortunately it didn't work as well as designed, and was insecure due to bugs.  Some of the problems were fixed in the previous soft fork (BIP 68), and Segwit resolves the remaining bugs.  In addition to that many developers, both core developers and other people, have extended on Satoshi's ideas for payment channels by connecting them in a network.

Look it up.

Btw, Satoshi warned against miner centralization back in 2010.  He asked people not to mine with GPUs, since he had intended to distribute the mining power.  How do you think he would have responded to ASICs and CVE-2017-9230?  By handing more power over to the miners?
2  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 08:04:44 PM
So you want a hard fork to destroy bitcoin and it's dominance, and the other arguments you made were just nonsense?
STAHP. Educate yourself. Don't you know that bitcoin has already hard forked several times in its history?

https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

Bitcoin didn't split in half - there is still only one bitcoin.
This is different for many reasons.

First of all the immediate fix was a soft fork.  They went back to a chain which every node could validate, instead of having two chains.  One which only new nodes could validate, and one which only old nodes could validate correctly.  Then people could either upgrade or increase the maximum locks for BerkleyDB.  Those who didn't would experience random crashes.

The solution was a bugfix.  Non-upgraded nodes would experience random crashes.

This happened a long time ago when Bitcoin still was young and had very few tech-savvy users.  Upgrading all nodes with a non-controversial bugfix or just increase the maximum locks, was easy.

There was absolutely no risk of anyone losing money by getting on the wrong side of a hard fork.  In fact, there never was a hard fork.  No block has ever been produced on what would be the other side of that fork.

When it becomes absolutely necessary to modify the protocol, sane people work together and get it done. Like when the blocks are totally full, and people have been waiting for years to do a trivial blocksize increase...
We already know it doesn't work like that.  For how long has segwit been ready?  It is still not activated.  Even when it fixes several bugs and weaknesses, in addition to increasing the block size.

When even a soft fork which solve many problems in one go, including the full blocks, proves to be too controversial to activate, then imagine what would happen with a controversial hard fork which only partially relieve one of the problems with no long-term solution.

Even if bitcoin DID split into two chains, one would have more hashpower, and would therefore be more valuable than the other, like Ethereum did. Ehrmagerd, it didn't die!
Hashpower does not make a coin valuable.  People do.  If Bitcoin proves to be changeable by a few people in suits just agreeing to handing themselves a few million coins, it will loose it's value very quickly.

Bitcoin dominance is ending because the blocksize is still too small.
Nah, it is mostly due to it's limitations.  Segwit tries to remove many of those limitations, but a small group of people don't want that top happen.  Larger blocks alone would just add another limitation.  Initial block download won't go any faster with larger blocks, unless something is done to make transaction validation scale at the same time.
3  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 05:16:47 PM
If you receive a transaction on your node, and it is confirmed, you will regard it as a good one.  The coin being spent may not exist on the other chain, or there may be another transaction on the other chain spending it differently.  So you will lose coins, and can easily be scammed.
That's not what I'd call "losing coins because you run a node".
Great.  I'll tell pepole who lose their coins that you have chosen a different name for it, so it must be OK.
Again, nobody CAN lose a coin just by running or not running a particular non-mining node.  That's trivially obvious.
Ah, you are making the argument they have to actually use the node to either receive or send transactions?  Yes, that goes without saying.

Quote
Yep, so you will make two coins.  And if you were to do that for every minor improvement, we would have more than 20 different bitcoin blockchains already, and most people, including me, would see it as a failed experiment.
Why ?  After all, each time you make two coins, they are evaluated in the market.  If most users find the improvement much better than the original, they will put all the market cap on the new one, and none on the old.
No.  Since people will lose money from this, and the security of the storage itself since all parameters are subject to change this way, the total market cap will be much lower.  Bitcoin will become one of those altcoins you never know what will happen to.

I am more interested in other properties of bitcoin than the market cap.  It doesn't matter much to me if it loses value.  If it loses the concept of the immutable blockchain rules, it has lost everything to me and become just another shitcoin.  I'll be out, and so will many other people holding large amounts, and small businesses (like mine) which depend on keeping cost and complexity down.

In PoW, the miners follow the market cap (in fact, they follow the block reward in $$ but if the rewards are comparable, the miners follow the market cap).  So if users decide to buy up the new coins, and dump the old ones, the market cap of the old ones goes to 0, and the market cap of the new one takes over all of it.
It is not that easy.  If miners were interested in market cap, then segwit would have been  activated a long time ago.

If the users are divided over the utility of the modification, two coins emerge with comparable market cap, mostly half of what used to be the original coin, which is a good thing too: it means that essentially a useless modification was applied, at least as evaluated by the market.
Yeah, this way you can make loads of shitcoins, and if you think the market wants it it would have happened many times already.

I can recommend bitcoin to people, because I know what it is.  If it stops being bitcoin, and becomes a bunch of shitcoins, I can't do that any more.

I would think the multitude of different coins a good thing ; but actually, one doesn't need to fork off bitcoin to do so, one can also start a chain from scratch.  That is what about 700 or more other crypto currencies have done.   The more the market is varied, the more different coins there are, the better the experiment, and the more fluid the market ; the better the outcome.    Monopolistic markets are a bad thing.  Variation and choice is good in my book.  I think bitcoin has been having a monopoly for far too long a time, and finally, other crypto is being considered somewhat, even though in a crazy speculative game.
What?  The first altcoins started in 2010.  Bitcoin hasn't had any kind of monopoly for as long as the economy around it has existed.

So you want a hard fork to destroy bitcoin and it's dominance, and the other arguments you made were just nonsense?

If there is a strong majority forking away in bitcoin, the slow difficulty adaptation in bitcoin will simply kill the small minority chain: its block rate will be ridiculously small.
Roll Eyes  OK, you obviously don't understand even the most basic properties of bitcoin.  Mining difficulty adjusts automatically every 2016 blocks to make sure the blockrate stay the same, regardless of the hashrate.

Note that you are contradicted that every hard fork needs to lead to two prongs in reality: most regularly hardforking coins like ethereum, DASH, monero, .... are in any case so much centralized on their "Core" dev team, that only in very contentious cases, two prongs emerge, as was the case with the winding-back HF on ethereum.
Those are centrally controlled shitcoins.  I wouldn't touch them with a ten foot pole.  Fortunately Bitcoin is nothing like that.

Quote
Of course, because segwit is a soft fork.  Hard forks don't work that way.  The blocks produced on the other side won't get orphaned.  Both chains will continue as different coins.
Yes.  That's good in my book.
Then just fork off your own coin.

Quote
Yep, and if someone want to do that with bitcoin they are welcome.  Just don't call the new coin "bitcoin", because that will be confusing to everyone, and don't expect anyone to use their new coin.
The funny thing is that a UASF is exactly the same.  You make two coins if the soft fork chain is minority, even though it is a soft fork.  UASF is asking users to only consider a segwit-only chain, and hope that a minority of miners will make a segwit-only chain that those UASF nodes will accept (otherwise, they stop).  But the old majority chain continues of course.  We ALSO have a fork and two coins: don't call the new one "bitcoin" in that case, you might confuse people.
No, it isn't the same.  Since segwit is backwards compatible, the other chain will reorg to the UASF chain if/when the UASF chain become the longest.  If UASF gains traction, those not running the UASF chain will at some point get reorged over to the UASF chain, losing all traces of the chain they used to be on.

However, this kind of fork is extremely dangerous.  Because the majority chain may be orphaned after a month or so if they don't transform it into a bilateral hard fork.
It can be orphaned any time.  Could be an hour, a day, a month or even years.  UASF is clearly the safest side to be on.  About 10% of all bitcoin nodes on the network signal some kind of support for a BIP148 style UASF.  It will be interesting to see how it plays out.
4  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 01:03:34 PM
If you receive a transaction on your node, and it is confirmed, you will regard it as a good one.  The coin being spent may not exist on the other chain, or there may be another transaction on the other chain spending it differently.  So you will lose coins, and can easily be scammed.
That's not what I'd call "losing coins because you run a node".
Great.  I'll tell pepole who lose their coins that you have chosen a different name for it, so it must be OK.

That's evident that if the chains have identical signature schemes, and you didn't do anything to split them, of course a valid transaction on chain A will also be a valid transaction on chain B, the famous "replay attack".  The thing to do, is that ideally, the one forking off should modify something in the signature (hard fork !) so that this is automatically solved (a good signature on one scheme will not be a good signature on the other) ; or you should mix in yourself newly mined dust on one of the two prongs.  Otherwise, it is normal that any signature on one chain will be copied over to the other chain.
Yep, so you will make two coins.  And if you were to do that for every minor improvement, we would have more than 20 different bitcoin blockchains already, and most people, including me, would see it as a failed experiment.

Quote
Quote
If it was simple to change the hard economic consensus parameters, like block size, inflation rate, time between blocks, POW algorithm etc, it would have happened several times already.  It doesn't, because people want bitcoin to be a secure store of value.
It doesn't, simply because of the mechanism of immutability, which, however, can break down if centralization occurs and there's a collusion of more than 50% of the consensus (= hash) power over a change.
> 50% of hashpower can only restrict activity by refusing to mine certain transactions.  They can not change the consensus.  If they produce invalid blocks, the hashpower is worthless.  Nodes will just throw their blocks away.
More than just restrict activity.  ANY soft fork is automatically imposed by a >50% hash rate collusion over the soft fork.  If tomorrow, >50% of miner nodes decide to impose segwit, then segwit will be.  Other miners have no option.  They will get orphaned all the time according to their own rules.  Because all nodes will accept segwit blocks like "legacy nodes", including the non-segwit miners.
Of course, because segwit is a soft fork.  Hard forks don't work that way.  The blocks produced on the other side won't get orphaned.  Both chains will continue as different coins.

A hard fork is a whole different affair: you make two coins, and users happen to possess both of them.  Up to them to use both of them, by running their respective wallets (and eventually, their respective nodes).
Yep, and if someone want to do that with bitcoin they are welcome.  Just don't call the new coin "bitcoin", because that will be confusing to everyone, and don't expect anyone to use their new coin.
5  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 11:45:54 AM
You never lose bitcoins because you run a non-mining node.
This is wrong in so many ways, you obviously have no clue.
Of course not.  Whatever happens on a non-mining node doesn't alter anything on a block chain (apart from sending goofed transactions eventually). 
Dude, I explained several ways.  Don't tell me not just because you don't understand them.

Quote
Secondly, there are several ways of losing coins due to a fork.  Just see the mess that occured when Ethereum split in ETC and ETH.  A chain fork can even be designed to steal coins or reverse transactions, like it was in the Ethereum case.
Forking happens by miners.  And as long as the original chain is one of the prongs, your coins exist of course on the original chain.  You are perfectly right that the ETH fork (by miners !) was done to reverse certain actions by one participant (the "dao hacker"), but he kept his holdings on the original (ETC) chain.
No, miners can't make a hard fork on their own.

Note that the forking is done by people building block chains and in a PoW system, these are mining nodes.  Non-mining nodes cannot alter the block chain, and hence cannot alter any protocol, or any block chain contents ; as such, they cannot "lose coins".  If by running a certain non-mining node, you've "lost coins", you can easily get them back: erase your node, and start another one with the "right" protocol (the one that can read the chain that has your coins out there).
Sorry, you don't make any sense.  Please go back and read how you can lose your coins in a chain split.  There will not be one blockchain, there will be two.  If you e.g. spent your coins in one of the chains, and the receiver copy your transaction in the other chain, you have lost coins in the other chain.  If you receive coins in one chain, the coins may not be valid in the other chain.  In both cases you have lost coins.  Erasing your  node and reinstalling it won't get your coins back.
6  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 11:38:43 AM
The original blocksize was 32mb and the 1mb was temporary anti-spam measure.
Not correct.  No version of bitcoin has been able to handle blocks larger than 1 MB.  When the 1 MB limit was set, bitcoin would still choke on 1 MB blocks.  Miners producing much smaller blocks would win any race, because nodes receiving the 1 MB block would crash.  Large blocks wouldn't propagate to other nodes.

Researchers have figured out that blocks larger than about 4 MB would be unsafe.  This is why segwit is capped at 4 MB.  If it was a way to make bitcoin work just as well with even larger blocks, it would probably have been implemented in segwit.  Fortunately the parameters have been chosen by scientists, not users.

The stubbornness and refusal to raise the limit created a side effect of bad business policy
The limit is a hard blockchain rule, not a business policy.  Splitting bitcoin in two would not only be a bad technical decision, it would be bad for businesses as well.  Especially small businesses like mine.

I do wish people on here studied accountancy like myself, then people would have a better understanding of Bitcoin.
LOL!

Btw, the economic properties of the block size limit become obvious when the txfee rewards are much larger than the block reward, which is going to happen faster with larger blocks.  It will no longer be profitable to build on a new block for a miner.  Instead he will try to steal the fees from the previous block by mining a new block at the same height, at least until the fees from waiting transactions in the mempool are higher than in the last mined block.  Thereby leading to steadily increasing txfees.  This is what miners want, not necessarily what users want.
7  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 11:19:11 AM
These modifications don't seem like difficult to do in 4 months, right ?
Making the modifications is not enough.  You need to upgrade every bitcoin node in the world as well.
Not really.  If you keep your old node running, you copy the the old fork, if sufficient miners go with the old fork to still make some blocks.  If you download the new node, you copy the new fork.  
And lose bitcoin.  How well do you think that will be welcomed by the greater community, and how much would you trust a currency whish did that?
You never lose bitcoins because you run a non-mining node.
This is wrong in so many ways, you obviously have no clue.

First of all I am running a mining node, but that's beside the point.

Secondly, there are several ways of losing coins due to a fork.  Just see the mess that occured when Ethereum split in ETC and ETH.  A chain fork can even be designed to steal coins or reverse transactions, like it was in the Ethereum case.

If you receive a transaction on your node, and it is confirmed, you will regard it as a good one.  The coin being spent may not exist on the other chain, or there may be another transaction on the other chain spending it differently.  So you will lose coins, and can easily be scammed.

The only things that matter is what is recorded on the block chain(s).  Whether your local copy gets fucked up or not doesn't matter.  The only thing you can have as an accident, is that your old software makes a funny transaction that is nevertheless accepted in some way by the miners and put in a chain, but is in a way screwed up that you cannot use its outputs any more.
What?  No.

If my chain is corrupted the, my node will just re-download the blocks with failing hashes, and I will be back on the best valid chain I am on.  

But by running an old node, you never "lose bitcoins".  And if bitcoin forks in two chains, you have your former coins on both of them.
And as soon as you spend them, you may be victim to an attack where someone copy your transaction to the other chain, and receive your coins on both chains.  Unless double-spending protection is in place before the chain splits.  This was not the case with ethereum, and many lost their coins on one of the chains due to this vulnerability.  None of the bit-altcoins address this problem properly in their attempted chain splits, and this is why exchanges won't adopt them, even as altcoins.

Quote
If it was simple to change the hard economic consensus parameters, like block size, inflation rate, time between blocks, POW algorithm etc, it would have happened several times already.  It doesn't, because people want bitcoin to be a secure store of value.
It doesn't, simply because of the mechanism of immutability, which, however, can break down if centralization occurs and there's a collusion of more than 50% of the consensus (= hash) power over a change.
> 50% of hashpower can only restrict activity by refusing to mine certain transactions.  They can not change the consensus.  If they produce invalid blocks, the hashpower is worthless.  Nodes will just throw their blocks away.

But at least I'm happy that you consider block size just as well a hard economic parameter as inflation rate.   I think that the block size limit as an economic parameter, introducing scarcity of transaction room, was a stupid thing to do in bitcoin's design, but so is its inflation rate.  So, bitcoin being designed as a system with a scarce and finite number of coins, I don't see the problem with bitcoin as a system with a finite and scarce number of transactions per unit of time.  I have to say I think the economic model of both is stupid if the idea was to make a currency, but then, that's how bitcoin was designed, and I think that is the way it should live its life.  The economic design looks more like the one for "exclusive famous paintings" which are rare to come by, and difficult to transact, in other words, a kind of highly speculative and not  very liquid asset with high price that is rarely moved, and only to move big amounts of value (not a currency at all, but a "settlement layer for rich guys doing things where fiat cannot go").  
Bitcoin is a settlement layer by design.  No hard fork can change that.

You can use other layers on top of bitcoin for fast and cheap transactions.  One example which dates back to the Satoshi era is payment channels.  Unfortuately they never worked due to malleability.  Segwit fixes this bug, and makes it possible to use payment channels safely.  In the mean time smart people have found out how to connect payment channels in a network, called the lightning network, how to extend the chain with sidechains, etc.  All of them depend on this bug to be fixed.

The block size becomes a very important economic parameter in the future when the reward from txfees is much larger than the block reward.  With large blocks this will happen faster, and we still don't have a solution to the problems which will arise then.

Quote
But in all of this, you don't even need to run a node.  You can just connect your light wallet to one of the miner pool nodes.
Yeah, or just use PayPal if you want to trust a thrid party.  Actually I think PayPal is more trustworthy than the miners.  That's why I chose to run my own nodes.
The point is, you can ask for the books of PayPal, or you can ask for the books of the miners.   That's what you do when you use a full node.  But you cannot change them, and there's only one book out there.  If you think that PayPal has been cheating in the books, you could go to a judge.  If you see that the miners have been cheating, I don't think you can go to a judge.  You can just curse them, and that's it.   If the one book that is out there is not to your likings, what are you going to do about it, apart from shouting, cursing, trying to tell everyone not to use bitcoin because it is a scam ....
Yep, and this is why I would never use Ethereum or any coin where the miners can change the rules.  I would be out before you could blink.  Exchange it for PayPal or something.

Quote
This won't be a problem, since old nodes don't generate segwit addresses.  You can pay him with your segwit coins, and it is secure.
Ah, I didn't know you could go back from a segwit address back to a legacy address.  How can the old node check that transaction, given that he doesn't have the witness data ?
For segwit transactions security would revert to just a little better than SPV.  It is the same as with e.g. P2SH transactions, OP_HODL, etc.  Of course privacy will still be better when you run a full node.

Suppose that I had coins on a legacy address A1.  I transfer them to my new segwit address S1.  Now, Joe, running an old node, has address A2.  Can I transact coins from S1 to A2 ?
But, suppose now that I had coins in S1, and I pay Jack, running a new node, in S2.
I could try to spend S1 to A2, because Joe, with his old node cannot see my transaction from S1 to S2.
Wrong.  Old nodes still see the transactions, and their UTXO set will be updated for all transactions.  Only the witness is segregated.  This is necessary, because transactions spending coins not in the UTXO set are invalid, and blocks containing them would be invalid.

But of course, the *miners* will not accept my transaction from S1 to A2, because that would be a double spend.  In other words, Joe, with his old node, cannot see that I'm doing a double spend, and would cheerfully accept a chain with a spending from S1 to A1 (if this is even possible ?), but he TRUSTS THE MINERS that they won't allow that.
This is just completely misunderstood.  No node, old or new, will accept S1 to A2 when S1 has been spent.  If the old node didn't see the S1 to S2 transaction, and S2 was spent, it would be a hard fork.

What's the point for him to run his old full node, and not a light wallet connected to a miner node ?
Better security and privacy.  The old node will only be useless for mining.

Quote
You may argue that segwit is a cleaner way of doing things, but there is no need to hard fork for it.  In fact it will be very stupid to hard fork for a simple change like that.  P2SH was a much more intrusive change, and it was done by a simple flag day activation.
The point is that if you do a radical change in the protocol, you fork anyhow.  There' s no good reason to keep backward compatibility with software that doesn't understand the new protocol but simply "allows it".  The coin after is not the same coin as the coin before.  The protocol is different.  The only thing that is the same, is the ownership of coins.
Eh, yes.  As long as you don't break any rules, the coin will be the same.  Why the f*** would anyone want to split into two coins for simple upgrades like P2SH, new opcodes like OP_HODL or segwit?  It doesn'ẗ make sense to me at all.  Only a badly designed coin would do that.

Quote
And a clean hard fork would also allow people to "not be tied to backward compatibility".  Many crypto currencies have such a policy.   There's a lot of clumsiness in the requirement of a soft fork that disappears with a hard fork.  For a radical modification like this one, a hard fork is much cleaner.
Use one of the scamcoins, if you want an insecure coin which hardforks all the time.  Don't think you will be able to convince all bitcoin users that would be a good idea, and then you have two coins, disruption and big losses for everyone.
This is what I call religion.  If you talk about "insecure" and "scam coin", that's not rational.
Call it what you want.  You could call it fiat, where uncontrollable inflation, invalidation of money and outright theft flourish.  I use Bitcoin instead, because I can be certain that nothing like this will happen.

Hell, I'm even sure that you can change the inflation rate in bitcoin with a soft fork too.  If you would allow every first transaction from legacy to segwit address to be spent not once, but twice, you'd double in one go, all bitcoin wallets that switch to segwit.  With a segwit soft fork because it is a new protocol that is "invisible" to the old one, so a soft fork.
No, that is not possible.  That would be a hard fork.  Again, you have misunderstood how bitcoin works.

Quote
The whole "leading argument" in this whole business is the irrational belief that non-mining full nodes have any decentralization value, and that old nodes with old node software are important.   Both of these notions are entirely wrong, but they are the fundamental argument on which all of this dispute is based.
Don't try to tell me this is wrong.  I run an exchange.  A small one, about 1 million USD in monthly volume now (times two, if you count buy and sell separately).  Quite often when people sell coins to me, it first takes them ages to sync their old Bitcoin QT node.  There are thousands of old nodes out there, and people who run them.
You could also just run a full node for your customers, and tell them to connect a light wallet to your node.
Or I could just use PayPal.  Seriously, do you really consider this an option?  Why do you use bitcoin at all?
8  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 08:45:20 AM
Core developers were NOT invited.

According to this they were.



But I've no idea who or what to believe any more.
This can easily be verified as fake.  There is no trace of his email on the bitcoin-dev mailing list, where he will reach all bitcoin-developers.  Either he has been sending to a few people who he knew wouldn't be going to the conference, or he made it up.  The only natural address for an invitation like this, is the bitcoin-dev mailing list, where suggestions regarding improvements to bitcoin are discussed and reviewed.
9  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 24, 2017, 08:31:53 AM
I think their refusal to turn up reflects rather poorly on them, though I've no idea how much notice was given. It's starting to look a little like they're more interested in sneering than working towards something everyone's happy enough with.
Core developers were NOT invited.
LOL!  Is this going to be a new bug party, like "BU" and "Classic", with Trump-style "best" programmers and testing?  Haha!  Good lock convincing anyone to run it.  This is only an attempt to fire up more in-fighting and delays.  I hope they fork off quickly, crash and burn and we can forget about them.
10  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 07:05:46 PM
...The Bitcoin Foundation don't employ any bitcoin developers at the moment, afaik...
Because they went broke paying Gavin $200k a year?
It was not the only reason they went broke, of course.  I think he was the last one, yes.  And he was not even hired as developer, because he had mostly quit developing at the time, but as "chief scientist" or something.
11  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 06:52:49 PM
Because SEC filings matter....
Quote
...development is overseen by a core group of developers including those employed by MIT Media Lab’s Digital Currency Initiative and the Bitcoin Foundation (the “Core Developers”)...

For those that have problems keeping up...

...paid by a single employer to do a very specific job...
One of the Bitcoin Core developers work at the MIT Media Lab.  The Bitcoin Foundation don't employ any bitcoin developers at the moment, afaik.  If they do, it must be a very cheap one.   The rest are employed elsewhere, by various companies, own startups etc.  Bitcoin Core is certainly not a company.  It is a very loosely connected group of people who do various amounts of work on bitcoin.
12  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 06:41:44 PM
There are no deals done behind closed doors.

Yeah, quote me out of context like that, and post a funny image, because that make is looks like you are a real grown-up!  Perhaps almost nine years old.

At this level of maturity, it becomes obvious why you don't understand the basics of how bitcoin works.  And how development of free software works.  Please ask your mother to explain it to you.
13  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 04:16:46 PM
...The developers are paid by a lot of different universities and companies, and some are not paid by anyone (e.g. students)...
All "Bitcoin Core" developers are paid and "some [contributors]are not paid by anyone". As I said, this is a significant distinction.
Most people need a day job to pay their bills, yes.

...  Noone get paid by a company called "Bitcoin Core"...
By that logic, the U.S. Marine Corps don't exist, because all Marines are paid by the U.S. Dept. of the Navy.
Those are paid by a single employer to do a very specific job, commanded by one commander in chief.  Try again.
14  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 04:12:59 PM
These modifications don't seem like difficult to do in 4 months, right ?
Making the modifications is not enough.  You need to upgrade every bitcoin node in the world as well.
Not really.  If you keep your old node running, you copy the the old fork, if sufficient miners go with the old fork to still make some blocks.  If you download the new node, you copy the new fork.  
And lose bitcoin.  How well do you think that will be welcomed by the greater community, and how much would you trust a currency whish did that?

If it was simple to change the hard economic consensus parameters, like block size, inflation rate, time between blocks, POW algorithm etc, it would have happened several times already.  It doesn't, because people want bitcoin to be a secure store of value.


But in all of this, you don't even need to run a node.  You can just connect your light wallet to one of the miner pool nodes.
Yeah, or just use PayPal if you want to trust a thrid party.  Actually I think PayPal is more trustworthy than the miners.  That's why I chose to run my own nodes.

Quote
Segwit as it is with 4 MB blocks can be deployed in two weeks, however.  There are still thousands of nodes not supporting segwit, but it doesn't matter.  Those will continue to work just fine, since it is a soft fork.
Of course it matters.  That would be nodes that cannot understand segwit transactions.  Yes, they wouldn't refuse the block chain, but they cannot understand it.  It would see funny transactions, but accepted as "anyone can spend".  If I'd pay a user with a segwit transaction, and his light wallet connects to such an old node, he would not see my transaction arrive.  The user of the old node himself wouldn't understand my transaction if I were to have segwit coins and wanted to pay him.  So this would be a crippled node in any case.
This won't be a problem, since old nodes don't generate segwit addresses.  You can pay him with your segwit coins, and it is secure.  The old node will accept the transactions and see the confirmations come as normal.  (Unconfirmed transactions are insecure, of course.  Unconfirmed transactions have never been secure, no matter how the transaction is created.)

The thing is that segwit is a radical modification of how bitcoin functions.  I'm not saying it is bad (I think it contains some very good ideas).  But it is a radically different way of doing many things.  Essentially, the legacy bitcoin and the segwit bitcoin are two entirely different things. A clean hard fork is much more adequate for this.
You may argue that segwit is a cleaner way of doing things, but there is no need to hard fork for it.  In fact it will be very stupid to hard fork for a simple change like that.  P2SH was a much more intrusive change, and it was done by a simple flag day activation.

And a clean hard fork would also allow people to "not be tied to backward compatibility".  Many crypto currencies have such a policy.   There's a lot of clumsiness in the requirement of a soft fork that disappears with a hard fork.  For a radical modification like this one, a hard fork is much cleaner.
Use one of the scamcoins, if you want an insecure coin which hardforks all the time.  Don't think you will be able to convince all bitcoin users that would be a good idea, and then you have two coins, disruption and big losses for everyone.

The whole "leading argument" in this whole business is the irrational belief that non-mining full nodes have any decentralization value, and that old nodes with old node software are important.   Both of these notions are entirely wrong, but they are the fundamental argument on which all of this dispute is based.
Don't try to tell me this is wrong.  I run an exchange.  A small one, about 1 million USD in monthly volume now (times two, if you count buy and sell separately).  Quite often when people sell coins to me, it first takes them ages to sync their old Bitcoin QT node.  There are thousands of old nodes out there, and people who run them.

My own thinking is that Core wants to push people out of the block chain, and onto the LN, because that's their toy, and they think that LN has not much to offer (probably erroneously !) apart if people are FORCED off the chain.
You should join the mailinglist and spend some time on IRC where decelopment is discussed.  Perhaps it will open your eyes.  This kind of conspiracy thinking is just silly.  First and foremost it is wrong, because "Core" isn't developing LN.  There are several implementations of LN, but none by "Core".  Segwit enable a lot of other technologies as well, and some are just as compelling as LN.  E.g. sidechains.

I think that *this* is the whole origin of this crazy list of arguments, that culminates in the absolute importance to the security of bitcoin of an old piece of software running on an old PC somewhere on a 56Kbit link in some basement somewhere in Africa or so, as excuse for not having to increase the legacy-transaction room on the chain.
You are the first one I've ever seen to make this excuse.  Sure it isn't a straw man?

In as much as "increasing block size to 2 MB" was considered a disaster for our old PC on his 56Kbit link in that basement, visibly increasing witness data to 4 MB was not going to be a problem, because somehow, these witness data were not essential to the security of bitcoin, (you could accept that *someone* *somewhere* had checked them, right ?).  One needed an army of full nodes that were constantly checking the single available chain out there in all of its details (was the argument), but suddenly, that wasn't needed any more for the witness data.
Going from 1 MB to 2 MB was going to kill all full nodes, but going from 1 MB to 4 MB of witness data wasn't a problem.
I don't think you understand how a blockchain works.  You can't go from 1 to 2 MB of block data, because that would make bitcoin split into two blockchains.  While 4 MB is a stretch as well, there has been a lot of research done on that subject.  It suggests that 4 MB is mostly safe, while larger blocks will not be.  The problems are somewhat relieved by the facts that it will be much faster to validate a segwit block, and there are incentives in place to stop the UTXO set growth.
15  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 03:43:57 PM
You're right, it's bad for companies (like Bitcoin Core) to make deals/decisions without asking the community's opinion behind the closed doors.  Cheesy It's almost entertaining to watch you ignore the fact that everything you say applies to the group you seem to be a fanboy of.  Undecided
You obviously don't follow the dev-list and the developer meetings on IRC.  Everything Bitcoin Core does (it is not a company, btw) is suggested by the wider community, discussed among the wider community, thoroughly tested, peer-reviewed, tested and eventually sometimes deployed under more or less full consensus.  Then, if it is a soft fork, 95% of the miner hashrate have to agree as well.  You will never see this kind of childish closed door deals happen with Bitcoin Core.

If Bitcoin Core would try a coup like this one, most of the developers would leave the project, and it would end up in the trash like "Bitcoin XT/Unlimited/Crashic/whatever".  You may say it already happened, when Gavin stopped beeing a developer, and started behaving as a some kind of ruler who wanted to make decisions on his own without any kind of peer-review or discussion.
It's so cute that you actually believe that.
I remember it very well, yes.  Coindesk had an article about it recently.

I never ever experienced a closed door at Bitcoin development.  The developers there welcome any well founded opionions both on the mailinglist, on IRC and on github.  Everything they do is public.  There are no deals done behind closed doors.

Quote from: Investopedia
DEFINITION of 'Company'
An entity formed to engage in a business.
A company need not be profitable, designed for profit, incorporated, or even successful in order to be a company. Because, English.
Setting that aside, not all "Contributors" are "Developers" and this in an important distinction when it comes to the fact that the "Developers" are paid. So, by all definitions, Bitcoin Core is a "company" and the "Developers" (devs) are in charge of, and paid by/for said company. Because, English.
By this definition, Bitcoin Core is not a company.

The developers are paid by a lot of different universities and companies, and some are not paid by anyone (e.g. students).  Noone get paid by a company called "Bitcoin Core".  Many are not paid for the work they do on Bitcoin Core, but the work may be done either on their spare time or as a project where they work.

As for the body of your thinking:
If you were right, a proposal that was slated for 95% and never got 40% would put Core in the direction that this thread wouldn't even exist (as it would be obvious that "the wider community" didn't want it).

Now, I'm sure that someone will try to make that argument that the pools are "in charge" and "the wider community" isn't represented by the wishes of said pools. The only problem with that logic is that "the wider community" has the ability to not mine in such pools.
The wider community don't mine.  Almost all mining is done in China.  Miners are just service providers.  Important service providers, of course, but they depend on the rest of the economy to make any money.  If exchanges and merchants don't accept their blocks, they are gone.  What you see now is essentially a few Chinese service providers on strike.  The rest of the economy, more than 90% of it, want the current proposal.
16  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 02:26:51 PM
These modifications don't seem like difficult to do in 4 months, right ?
Making the modifications is not enough.  You need to upgrade every bitcoin node in the world as well.  And research suggests that blocks larger than 4 MB would be unsafe, so I doubt you will be able to convince 100% of all bitcoin users to "upgrade" to something entirely untested like that, backed only by some secretive backroom dealings.

Segwit as it is with 4 MB blocks can be deployed in two weeks, however.  There are still thousands of nodes not supporting segwit, but it doesn't matter.  Those will continue to work just fine, since it is a soft fork.
17  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 23, 2017, 02:11:49 PM
So it is O.K. for big mining companies to make deals without asking the community's opinion behind the closed doors but it is not O.K. to change the PoW algo prevent these kind of situations.

I didn't sign up for a centralized piece of shit coin and a toy for big companies.

We must drain the swamp.
You're right, it's bad for companies (like Bitcoin Core) to make deals/decisions without asking the community's opinion behind the closed doors.  Cheesy It's almost entertaining to watch you ignore the fact that everything you say applies to the group you seem to be a fanboy of.  Undecided
You obviously don't follow the dev-list and the developer meetings on IRC.  Everything Bitcoin Core does (it is not a company, btw) is suggested by the wider community, discussed among the wider community, thoroughly tested, peer-reviewed, tested and eventually sometimes deployed under more or less full consensus.  Then, if it is a soft fork, 95% of the miner hashrate have to agree as well.  You will never see this kind of childish closed door deals happen with Bitcoin Core.

If Bitcoin Core would try a coup like this one, most of the developers would leave the project, and it would end up in the trash like "Bitcoin XT/Unlimited/Crashic/whatever".  You may say it already happened, when Gavin stopped beeing a developer, and started behaving as a some kind of ruler who wanted to make decisions on his own without any kind of peer-review or discussion.
18  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 22, 2017, 12:14:15 PM
They don't like the 4 MB segwit blocks, but want to shrink them to 2 MB?  What a mess!  Why can't they just go with the current proposal, and cap the blocks at 2 MB?

Babies.
19  Bitcoin / Project Development / Re: [ANN] Bitcoin PoW Upgrade Initiative on: March 19, 2017, 11:04:05 PM
... I think a large enough economic majority will make the current miners come along in a UASF.  The miners have no interest in mining worthless coins after all.
Sturle, I am not an expert cryptocurrency programmer, but on the topic of business I feel qualified to comment: as a KnC exec said during their company's dying swan song, it's unlikely the Chinese mining operations would be able to operate at their margins unless the Chinese miners receive virtually unlimited funding from a state-level entity (e.g. the government of China or perhaps the PBoC).
I doubt that, but it is a different issue.  I don't think we should base an altcoin on a conspiracy theory.

In my view, the best way to remove Bitmain and other tyrants (for a year or two) is to have the full PoW change, rather than having 50% SHA-256 and 50% a new algorithm.
My point is that you can't change the POW in Bitcoin.  You can make a new coin with a different POW, and you can even carry over all the coins fro Bitcoin in a genesis block or whatever, and fix everything else which is wrong in Bitcoin in the same go, but you can't change the POW agorithm.  It is impossible.  It will become a new coin either you want to or not,  It is just as stupid as those scammers who pretend it is possible to increase the blocksize in Bitcoin.  It will become a new coin either you want to or not.

The only way to upgrade the POW while keeping Bitcoin Bitcoin, is to add an extra POW as a soft fork.

I see there are mostly newbies posting in this thread.  Perhaps you should take some time to educate yourself about how bitocoin and blockchains work.
20  Bitcoin / Project Development / Re: [ANN] Bitcoin PoW Upgrade Initiative on: March 19, 2017, 04:37:08 PM
I think a hardfork change is too drastic, and will certainly end in a contentious hard fork.  A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction.  This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs.
Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.
The current miners will still have a huge advantage with the extra-POW soft-fork model, since SHA256 hashing power as well is required to find blocks, so I think a large enough economic majority will make the current miners come along in a UASF.  The miners have no interest in mining worthless coins after all.  They will have to share their power and some of their income with CPU miners, since none of them can operate alone, but will likely still have most of the payout.  It is easier to recruit another CPU miner for peanuts, than getting enough ASIC hashing power to compete at the current difficulty.  The most challenging task here is to find the right balance between first and second POW difficulty, and how to adjust this autonomously in a way compatible with the current difficulty adjustment scheme.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 72 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!