Do I _support_ BU? Hmm... I don't so much _support_ BU, but I do _run_ BU. As far as I know, BU is the only somewhat mainstream choice of client that allows for maxblocksize to be a changing quantity subject to majority acclamation.
Well, yeah - wait - on the basis of that criteria, I damn double do support BU.
We all know it has had some implementation challenges - no need to pussyfoot around that. But the overall goals of BU are Bitcoin as I -- and, as I think Satoshi -- envisioned it.
Bitcoin needs to get out from under the forces trying to suffocate it with a pillow in its crib. Today, BU the the clear solution. There are others in development that fulfill the same vision. Bitcoin will in the end be liberated.
Topic: So do you still support BU? (Read 2048 times)
This proves again that the real motive is always money. The pools started supporting BU because they hoped to gain more cash from it. They didn't do it to support the network or to make it easier for everyone to use Bitcoin, and as Roger Ver proved by not taking the bet, they don't believe in what they're preaching. It's just a means to get richer.
Actual life is motivated by money. Everyone wants to have lots of money and want to make money in any way. Over time the currency may change, the former is now the money is money and then we earn money by bitcoin.
Bitcoin Unlimited or Bitcoin SegWit etc. They are all nothing but a transition process. I mean, both of them not final anything for bitcoin.
More radical solutions are needed for the long term.
More radical solutions are needed for the long term.
I don't support bitcoin unlimited because i think it will be like the ethereum classic which will stay down below the market and the king will still be the bitcoin and i think even though BU attracts some people it is not enough to defeat the huge bitcoin community because it will take time for them to do that and gather enough people to dominate the market.
I do not like bu coin for any reason!
miner using asicboost or planning to, see SegWit like a lost of $100M earning / year.. Enought to pay a lot of propaganda trying to fork BTC otherwise than with SegWit..
IMHO, SegWit is the way to go for now, BU is incentived by a lot of propaganda, motivated by prifit over BTC survival.
I bet in each thread where those subject are written about, there is at least few paid user/troll to demonize SegWit and promote BU.
Do you know about moderators and cencorship here and in reddit ? <-- this may make my post disapear
IMHO, SegWit is the way to go for now, BU is incentived by a lot of propaganda, motivated by prifit over BTC survival.
I bet in each thread where those subject are written about, there is at least few paid user/troll to demonize SegWit and promote BU.
Do you know about moderators and cencorship here and in reddit ? <-- this may make my post disapear
Moderators seem to be taking a neutral viewpoint in this forum subsection.
Don't forget, there is propaganda going on in both sides. Core -> Blockstream -> DCG -> +funding from financial sector actors means the core propaganda machine is well funded. DCG owns some bitcoin new sites. So what you have said, the reverse could also be claimed. According to Forbes, one of DCG's investors is Mastercard. Why? Is it not a well known corporate tactic to buy out the competition and shut it down? Are they wanting to take a stake in BTC's success, or would they be happy to see it destroyed? I don't know what Mastercard's true intentions are.
Mining is now an industrial activity. These people tend to plan over long life cycles, so are incentivised by long term gains, not short term profits. It takes a long time to design, manufacture and deploy the next generation ASIC.
In the end, read the BTC white paper and decide whether you agree with its vision or not. If not, create an altcoin - it will be more successful than BTC if it is a better vision. You have to consider who is trying to change BTC's original design, and what tactics are being used to attempt to do this.
miner using asicboost or planning to, see SegWit like a lost of $100M earning / year.. Enought to pay a lot of propaganda trying to fork BTC otherwise than with SegWit..
IMHO, SegWit is the way to go for now, BU is incentived by a lot of propaganda, motivated by prifit over BTC survival.
I bet in each thread where those subject are written about, there is at least few paid user/troll to demonize SegWit and promote BU.
Do you know about moderators and cencorship here and in reddit ? <-- this may make my post disapear
IMHO, SegWit is the way to go for now, BU is incentived by a lot of propaganda, motivated by prifit over BTC survival.
I bet in each thread where those subject are written about, there is at least few paid user/troll to demonize SegWit and promote BU.
Do you know about moderators and cencorship here and in reddit ? <-- this may make my post disapear
I think we just need more time. Larger blocks are inevitable.
Most importantly, miners need to understand their role as stewards of the network; right now they don't fully recognize their own strength.
To get here, I think we need:
1. The community to realize that the critical aspects of Bitcoin have already been invented (by Satoshi Nakamoto). Developers today are protocol maintainers, and they are replaceable. The model where "wise developers" liaise between miners and businesses is coming to an end--businesses will soon directly talk to miners, and the power developers presently have will be diminished.
2. Node operators to understand that they can configure their nodes to accept blocks larger than 1 MB today. For some reason, a larger fraction of the community still thinks that the transition to larger blocks needs to be highly synchronized and that everyone needs to change their block size limits together. They don't realize that already over 10% of the network nodes would accept blocks larger than 1 MB if a miner produced them.
Here's a talk I gave at Coinbase recently that relates to this discussion: https://www.youtube.com/watch?v=pWnFDocAmfg
Most importantly, miners need to understand their role as stewards of the network; right now they don't fully recognize their own strength.
To get here, I think we need:
1. The community to realize that the critical aspects of Bitcoin have already been invented (by Satoshi Nakamoto). Developers today are protocol maintainers, and they are replaceable. The model where "wise developers" liaise between miners and businesses is coming to an end--businesses will soon directly talk to miners, and the power developers presently have will be diminished.
2. Node operators to understand that they can configure their nodes to accept blocks larger than 1 MB today. For some reason, a larger fraction of the community still thinks that the transition to larger blocks needs to be highly synchronized and that everyone needs to change their block size limits together. They don't realize that already over 10% of the network nodes would accept blocks larger than 1 MB if a miner produced them.
Here's a talk I gave at Coinbase recently that relates to this discussion: https://www.youtube.com/watch?v=pWnFDocAmfg
Development / protocol maintenance needs to be funded. I think that funding should come from within the bitcoin economy itself, rather than from outside economic actors. That means miners, exchanges, bitcoin payment providers, online wallet services, mixers, etc have a role to play in sustaining that development across multiple node implementations. If the funding is diverse, that should limit the influence of one particular actor. I suppose that is what a DAO is for!
I have no problem with with giving the programmers a percentage per block. But the off chain will siphon a lot of money from miners. And the risk is just to high for miners. It takes 13 months just to break even with one s9.
After the Bitmain's ASICBOOST exploit that Jihan Wu used to get an additional 30% (more or less) efficiency for his mining hardware, and the real reason behind Bitmain's attempts to block implementing SegWit has been exposed, do you still support BU after all? If so, why?
I never supported BU but at the same time I am all for making bitcoin flawless.So any changes that can better btc without compromising on its originality is most welcomed by me. legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
wasnt that the idea of the Bitcoin foundation?
People loved to bitch and moan about them....but they were 100x better than Blockstream.
People loved to bitch and moan about them....but they were 100x better than Blockstream.
I think we just need more time. Larger blocks are inevitable.
Most importantly, miners need to understand their role as stewards of the network; right now they don't fully recognize their own strength.
To get here, I think we need:
1. The community to realize that the critical aspects of Bitcoin have already been invented (by Satoshi Nakamoto). Developers today are protocol maintainers, and they are replaceable. The model where "wise developers" liaise between miners and businesses is coming to an end--businesses will soon directly talk to miners, and the power developers presently have will be diminished.
2. Node operators to understand that they can configure their nodes to accept blocks larger than 1 MB today. For some reason, a larger fraction of the community still thinks that the transition to larger blocks needs to be highly synchronized and that everyone needs to change their block size limits together. They don't realize that already over 10% of the network nodes would accept blocks larger than 1 MB if a miner produced them.
Here's a talk I gave at Coinbase recently that relates to this discussion: https://www.youtube.com/watch?v=pWnFDocAmfg
Most importantly, miners need to understand their role as stewards of the network; right now they don't fully recognize their own strength.
To get here, I think we need:
1. The community to realize that the critical aspects of Bitcoin have already been invented (by Satoshi Nakamoto). Developers today are protocol maintainers, and they are replaceable. The model where "wise developers" liaise between miners and businesses is coming to an end--businesses will soon directly talk to miners, and the power developers presently have will be diminished.
2. Node operators to understand that they can configure their nodes to accept blocks larger than 1 MB today. For some reason, a larger fraction of the community still thinks that the transition to larger blocks needs to be highly synchronized and that everyone needs to change their block size limits together. They don't realize that already over 10% of the network nodes would accept blocks larger than 1 MB if a miner produced them.
Here's a talk I gave at Coinbase recently that relates to this discussion: https://www.youtube.com/watch?v=pWnFDocAmfg
Development / protocol maintenance needs to be funded. I think that funding should come from within the bitcoin economy itself, rather than from outside economic actors. That means miners, exchanges, bitcoin payment providers, online wallet services, mixers, etc have a role to play in sustaining that development across multiple node implementations. If the funding is diverse, that should limit the influence of one particular actor. I suppose that is what a DAO is for!
hi Peter
what is the best strategy to get bigger blocks in your opinion, now that miner support seems to be (at the moment) stagnating for BU?
What do you think about extension blocks?
what is the best strategy to get bigger blocks in your opinion, now that miner support seems to be (at the moment) stagnating for BU?
What do you think about extension blocks?
I think we just need more time. Larger blocks are inevitable.
Most importantly, miners need to understand their role as stewards of the network; right now they don't fully recognize their own strength.
To get here, I think we need:
1. The community to realize that the critical aspects of Bitcoin have already been invented (by Satoshi Nakamoto). Developers today are protocol maintainers, and they are replaceable. The model where "wise developers" liaise between miners and businesses is coming to an end--businesses will soon directly talk to miners, and the power developers presently have will be diminished.
2. Node operators to understand that they can configure their nodes to accept blocks larger than 1 MB today. For some reason, a larger fraction of the community still thinks that the transition to larger blocks needs to be highly synchronized and that everyone needs to change their block size limits together. They don't realize that already over 10% of the network nodes would accept blocks larger than 1 MB if a miner produced them.
Here's a talk I gave at Coinbase recently that relates to this discussion: https://www.youtube.com/watch?v=pWnFDocAmfg
Why not have a problem with cores ulterior motives. They want to make a lot of money off chain for them selves.
blockstream, not core, though of course they're interrelated to an extent.
as long they remain demonstrably committed to maintaining bitcoin's integrity then i'll approve of them, not that my approval counts for anything.
Remain? Lol.. I see. So it's ok for the programmers to become centralized and make a ton of money. Brilliant.
Thanks. Any plans to add the mempool saving feature in BU? I had a quick look at the open issues / pull requests and couldn't see one.
I'm not sure; thezerg would know. It sounds like a good feature that aligns with our vision, so I'd assume we would.
We're always looking for people to port over things like this, if you're interested!
Okay, I've opened issues for BU, classic and XT for this feature, with a suggestion on how I would approach it.
Quote
Bitcoin core 0.14 has a mempool saving feature that saves the mempool states between restarts. This is a very useful feature for people who multiboot between O/S's. (and also in the event of a system crash for miners.) I think this would be useful to add to BU.
I am not familiar with this part of the code, but I would look to implement the transaction pool in a virtual memory segment using mmap(), msync(), munmap() if possible. This would mean that all transactions are immediately loaded into virtual memory on start up when the memory segment is mapped onto.
I am not familiar with this part of the code, but I would look to implement the transaction pool in a virtual memory segment using mmap(), msync(), munmap() if possible. This would mean that all transactions are immediately loaded into virtual memory on start up when the memory segment is mapped onto.
I'm not sure if 0.14 uses the mmap() method for this, it is used somewhere in the code. Long time since I've used C++ and I'm not that familiar with the std libraries or the core code, so not sure if I would be able to have a crack at it myself at this moment in time.
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
Thanks. Any plans to add the mempool saving feature in BU? I had a quick look at the open issues / pull requests and couldn't see one.
I'm not sure; thezerg would know. It sounds like a good feature that aligns with our vision, so I'd assume we would.
We're always looking for people to port over things like this, if you're interested!
hi Peter
what is the best strategy to get bigger blocks in your opinion, now that miner support seems to be (at the moment) stagnating for BU?
What do you think about extension blocks?
The bitcoin infinity patch sounds interesting, any links? Also I wonder how many alternative node implementations are adding the mempool saving feature that Core 0.14 has. I can fire up a second node under Linux to try a few different implementations out.
Here's the repo:
https://github.com/whitslack/bitcoin-infinity
holly shit 32MB blocks
Thanks. Any plans to add the mempool saving feature in BU? I had a quick look at the open issues / pull requests and couldn't see one.
I'm not sure; thezerg would know. It sounds like a good feature that aligns with our vision, so I'd assume we would.
We're always looking for people to port over things like this, if you're interested!
The bitcoin infinity patch sounds interesting, any links? Also I wonder how many alternative node implementations are adding the mempool saving feature that Core 0.14 has. I can fire up a second node under Linux to try a few different implementations out.
Here's the repo:
https://github.com/whitslack/bitcoin-infinity
Thanks. Any plans to add the mempool saving feature in BU? I had a quick look at the open issues / pull requests and couldn't see one.
Why not have a problem with cores ulterior motives. They want to make a lot of money off chain for them selves.
blockstream, not core, though of course they're interrelated to an extent.
as long they remain demonstrably committed to maintaining bitcoin's integrity then i'll approve of them, not that my approval counts for anything.
The bitcoin infinity patch sounds interesting, any links? Also I wonder how many alternative node implementations are adding the mempool saving feature that Core 0.14 has. I can fire up a second node under Linux to try a few different implementations out.
Here's the repo:
https://github.com/whitslack/bitcoin-infinity
Jump to: