Bitcoin Forum
May 29, 2017, 09:14:23 PM *
News: If the forum does not load normally for you, please send me a traceroute.
 
  Home Help Search Donate Login Register  
  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 ... 566 »
1  Bitcoin / Hardware / MOVED: Starting Mining on: Today at 01:11:53 PM
This topic has been moved to Mining (Altcoins).

https://bitcointalk.org/index.php?topic=1939068.0
2  Bitcoin / Bitcoin Discussion / Re: UASF Activation on: Today at 11:19:05 AM
These two links are helpful.

https://www.weusecoins.com/uasf-guide/
http://www.uasf.co/
3  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: Today at 09:46:21 AM
I can see franky1 posting but I can't see what he's saying since he's the number 1 ignore I have on at the moment. If someone feels his posts are pure trolling (as they normally are), point them out and I'll delete them.
4  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: Today at 09:41:35 AM
For what it's worth, I quite like the combo of 2MB base size and segwit, just not the miners' agreement's alleged planned execution of it. It still only smells of a bargaining tool to me and hopefully that's all it will end up being (see chest thumping.)

[thumps cognition]

What makes you think that 2 MB base + 6 MB witness blocks aren't going to get filled up to the 8MB max very quickly? That's a potential 40GB+ of new blockchain per month, 360GB per year.

Are you stupid? Because it's either me or you that is
Yes I acknowledge how big 8MB blocks would be potentially. Will they fill up immediately? I seriously doubt it will fill immediately but I do see demand for ~2MB of transactions easily in the current climate of transactions and we've already easily outgrown that. So why would I advocate for any more space than segwit alone provides?

A number of things that I'll list off the top of my head (no doubt there's much more I can't think of right now).
- I believe that there is room for more on-chain growth, even if we move micro-transactions off-chain (which I do believe is the answer to scaling to massive sizes.)
- If we assume bitcoin already needs double the space that it currently has based on current transaction volume, it means we should already be aiming for double that again at a minimum, and while segwit provides up to 4MB of transactions, it depends entirely on the type of transactions as to how much extra space will actually be available.  Given the most pessimistic estimate of 1.7MB that means we have already outgrown that capacity.
- Why should we aim for a blockchain that has up to 8MB of transactions per block instead of 1MB and require the extra storage? There's a self fulfilling prophecy there if you want to have more transactions on the chain; if you want to fit twice as many transactions you need to be providing twice as much space.
- Segwit transactions will allow one to throw away the signatures if they desire to ease storage space as an argument in favour of more segwit transactions. Yet there isn't a great deal of difference in concept between this and pruning nodes of classic transactions and blocks; if storage becomes prohibitive then nodes should set to prune which is working here and now very safely with running wallets. Yes we will see more pruned nodes in the future but we have the technology now to allow them to run fully validating nodes without necessarily storing every single block and transaction.
- Storage space and bandwidth has gotten cheaper. I'm not advocating for any planned continuous growth based on any outdated concepts like Moore's law but most of us can easily afford a lot more space and bandwidth now. 1MB has been manageable for a number of years now already. 8MB is much more I agree but again I can't see us suddenly going from 1 to 8MB just by activating the change.
- I am absolutely against the idea of a change of PoW and it has nothing to do with the fact that 95% of the mining is done with my software and I've gotten my place in bitcoin from the mining world. I firmly believe that any disruptive change of the size of a PoW change will cause massive destabilisation of bitcoin and it would take a long time to recover. Additionally any move towards an "asic resistant" algorithm is folly and purely a temporising measure. In the words of the hardware people I have worked with over the years: There is no such thing as an asic resistant algorithm. It's only a matter of time before we end up in exactly the same place we currently are with mining and at the cost of ridiculous instability in the meantime. For the record I have only a single 7TH miner to my name and I mostly use it only for testing since I can't even justify the electricity costs of running it here so it's clearly not because I'd lose my ability to mine. Additionally it would be trivial for me to create a pool for any other mining algorithm too. The reason I mention PoW is mining fees.
- Mining fees - love them or hate them depending on whether you're a miner or a user; if for argument's sake we do not want the network to fork off with a PoW change and fuck off all the miners out there, the reality is that segwit provides a degree of growth in transactions and consequently requires more resources - storage, bandwidth, even if it decreases cpu at verification, and yet does not provide more reward to miners. This is the sticking point that no doubt is pissing off the vast majority of Jihan's cohort. I was happy to sacrifice mining fees temporarily for the growth provided by segwit, though the rest of the mining world was not, but what happens after that?
- With lack of another scaling plan beyond segwit, and in all likelihood a network that will fill that capacity immediately, the only other way to expand transaction space without another technological advancement in scalability is by expanding the base block size.

I've intentionally omitted the quadratic scaling discussion because your argument was about storage space specifically.
5  Bitcoin / Hardware / MOVED: Coin laundry to Bitcoin Farm on: Today at 08:13:37 AM
This topic has been moved to Mining speculation.

https://bitcointalk.org/index.php?topic=1936458.0
6  Bitcoin / Mining / MOVED: How to dualmine ETH+SiaCoin on Mac? on: Today at 08:02:31 AM
This topic has been moved to Mining (Altcoins).

https://bitcointalk.org/index.php?topic=1938809.0
7  Bitcoin / Mining / Re: PoolServerJ maybe without the J. What pool Ops want these days? on: Today at 12:46:55 AM
You're welcome to join the open code here instead of starting another project from scratch unless you don't want to work in c:
https://bitbucket.org/ckolivas/ckpool


Hi Con... Long time no C.
* -ck clubs shads over the head for such a terrible pun
8  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 28, 2017, 11:26:47 PM
Why must you debate semantics in a biased manner? Yes the core block size doesn't change, but with segwit it will fit up to 4x as many segwit transactions...
Because, sadly, semantics matter (especially when it comes to dispelling myths. I don't deny that segwit would produce more transactions per block; however, when the sticking point is more and bigger, what constitutes "bigger" maters. Without that distinction, I fear it becomes sewit, 1 MB continued, and a year or two from now we go through this all over again (except with the claims that "we gave you 'bigger' blocks already" from one side and "see, segwit didn't help anything" from the other). There's no reason that a broad compromise can't lead to a new starting point, rather than something that will put us right where we are now.
For what it's worth, I quite like the combo of 2MB base size and segwit, just not the miners' agreement's alleged planned execution of it. It still only smells of a bargaining tool to me and hopefully that's all it will end up being (see chest thumping.)
9  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.14.1 Released on: May 28, 2017, 11:10:35 PM
Hey guys, I am new and was looking for something for CPU mining.


Why we can't use this new version for mining?
Because bitcoin mining difficulty is so high that CPU mining isn't even guaranteed to solve one block on average before the end of the known universe. We don't want to encourage people to waste time and energy doing something completely futile and furthermore encourage them to create illegal botnets stealing power for something futile (that's usually why people ask about CPU mining.)
10  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 28, 2017, 10:52:53 PM
Segwit comes with a bigger block size...
Yeah, no.
If you have 1 pound of crap in a box, 1/4 of which is dry, and say "I'm only going to weigh how much crap is dry and put it back in the box", you still have 1 pound of crap in a box (even if you pretend to take away that 1/4 pound).
Segwit gives the illusion of "bigger block size" by redefining what "size" is, not by actually adding size. At some point, one would hope you'd stop being a Core fanboy long enough to at least understand what you're a fanboy of.  Roll Eyes
Why must you debate semantics in a biased manner? Yes the core block size doesn't change, but with segwit it will fit up to 4x as many segwit transactions as we can currently fit legacy transactions. Pedantry over defining block size and papering over that fact at the same time is hypocritical. Be pedantic but be consistent.

This endless debate over definitions is a complete waste of time and has been done to death on every other thread already and I'm not interested in yet another fucking discussion regarding why everyone's side is better than everyone else's. Can we stick to the miner agreement for this thread at least and how the fuck we'll come to an agreement? I want to see no fork and both sides mildly satisfied and mildly dissatisfied at the same time if that's what it takes, provided we end up with one good bitcoin blockchain only.

As for the UASF graph showing over 40% support that seemed to be an anomaly and it's back around 11% so it remains unconvincing for now.
11  Bitcoin / Bitcoin Discussion / Re: Bitcoin mining should be profitable now on: May 28, 2017, 10:24:45 PM
Bitcoin mining should be profitable now as

Bitcoin fees are much higher now

Example :
If I am going to buy 10 Gh/s from Hashflare = $1.2 + 0.002 trx fee
but return is not worth to invest
10Gh is a pitiful amount of hashrate and anyone selling you that is selling you effectively nothing for a little bit of money from those who don't understand this. 10GH isn't enough to even register a payout from a pool if you mine there for a year; it will always be below dust limits.
12  Bitcoin / Mining support / Re: I am trying to mine but I can't figure it out :( on: May 28, 2017, 10:20:47 PM
I need a pool still

Please take note:

Here are my comments on this case:
1. Antrouter is for solo mining only and you need to be really really lucky to find a block in solo with it.

2. Two Antminer U3's doesn't offer you that much of hash rate. Your miner rewards are really really small in pooled mining.

The antminer U3s will never produce anything large enough at a pool to even cash out. They will always be below dust limits. You can mine at a pool but don't expect that you'll ever get a payout.
13  Bitcoin / Mining / Re: PoolServerJ maybe without the J. What pool Ops want these days? on: May 28, 2017, 10:16:51 PM
You're welcome to join the open code here instead of starting another project from scratch unless you don't want to work in c:
https://bitbucket.org/ckolivas/ckpool
14  Bitcoin / Mining / Re: solo mining those who found block.. on: May 28, 2017, 09:38:03 PM
It would take the same amount of time to solo a block of 12.5 as it would to mine 12.5 using a pool. But this is "on average".

Yes, but you still need to find a block first. So you need to fight with pool hash power. For time maybe it's 'on average' but hash power seems to be impossible for solo mining.
Strictly speaking Argon2 is right that on average you can earn the same but that's assuming infinite time when realistically the variance makes it not feasible.

What do you mean by "need to fight with pool hash power"? There is no such thing. All miners are unique and not fighting anyone except overall network diff.
15  Bitcoin / Hardware / MOVED: Mining on: May 28, 2017, 02:27:55 PM
This topic has been moved to Mining (Altcoins).

https://bitcointalk.org/index.php?topic=1937564.0
16  Bitcoin / Mining / MOVED: Where TO Buy Bitcoin Miner ? on: May 28, 2017, 01:19:33 PM
This topic has been moved to Mining speculation.

https://bitcointalk.org/index.php?topic=1934858.0
17  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 28, 2017, 10:01:01 AM
I would not sell yourself short. 0.1% is still 1/1000 of the network. Also you have both the history and technical background that makes you very relevant to this discussion.

From what I have read about thus dispute I agree with your bolded analysis above. That offer will almost certainly be rejected but it is still progress.

Honestly I am somewhat optimistic that some general consensus will come from this. It really is in everyone's best interest to reach a compromise. If you love big blocks then 2Mb is insufficient but still a step in the right direction. If you hate big blocks then SegWit a a step in the right direction and 2Mb represent a finite threat with limited fallout.

Thanks. As I said earlier I've already predicted what I believe will be the outcome, it's just how we're going to get there that's left to determine.

The halfway point is core agreeing to their current segwit implementation AND a 2MB base blocksize hard fork that they implement - it's my gut feeling that's what we'll end up with but there needs to be a lot of rhetoric, chest thumping and circle jerking in the interim.
18  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 28, 2017, 08:54:05 AM
Ok I have posted this a few times....


Why can we not merge mine segwit, BU, and whatever else with BTC as it stands now, with the same distribution of coins, and just let the market decide which one has more value,

every one wins!
No matter how many threads you post it on, it still remains nonsense.

Merge mining and forks simply don't work that way. Merged mine coins do so voluntarily on the back of a real coin that has a high degree of compatibility. Segwit and BU would be completely incompatible and obviously neither would want to ride on the back of the other.
19  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: May 28, 2017, 07:11:02 AM
As a first step, let's see if lowering the threshold to 80% is enough for them to consider BIP91. Without clear explanation of all their motivation it's hard to know exactly what they'll agree to. Offering 80% is to see if it's the prohibitively high 95% that is one of the major stumbling blocks to segwit. The fact they've included segwit at 80% in their own proposal makes it a clear match for that part of their conditions. However I'm inclined to believe they only care about their 2MB base size hard fork and are agreeing to segwit only to barter that in and won't agree to just changing the activation percentage. Additionally different pools have different motivations and flexibility - btcc and f2pool have already said yes to 80% but then they were already signalling segwit...

Alas my own pools amount to less than 0.1% of the network hashrate so what I have to say makes no difference to anyone or anything, though there are hundreds of PH now running my pool software...
20  Bitcoin / Mining / MOVED: Request to push one transaction.. on: May 27, 2017, 09:33:12 PM
This topic has been moved to Technical Support.

https://bitcointalk.org/index.php?topic=1936165.0
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 ... 566 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!