Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subscription status remains the same for very busy addresses #566

Closed
erasmospunk opened this issue Aug 9, 2018 · 4 comments

Comments

@erasmospunk
Copy link
Contributor

commented Aug 9, 2018

While researching something for issue #348 I discovered this probably rare bug.

When an address contains too many transactions, the subscription status stops changing on newer transactions.

This threshold depends on the MAX_SEND env variable and in default installation is 10309 transactions. When setting the minimum MAX_SEND = 350000 the limit is 3608 transactions.

An easy way to try it is in regtest by mining to a single address with the generatetoaddress RPC call. Once the threshold is passed the blockchain.*.subscribe will return the same status hash.

The reason this happens is that session's ::address_status() function needs the full address history to properly calculate the status while the ChainState::get_history() limits the number of history entries depending the MAX_SEND env var.

@kyuupichan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2018

Yeah; I think I consider this more an anti-DoS feature than a bug. Imagine that address is Satoshi Dice's busy one....

With the new protocol suggested in #348 this wouldn't be an issue

@erasmospunk

This comment has been minimized.

Copy link
Contributor Author

commented Aug 10, 2018

Initially I thought about using the reverse order of the limited history to guarantee that the status will always change but then we will hit the blockchain.*.get_history limits.

Do think it makes sense to return an error message when the limit is reached?

@kyuupichan

This comment has been minimized.

Copy link
Owner

commented Feb 17, 2019

Yes I think returning an error is the right thing. It might take out the clients though!

@kyuupichan

This comment has been minimized.

Copy link
Owner

commented Feb 17, 2019

But that's not a reason to avoid doing it; I'll aim to do it for the next release

@kyuupichan kyuupichan self-assigned this Feb 17, 2019

@kyuupichan kyuupichan added this to the 1.9.6 milestone Feb 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.