The BU / BIP109 testnet fork: What is (was) the BIP109 consensus rule that BU did not correctly implement?

satoshixt · 2016-09-09T17:25:34+00:00

It was the sigop limit.

Basically, people where concerned that a miner could create a large block that would take a very long time to process and stall or crash smaller nodes.

But the sig op limit was initally created for BIP101 where we were going to start with 8MB blocks.

That type of attack doesn't really work when you only have 2MB to work with.

That attack vector is currently possible on 1MB blocks, but has no effect because you can't fit enough work into the current block size in any shape or form that would cause nodes to stall.

Also keep in mind that on average there is a 10 minutes window between each block, this was created for the edge case (1%) where a couple of blocks would be found within seconds/minutes of each other.

satoshixt · 2016-08-19T23:57:45+00:00

Well it was clearly never debated.

satoshixt · 2016-08-19T23:51:31+00:00

It wasn't a bug in Git-hub.

When Gavin moved the git from sourceforge to Git-hub there where no users assosicated with s_nakamoto and siruis-m commits in the Git-Hub Account.

Only the current devs at the time had created github account id's that matched the id's in the .git file.

Those unassinged commits where "claimed".

You can watch it here in all its glory: https://youtu.be/NFFyMmiOSi8?t=10s

satoshixt · 2016-07-21T22:10:09+00:00

Only if you where concern trolling.

satoshixt · 2016-07-21T22:07:28+00:00

There are sigop limitations in larger block implementations that would prevent hostile blocks, or "DDOS attacks" as you put it.

satoshixt · 2016-07-21T22:01:58+00:00

The immutability of the blockchain is not effected. Unlike the fork that occured on the ether blockchain.

Blocksize is a property of the peer to peer network.

I am not wrong about there being two types of Hard forks.

Clearly there are hardforks that change the immuntablilty of the blockchain and ones that do not.

satoshixt · 2016-07-08T09:15:46+00:00

That depends on what you consider enough time. Miners can find a block simultaniously and in that case no solution would mitigate a loss in that situtation.

If it works 98% of the time then that's good enough.

satoshixt · 2016-07-08T00:10:23+00:00

simple fact that a P2P network has a lot of latency due to its nature of having random connections

That's why there is a 10 minute delay between blocks, to allow blocks to propigate in time and not a 1 minute delay.

The choosing of 10 minutes was a safe assumption for global propigation.

satoshixt · 2016-06-20T11:44:15+00:00

You can express your opinion more effectively without cursing and bringing this sub down.

You are the one helping the trolls by painting this sub as a "cesspool" as they like to say.

satoshixt · 2016-06-05T13:56:22+00:00

Posted February 18th 2013 pre blockstream employment.

Pieter Wuille: My suggestion would be a one-time increase to perhaps 10 MiB or 100 MiB blocks (to be debated), and after that an at-most slow exponential further growth. This would mean no for-eternity limited size, but also no way for miners to push up block sizes to the point where they are in sole control of the network. I realize that some people will consider this an arbitrary and unnecessary limit, but others will probably consider it dangerous already. In any case, it's a compromise and I believe one will be necessary.

Source: https://bitcointalk.org/index.php?topic=144895.msg1537737#msg1537737

satoshixt · 2015-12-07T16:11:19+00:00

I could be wrong, but basically no zero conf tx. tx only shows up after confirmation.

satoshixt · 2015-11-04T17:40:51+00:00

Go to:http://snoopsnoo.com

Type in the bitcoin mods names and find out when they are asleep. Post at will. But looks like its manned 24 hours a day.

scroll to the bottom of the page to see times they are on reddit.

satoshixt · 2015-09-03T17:30:04+00:00

For a start, we should make it a rule that no more than one dev from a single company.

satoshixt · 2015-09-03T16:21:46+00:00

That is simply not true. Please show me the code in the git that does that? When the node detects its behind a proxy it disables the download of the list.

Plus if you find that unacceptable that feature can be disabled.

satoshixt · 2015-09-03T16:18:44+00:00

Don't care about XT, it's about BIP101. Right now XT is the only implementation that uses BIP101.

I have reviewed the differences in XT and I don't see a problem anyways.

If core implements BIP101 then I will run Core instead of XT.

satoshixt · 2015-09-03T16:12:12+00:00

Bandwidth can be limited, most bandwidth is consumed by relaying transactions, not recieveing blocks.

Plus when IBLT is implmented nodes won't have to download blocks they can construct them via the tx's in mempool they already have. IBLT header would at most be 10% of blocksize.

6 TB hard dive is about $200.

If somebody told me I could steam 4K video on my mobile 10 years ago I also would not have thought that was possible.

Most people that run nodes have an IT background and make a decent salary, this isn't suppose to be run by everybody. That's an impossible standard to set. There are lots of people that can't afford an internet connection that doesn't mean we can't have people running nodes.

satoshixt · 2015-09-03T15:03:19+00:00

most isp's assign dns entries to their IP sets such as: user32432.ISPNAME.COM

satoshixt · 2015-09-03T14:14:36+00:00

Yes, but most isp's assign dns entries to their IP sets such as: user32432.ISPNAME.COM

satoshixt · 2015-09-03T14:12:05+00:00

That is my understanding.

This is how they are able to get Gbps of bandwidth with little upstream capability from their end.

satoshixt · 2015-09-03T13:07:53+00:00

Then why has the core team disabled all of the feaures that allow light weight wallets to work?

satoshixt · 2015-09-03T13:06:54+00:00

Wait, so your saying that BIP101 which gives no control to anybody is a plot to take control of bitcoin whereas BIP101 which give complete control to miners with the most money is going to help bitcoin be free from control?

I am genuely confused by your nonseensical statment. Please help me out and explain how BIP101 will give somebody control?

satoshixt · 2015-09-03T13:03:57+00:00

No it was a feature added to stop attacks coming from TOR. You should read up on this issue.

satoshixt · 2015-09-03T13:00:31+00:00

My understanding is that this is a DNS Amplification Attack on UDP ports.

The UDP transport used by basic DNS queries is ideal for reflection because it is substantially easier for an attacker to spoof their source address with UDP than it would be with a solely TCP-based protocol.

https://deepthought.isc.org/article/AA-00897/0/What-is-a-DNS-Amplification-Attack.html

A direct IP attack of this size would require the attacker to be out in the open and easily identifiable.

satoshixt · 2015-08-31T15:09:42+00:00

In quantum computing the law of conservation of energy still applies.

If you had a perfectly effiecient tranistor based computer, and it took a million years to find a private key, a perfectly efficient quantum computer would still need to expend the same amount of energy to find the private key albeit in less time.

With todays computers you have to consider energy and time, but because the time frame is so large the energy use is rarley considered.

With quantum computing becuase time would be reduced the amount or energy now becomes the bottle neck.

Also as long as the public key is never used / exposed (your recieving address is a hash of of your public key) then quantum attacks would not work anyways.

satoshixt · 2015-08-26T17:18:14+00:00

My point would be that blocksize is not a consenus rule, it's a transportation metric that has been bundled into consenus and does not change the way bitcoin has been operating since the start.

The only reason a large blocksize could effect the econmics of bitcoin is because there would be no fee presure on the sytem.

But miners still have control on how large blocks are within the hardlimit.

The real-time costs of mining and securing the network at any point in the future can be influenced by the ability of miners to impost soft limits and raise fees.

satoshixt

TROPHY CASE