Blockchain split of 4 July 2015 - page 6.

S4VV4S

hero member

Activity: 1582

Merit: 502

Quote from: SebastianJu on July 07, 2015, 04:02:58 AM

Quote from: ?? on ??

Quote from: yeponlyone on July 07, 2015, 12:48:43 AM

Is something up today also....?

I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587

As you can see from Blockchain.info - their is a stress test going on - most blocks are close to 1MB in size. You put only 0.0001 BTC as fees - so just wait until your cheap transaction gets selected by the miners...

These stress tests are annoying. They will proceed until they showed what they wanted to show it seems. Roll Eyes

Yes, but as mentioned before they are useful as to know how much the network can handle.
Obviously it needs more stressing than that Wink

But it's good to know the "limits".
Don't you think?

On another note, I think the "fork of July" was more stressing than the stress test.

SebastianJu

legendary

Activity: 2674

Merit: 1082

Legendary Escrow Service - Tip Jar in Profile

Quote from: ?? on ??

Quote from: yeponlyone on July 07, 2015, 12:48:43 AM

Is something up today also....?

I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587

As you can see from Blockchain.info - their is a stress test going on - most blocks are close to 1MB in size. You put only 0.0001 BTC as fees - so just wait until your cheap transaction gets selected by the miners...

These stress tests are annoying. They will proceed until they showed what they wanted to show it seems. Roll Eyes

S4VV4S

hero member

Activity: 1582

Merit: 502

Quote from: goku90504 on July 07, 2015, 02:39:41 AM

Quote from: RealBitcoin on July 04, 2015, 01:21:27 PM

Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment.

Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this?

no no no there is no stolen information the problems are all for people receiving BTC on older or light security wallets and it doesn't even say that it compromises the wallet it might compromise the individual transaction you received

I am a Bitcoin Core user myself, never needed something "lighter", however I need to ask: Do (any) SPV wallets have an alert system similar to Bitcoin Core to warn users?
And if not, then why not?

Also, edit all your posts in one, otherwise you might get banned by a mod.
Just a heads up Wink

goku90504

newbie

Activity: 23

Merit: 0

Quote from: RealBitcoin on July 04, 2015, 01:25:56 PM

Quote from: wpalczynski on July 04, 2015, 01:22:30 PM

Quote from: RealBitcoin on July 04, 2015, 01:21:27 PM

Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment.

Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this?

Its safe to send. If anything its the receiver that needs to wait for 30+ confirmations to ensure that he will retain the bitcoin.

Only the guy who controls the private keys of the address can double spend right?

Also excuse me for my noobness, but i`m not a tech person. How is it safe to send when blockchain.info hasnt updated their client, what if they send that bitcoin to the wrong blockchain, those coins are lost then arent they? Grin

no the coins are not a physical object that land on one side of the other that can be lost when one side takes the dump

they are a logical object the chain only records change in ownership so if its sent to the wrong chain the coin comes back to the sender when that chain takes a dump

goku90504

newbie

Activity: 23

Merit: 0

Quote from: RealBitcoin on July 04, 2015, 01:21:27 PM

Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment.

Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this?

no no no there is no stolen information the problems are all for people receiving BTC on older or light security wallets and it doesn't even say that it compromises the wallet it might compromise the individual transaction you received

goku90504

newbie

Activity: 23

Merit: 0

Quote from: Altcoin4life on July 04, 2015, 09:15:07 AM

Is there a way to force those spv mining to have their work count as less to discourage it?

sort of their work is invalidated if they build on a bad block meaning for that case it counts as 0 nada zip zilch if they build on a good block then there is no way to tell the difference between spv mining and regular mining from the outside

goku90504

newbie

Activity: 23

Merit: 0

Quote from: SISAR on July 04, 2015, 07:10:34 AM

Quote from: turvarya on July 04, 2015, 07:06:27 AM

Quote from: btc_enigma on July 04, 2015, 07:02:13 AM

Can someone explain why 0.9 bitcoind are not safe to use ? Won't they also catch up to the longest chain later ?

They allow invalid blocks.
So, if you have 2 chains one with invalid blocks and one without. Bitcoin Core 0.9 would chose the longest block as the right one. Bitcoin Core 0.10.2 would just ignore the chain with the invalid blocks.

Bitcoin always choses blockchain with the most work done (sum of all hashes that were used to create blocks, since genesis block) which is not neccessarily the longest blockchain.

not quite it first eliminates chains with invalid blocks by the rules of the current program then selects the one with the most work done of the reaming options if there is more than one at that point

goku90504

newbie

Activity: 23

Merit: 0

Quote from: Quantus on July 04, 2015, 06:13:55 AM

If your running any web based wallet I would not trust any incoming transactions with less then 20 confirmations. Because they could be orphaned by the network. Chines farms are spitting out a lot of trash these days in the hope they will make more money. They don't have the bandwidth to send out even 1mb blocks.

what is Chines farms do you mean Chinese?

yeponlyone

hero member

Activity: 504

Merit: 500

Thanks for the swift replies.

Both transactions are getting confirmations now.

Mikestang

legendary

Activity: 1274

Merit: 1000

Quote from: yeponlyone on July 07, 2015, 12:48:43 AM

Is something up today also....?

I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587

Lower fee tx are getting pushed to the back of the line, but regular fee are moving along just fine. All the backlogged tx are low fee.

https://bitcointalksearch.org/topic/are-we-stress-testing-again-1111811

yeponlyone

hero member

Activity: 504

Merit: 500

Is something up today also....?

I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587

Amitabh S

legendary

Activity: 1001

Merit: 1003

Quote from: Cryddit on July 06, 2015, 03:46:35 PM

Quote from: JorgeStolfi on July 06, 2015, 07:59:24 AM

Quote from: Amitabh S on July 06, 2015, 01:32:42 AM

On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness.

You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes.

Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published.

It's true. To determine the place in the last-thousand-blocks rule, you need to download and check the last thousand blocks (not just the last 50).

A different consensus-rule could be used that would be amenable to checking over shorter sequences. For example, each block could publish a "current block version" as it does now, _and_ a logarithmic average - with the changeover to occur when the logarithmic average gets within 0.05 of the higher integer version.

A logarithmic average at block n would (as an example) be 999/1000 of the logarithmic average at the previous block, plus 1/1000 of the current block version. Using a logarithmic average rather than a computed-over-the-last-thousand average would mean you could check and make sure the logarithmic average is right without looking more than one block into the past.

That is too complex. I believe a shortcut is as follows (quoted from another post):

Quote from: Amitabh S on July 06, 2015, 09:09:49 AM

Quote from: JorgeStolfi on July 06, 2015, 07:59:24 AM

Quote from: Amitabh S on July 06, 2015, 01:32:42 AM

On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness.

Let us assume that an "invalid chain" cannot be more than 50 blocks.

Step 1. We boot our SPV node "now", several days after the July 4 fork.
Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block.
Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers).
That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash).
Step 4. We can start counting b_m as a block of a valid chain if above checks pass.
Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient.

You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes.

Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published.

I agree, we need a timestamp. Version 3 started from orphaned block 363731 onwards. That block was generated at 2015-07-04 02:09:40.
which turns out to be 1435955980000 in Unix time.

We ensure that any block with timestamp greater than above is checked using the above logic with appropriate modification (example, v3 check in previous blocks stops at block 363730). This is still cheaper than running a full node.

This is "mixed mode" operating as SPV but bootstrapping using the previous 50 blocks (stopping at block 363730).

almightyruler

legendary

Activity: 2268

Merit: 1092

Quote from: dooglus on July 06, 2015, 01:19:37 PM

As I understand it, f2pool didn't even have a copy of the block they were mining on top of. All they had was the bare minimum needed to build on top of it.

I believe cgminer (and probably others) have supported this trick for some time: if a backup pool (that you otherwise never send any work to) signals new block data before your primary, the miner starts work on the new block, even though the primary has not yet acknowledged the block. The implementation of detecting this from one pool to another would differ to that of an end miner, but I guess it's effectively the same thing.

edonkey

legendary

Activity: 1150

Merit: 1004

Quote from: ?? on ??

The only way to get rid of un-ethical pools, is to vote with your hash (the mining hash Roll Eyes

). Already F2pool has lost about 5% of its network hashing power since the fork.

If you are a miner, mining on F2pool and looking for an alternative pool, why not consider Slush pool . Slush was the first mining pool in 2011, and he is also the creator of SatoshiLabs - the manufacturer of the Trezor hardware wallet. His pool is about 3% of the bitcoin network, why not give him a boost, and some support for the innovations he brought to bitcoin since 2011 ! As a bonus, you will receive a discount for the purchase of a Trezor, just to mine there!

+1 for Slush's pool!

I bailed on Antpool after the "Fork of July" (just made that up, but I'm probably not the first) and went back to Slush. It's a great pool. Although since it's a little on the small side you have to be OK with some variance.

Mikestang

legendary

Activity: 1274

Merit: 1000

Quote from: acid_rain on July 06, 2015, 03:19:47 PM

This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built.

30 tx (x) ~10 min/tx (/) 60min/hour = 5 hours

What coincidence are you alluding to? Sounds to me like you're some sort of conspiracy nut who's bad at math.

If you talk bitcoin/blockchain, you talk forks. People have been talking about them since the network first came on line.

Back to topic, latest Coindesk article on the fork: http://www.coindesk.com/double-spending-risk-bitcoin-network-fork/

l1m3st0n3

newbie

Activity: 8

Merit: 0

Quote from: MCHouston on July 06, 2015, 04:11:06 PM

Quote from: acid_rain on July 06, 2015, 03:19:47 PM

This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built.

People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses.

5 Hours but close.

lol @ 12 hrs.

MCHouston

hero member

Activity: 882

Merit: 500

Where am I?

Quote from: acid_rain on July 06, 2015, 03:19:47 PM

This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built.

People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses.

5 Hours but close.

Cryddit

legendary

Activity: 924

Merit: 1129

Quote from: dooglus on July 06, 2015, 01:19:37 PM

I don't see a way of checking that the miners even have a copy of the parent block let alone checking that they have verified it without breaking compatibility with all existing mining hardware.

Fuck all existing mining hardware. If miners can do this then clearly it isn't correct and needs to be thrown out anyway.

Cryddit

legendary

Activity: 924

Merit: 1129

Quote from: JorgeStolfi on July 06, 2015, 07:59:24 AM

Quote from: Amitabh S on July 06, 2015, 01:32:42 AM

On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness.

You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes.

Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published.

It's true. To determine the place in the last-thousand-blocks rule, you need to download and check the last thousand blocks (not just the last 50).

A different consensus-rule could be used that would be amenable to checking over shorter sequences. For example, each block could publish a "current block version" as it does now, _and_ a logarithmic average - with the changeover to occur when the logarithmic average gets within 0.05 of the higher integer version.

A logarithmic average at block n would (as an example) be 999/1000 of the logarithmic average at the previous block, plus 1/1000 of the current block version. Using a logarithmic average rather than a computed-over-the-last-thousand average would mean you could check and make sure the logarithmic average is right without looking more than one block into the past.

acid_rain

newbie

Activity: 41

Merit: 0

BTC has gone rogue. CFR has taken over biatch. '

While this will only inflate the price even more, legit businesses are hurting man.

Topic: Blockchain split of 4 July 2015 - page 6. (Read 45589 times)