Bitcoin Forum
May 08, 2024, 02:17:51 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 ... 195 »
1  Bitcoin / Electrum / Re: Monetization Idea for Electrum on: January 04, 2017, 11:49:20 AM
Electrum simply is the best wallet out there.
2  Local / Petites annonces / Re: Achat Bitcoin sur Paris en espèces on: May 19, 2015, 10:15:54 AM
Ben oui, tu risques pas d'acheter à un cours imaginaire.
Et par définition, le cours auquel tu achètes devient le cours du marché.
3  Bitcoin / Bitcoin Discussion / Re: Block chain size/storage and slow downloads for new users on: March 24, 2015, 04:53:19 PM
while the small guys can just leech the blockchain history from them.

For free obviously.
4  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 09:51:04 PM
What you are missing it that if the fork is actually made, blocks compatible with the 20 MB fork only will come after 75% of the nodes have announced themselves that they will be ready for the fork. So, either this happens and it's more profitable to mine on the 20 MB chain, or this doesn't happen and nobody will be mining on the 20 MB chain.

First of all, the prices can start diverging before the fork actually happens. The economic resolution will probably not need an actual fork to happen.

In addition to that, even if only 25% of miners remain on bitcoin at first, there will still be one block every 40 minutes, and one block every 13 minutes and 20 seconds on the 75% chain which seems more than enough to get some trading going on.

Now, in addition to this, you could perfectly imagine that some miners decided to broadcast v4-tagged blocks before the fork, for the sole purpose of inflating the gavincoin/bitcoin rate, with no intention of actually honoring the hard-fork. By doing this they would lead unsuspecting bagholders to sell more bitcoin for gavincoin than they would have otherwise. If this happens, god help you, you'll think you'll have 75% of the miner support, but when the hard fork comes you'll find all this hashrate disappearing from under your feet and supporting the other chain...

"We heard you like market manipulation, so we put some market manipulation in your market manipulation..."
5  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 05:33:08 PM
Thanks for explaining!   Wink

No probs!
6  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 05:03:02 PM
Why not ?

Why would I obstruct development efforts that I believe would harm Bitcoin in the long run and invest resources for another fork to win if I wanted to Short?  

Which brings us back a few posts...  to me...  the said contracts would make sense only if I believed that these large businesses pushing for the increase would end back on the 1 MB chain.

...still might be missing something though...

Let's assume the prices of bitcoin and gavincoin diverge because of the shorting and that you can sell one bitcoin for two gavincoins.

If you support the original bitcoin you'll mine on the original chain.

Now if you think gavincoin will prevail, it's still more profitable to mine on the original chain, because whatever you mine, it will ultimately yield two gavincoins for every original bitcoin you mine.

And obviously, by doing so you're strengthening bitcoin at the expense of gavincoin. The value of a coin attracts mining, which in turns increases the value of this coin against the other.
7  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 04:20:42 PM
not sure if the thought process behind the said shorting contracts make sense though.

Why not ?
8  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 03:58:57 PM
So...  the If not stands?   Undecided

Some people, I am among them, are of the opinion that this fork is unneeded, "solves" a problem that does not exist, and has the potential to harm Bitcoin in the long run.
9  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 03:01:37 PM
There is no "three-to-one" margin.  You don't get to claim agnostic/DGAF as votes to affirm your silly fork, which actually only enjoys 60% support against the negative/status quo default presumption.

His math is correct though, if you have 60% X and 20% Y then you have a 3-to-1 ratio
10  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 02:34:23 PM
Are you this annoying in person, or just online?

We met IRL in 2011, you have all the data to figure this one out :-)


I spent last week talking to some of the largest Bitcoin businesses (much bigger than Paymium/Bitcoin-Central or anything anybody in #bitcoin-assets is involved with), and they all want the maximum block size to increase.

And how's convincing core devs going? Any luck convincing anyone else than Hearn?


The poll in this thread says people support it by a three-to-one margin.

That's irrelevant, travel to Greece, ask around if the ECB should print more Euros.
Just because a lot of people think X doesn't make X correct.


It is going to happen sooner or later.

No probs, the faster you publish your altcoin's specs, the faster we'll be able to draft contracts allowing the market to short it into the ground.


I want it to happen sooner because Very Bad Things will happen if we get to 100% full 1MB blocks:

I don't think it's such a bad thing if frivolous transactions are discouraged from being burdened onto every full node's hard-drive.


being an annoying troll

I disagree with you, so I'm a troll... Is gmaxwell also a troll?

Quote
gmaxwell → gavinandresen: First stop pretending that there actually is consensus or that this is easy and safe. We couldn't even manage to get BIP34 right without two somewhat ugly unexpected effects (we burned the most significant bit of the block version number; and the switchover criteria we implemented wasn't actually the criteria described in the BIP)


I have a TODO list you could help out with. Although the last time you agreed to help out, Dave, you didn't follow through on your promises (do you remember when you agreed to help with the testnet?).

Am I missing something?
11  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 01:48:41 PM
You're using wumpus' comments to defend your view and I'm asking if there's anything else posted by wumpus to explain those comments.  I want to see his reasoning as to why blocks should be full.  Your reading skills need fixing.

Not really, AFAIK he didn't post anything.
If you want to hear his stance why don't you just hop on IRC and ask him directly?
12  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 01:43:11 PM
Don't back down, R2D221, you're absolutely right.  Davout said himself that he thinks bitcoin is "perfect as it is and doesn't need fixing", so he can't then turn around and say he's not supporting a permanent 1mb block.  It's not your fault he's a weasel and openly contradicts himself.

I said "it doesn't need fixing".
I didn't say "it'll never need fixing".

Your reading skills, they do need fixing.
13  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 01:36:35 PM
Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.

So there's no reasoning or justification?  Just an opinion?  Thought as much.

Looks like you missed it the first time it was posted: http://fr.anco.is/2015/gavineries/


You still can't give an answer that doesn't amount to "it works for me, so to hell with everyone else":

Does Bitcoin not work for you?


And you have the nerve to talk about bias?  If you can't or won't consider the consequences of a 1mb limit to the majority of users, you don't get to lecture about bias.  Again, users aren't going to support a network that doesn't confirm their transactions in a timely and secure fashion.  Full blocks means either wait for an available block, or go off chain and introduce risk.

Most users don't really care, they'll transact off-chain if it's more convenient. Users that have enough money that justifies taking the paranoid road will always have either enough money to cover the fees, or wait for some space in a block.


Also, I like how you left Mike Hearn's reply out of your earlier post

That's why intellectually honest people give you the sources of their quotes, so you can research relevant context if so inclined.
The reason I didn't quote Hearn is that the point he makes is pretty retarded. Bitcoin won't crash and burn because mempools increase, it's trivial for miners to drop transactions they don't care about, and merchants should not rely on 0-confs anyway.

Also allow me to highlight some interesting bit in Hearn's post:

Quote
If some people say "no it's too risky" and then there are problems, they look prescient and wise and can easily have a told-you-so attitude. And unfortunately then the people who were trying to improve things can easily lose influence and things grind to a halt.

This is a fucking *feature*, if someone pushes for a change, despite being told that it's risky by intelligent people, and fuck up, of fucking course they should lose influence. What would the alternative be? "O, you broke this system despite being told your idea was stupid, please have some more influence" ?

14  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 12:48:18 PM
If wumpus thinks blocks should be full, then I'd like to see his reasoning.  Gavin has outlined his stance with his blocksize economics and scalability roadmap posts.  A continuous stream of full blocks isn't something we've tried before and we need to see a really convincing argument to justify attempting it.

Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.


So far no one has given me a satisfactory response to this:

If the userbase increases and blocks are full, the choices are as follows:

  • Pay an average fee and still wait for the next available block that isn't full (which will take longer and longer as more users join, even if you pay a fee)
  • Pay an above-average fee and hope that it's more than everyone else is paying (and if you don't guess correctly, wait for the next block)
  • Go off chain and hope that whoever you trusted doesn't run off with the coins
  • Use another coin

Maybe if you actually phrased it like a question it'd be easier to answer.
And it would certainly be easier for the one who answers to show that the assumptions the question is based on, are flawed.
15  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 11:15:34 AM
There have been other threads that resolved this long ago.

Could you please quote other core devs saying they OK this ?

Here is mine :

Quote
sipa → i'm generally in favor of a larger blocksize, but only under the condition that there is a proposal that has extremely wide consensus

wumpus → I'm still not convinced we require a larger blocksize yet

Luke-Jr → wumpus: we definitely don't yet - but it's probably something to be thinking about

gavinandresen → wumpus: how full do blocks need to be before you think we need a hardfork?

wumpus → gavinandresen: all of them full, and a backlog of serious (not spammy) transactions

gmaxwell → gavinandresen: First stop pretending that there actually is consensus or that this is easy and safe. We couldn't even manage to get BIP34 right without two somewhat ugly unexpected effects (we burned the most significant bit of the block version number; and the switchover criteria we implemented wasn't actually the criteria described in the BIP)

Source.
16  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: March 17, 2015, 11:05:24 AM
I have not read through the full tread but is there a summary of the core developer's positions on this matter?

Gavin Andresen and Mike Hearn are sold, others are like 'meh'.
17  Bitcoin / Bitcoin Discussion / Re: Bitcoin 1400MB Fork on: March 17, 2015, 11:05:02 AM
check out lightning payment channels and it will make sense.  It allows you to have every global transaction on a 3mb isp. Tips too.. That's not big like you claim.

To date, lightning is vaporware, let's see when it's actually rolled-out.


That will be so cool to have a full node on a basic internet package. Looks like they got the problem solved. /thread

Why do you speak in the future tense, Bitcoin already works fine on a basic internet package.
18  Bitcoin / Bitcoin Discussion / Re: Bitcoin 1400MB Fork on: March 17, 2015, 09:30:55 AM
Micro-channels are also for single payments. Tipping is also recurring. You are simply biased as to their direction. Think of tipping like leaving money on the table. You have to trust that the busboy doesn't swipe it before the server. Pushing settlements forward reduces mining fees and the occasional small single tip is made up in micro-channel fees.

That doesn't make much sense...
But hey, if you feel like avoiding answering the question of what the trade-off of a bigger chain is, I can't really force you.
19  Bitcoin / Bitcoin Discussion / Re: Bitcoin 1400MB Fork on: March 17, 2015, 09:02:18 AM
Everything is a trade-off.

Sure, so what's the trade-off for allowing micropayments and reddit's tipping on the primary chain?
Bitcoin is ideal for that if you use payment channels. I'm not sure why they aren't doing that right now.

Because micro-channels are only for recurring micro-payments that can be aggregated to a bigger one later. It's a small subset of micro-payments, certainly not the general case.

Now if you'd please answer the original question.
20  Bitcoin / Bitcoin Discussion / Re: Bitcoin 1400MB Fork on: March 17, 2015, 08:45:29 AM
Everything is a trade-off.

Sure, so what's the trade-off for allowing micropayments and reddit's tipping on the primary chain?
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 ... 195 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!