So do you still support BU?

[Genedarner123]

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?  

Why do core sheep continue to spread lies when not one of the core sheep has posted any data that asic boost has been used?
It's simple to prove or disprove. Yet still no data from the sheep.

Its not about whether they used it or not. The point is such an exploit dose exist and they tried to patent it without making it a public knowledge.

[Peter R]

I ran a BU node for a while, but now I consider it Bitcoin Unneeded. It's complexity just isn't required. I believe the block size limit should simply be removed altogether (as per the original bitcoin design). I think the right approach is dynamic block size generation, based on transaction pool demand factors, network propagation factors, etc.. Low fee paying transactions can be artificially delayed if required.

Are you running any node right now?  I'd love to see more nodes running on the network with the block size limit completely removed, as you suggest.  I think the "Infinity Patch" for Core is an initiative to do this.  I'm not sure how far along it is (not that it would be hard to do).

At the end of the day, nodes either accept blocks up to X MB or not.  Whether they are running BU, Classic, Core+∞, Bcoin or Btcd doesn't matter.

Previously, pools used to up the block size as a soft limit (until they hit the hard limit). This unfortunately does not keep up with moments of high demand, and provides no fee market pressure during periods of low demand. Unfortunately, when the demand cap is exceeded, the function of the bitcoin network starts to fall apart. That is, zero confirmation transaction risk changes from a disadvantageous double spend propagation attempt to one where the transaction does not confirm at all due to transaction pool forgetfulness, and selective transaction relay from nodes.

Here's a related graph:

[European Central Bank]

never for one second did i support it. that's not because i disagree with big blocks, it's because i disagree with ulterior motives and incompetence. and the absolutely relentless fud and shilling tells me this was not an effort worthy of anyone's respect.

[tournamentdan]

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?  

Why do core sheep continue to spread lies when not one of the core sheep has posted any data that asic boost has been used?
It's simple to prove or disprove. Yet still no data from the sheep.

Its not about whether they used it or not. The point is such an exploit dose exist and they tried to patent it without making it a public knowledge.

Actually they did make it public knowledge. Just not to the general public. Information about the asicboost was given out to Multiple pools not affiliated with Bitmain.

There isn't any proof that asicboost works. The only thing they may be guilty of is patent trolling. Yet I don't hear many people complaining about core patents for off chain transactions. Which by the way would make them shit tons of money.

[AngryDwarf]

Are you running any node right now?  I'd love to see more nodes running on the network with the block size limit completely removed, as you suggest.  I think the "Infinity Patch" for Core is an initiative to do this.  I'm not sure how far along it is (not that it would be hard to do).

At the end of the day, nodes either accept blocks up to X MB or not.  Whether they are running BU, Classic, Core+∞, Bcoin or Btcd doesn't matter.

I'm currently running a Core 0.14 node for its mempool saving feature, since I switch between Windows and Linux. I want to keep an eye on the mempool size so that I can combine UTXO's during low demand. It seems some pools are still using the coin amount * coin age feature, and I've managed to combine a few two UTXO's into a larger one for just 1 sat/byte; one confirmed in the next block, and all confirmed within two hours despite higher fee tx's being in the mempool! It's kind of an insurance policy against protracted block size limits and potential sky rocketing demand/fees. I can run quite relaxed mempool settings using this feature:

Code:

maxmempool=4096
mempoolexpiry=8760
minrelaytxfee=0.00000001

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.

[tournamentdan]

never for one second did i support it. that's not because i disagree with big blocks, it's because i disagree with ulterior motives and incompetence. and the absolutely relentless fud and shilling tells me this was not an effort worthy of anyone's respect.

Why not have a problem with cores ulterior motives. They want to make a lot of money off chain for them selves.

[Peter R]

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

[European Central Bank]

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.

[AngryDwarf]

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.

[Peter R]

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!

[XbladeX]

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

[jonald_fyookball]

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?

[AngryDwarf]

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.

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'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.

[tournamentdan]

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.

[Peter R]

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?

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    

[AngryDwarf]

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    

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!

[jonald_fyookball]

wasnt that the idea of the Bitcoin foundation? 

People loved to bitch and moan about them....but they were 100x better than Blockstream.

[zahra4577]

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.

[tournamentdan]

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    

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.

[DoomDumas]

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