hacash / explorer Goto Github PK

Accessing data from http://block.hacash.org/api/block/list?last=169355&limit=100 where:

limit=<100 is attainable.
However, if limit>100 it only returns: {"datas":169255,"ret":0}
Is there a way to access all data from genesis block where:
`limit = current block

Also, are there any other API documentations available?
Thank you.

Hey JoJoin, sorry but I think I got another issue with the HACD bidding to report.

To my understanding, every 5 blocks is the mining period for HACD bidding. So, on blocks ending with 5 or 0 the previous bidding period ends and begins a new period.

On block 164307 two diamonds were found by the same miner AYMBBY, XSYXSH with TX hashes f2f79b817be528a917641d29a0a442ee3c8906475086511d4b7e20de34a71015 and 94f9ea54b7b39e12aef06c4e04027913b5e97c681a7dd17ea453c2c9ecdebe00, respectively.

However on block 164310, the remained as shown here: https://gyazo.com/b78c3a3dd1fefacfb06a559cba581cc3 and they continued to persist up to the point I am writing this comment on block 164312 as shown here: https://gyazo.com/bf98892a935b785e7124b54fa687ed67

And here they are on block 314. A whole 7 blocks from when they were found (307): https://gyazo.com/42cb48d128b6a114f9f4b4797e0a19d9

I am 100% certain those 2 diamonds were mined on block 307. How did they "roll over" to the next 5 block bidding period?

Firstly, please let me know if there's a better place to be inputting these suggestions. I don't want to create a bunch of issue tickets on a bunch of repositories and make things difficult for you. I hope this feedback is useful to you.

Secondly, the reason for this "issue" is a suggestion to include coinbase transactions in the explorer in some way. As you see here, the explorer states "without coinbase": https://gyazo.com/191f9c506696f19f4849e25f8b770c6f . As far as I can tell, there is no where else coinbase deposits can be viewed so we cannot track block reward deposits and, more importantly, diamond bid deposits. Is there anyway we can add a toggle that allows for "With / Without Coinbase?

Third, is there a way to display the diamond name in the wallet for all diamonds in that wallet. As we previously discussed on a different issue thread, its REALLY hard to transfer diamonds. You stated the difficulty is party by design. But I have no way to look up my diamond names other than clicking through thousands of old block hashes to manually check if the diamond executed in the block was mine or not; all just to find the diamond name. We really need a way for the explorer to provide that information.

Thank you for your time. Let me know if I can be of any help.

If a HACD miner places an updated bid via wallet.hacash.org using a private key from another wallet than the original fee address the wallet will rightly state an error "Tx fee address password error." https://gyazo.com/1e4bd1c52e08444af32d667a2d83e8ae

However, the updated bid will still show on the bid table: https://gyazo.com/bcdd965e653dd4a8904970379fc348bc

As you see, HACD IZNAIT has a higher bid than HACD HYKZBI. However, that is the errored transaction I produced to create the first screenshot at the top of this message.

So we see two issues here:

1. An errored bid still is displayed on the bid table
2. The higher fee is not in the correct position as compared to other amounts (even though it is errored anyways). Its correctly positioned above the 6:244 bid, but incorrectly positioned under the 1:247 bid

This shot is from a pool worker miner: https://gyazo.com/d6c8d933a37bdc41f2def2b66129f972

Is the first number the hashrate the individual miner contributes and the second number is the total hashrate of the pool?

it is a fully premined coin - why lie about it??

Hey Brother,

Take a look at this video: https://vimeo.com/457031227

Password to access is: HACD

This is a video I was making for a friend to help explain HACD mining, but I caught the bug on camera so I wanted to show you.

As you will see the top bid is for 2:248. The mining period then closes and I go to check that HACD transaction. The fee paid was 3:247, not the top bid of 2:248.

The handling address had plenty of funds to pay the bid.

How did this happen?

I have 2 top 100 HAC addresses, but only 1 is displayed in the top 100 list. I have not transacted for a long time, so it is not just the chain is not caught up. Seems to be a bug.

There is an issue when displaying HACD Diamonds in [https://explorer.hacash.org]
The problem will be observed whenever there are greater than eighteen HACD Diamonds.

Take for example [https://explorer.hacash.org/address/1K7TqSzBDXk6cy3VifPWDgEZ97mDiao2vP], which has a number of HACD Diamonds.

The problem reported is that the names of the HACD Diamonds are split across multiple lines.
The browser used is Firefox, 91.0.2 (64-bit)

The fix for this problem is to only display the fully qualified HACD Diamond names.
The HACD Diamond names are already separated by commas, the code should allow fully qualified HACD Diamonds to be displayed in full, not split over multiple lines.

THANX(MKD).

Hello, sorry if this is commented in the wrong repo but I found a small bug:

A diamond miner can increase the bid for a diamond on wallet.hacash.org to an amount greater than the HAC available in the handling address.

For example,
Miner A has 10 HAC in the handling address
Miner B has 5 HAC in the handling address

Miner A bids 4 HAC for their diamond
Miner B bids 5 HAC for their diamond
Then Miner A increases bid to 6 HAC
Then Miner B increases bid to 7 HAC
Finally, Miner A increases bid to 8 HAC

Miner B only has 5 HAC in the handling address but is still able to bid 7 HAC. Of course, Miner B does not win the bid when the 5 block confirm window ends. Miner A wins the diamond for 6 HAC since Miner B did not have the bid amount (7 HAC) in the handling address. However, Miner B "cost" Miner A an extra 2 HAC. Miner B was showing a bid greater than the amount than he had available. This would be misleading to Miner A on the explorer that shows diamond bids.

This issue "breaks" the game theory that plays out among diamond miners. It means people that have no intent to pay the bid amount can drive the price up without risking anything as long as someone outbids them.

A handling address balance check should be added so that a bid cannot be placed if the bid amount is greater than the amount of HAC in the handling address.

Hey Brother,

Found another important bug to diamond mining: If an amount is larger, but uses a smaller decimal setting (eg, 247 vs 246), the smaller amount will win the diamond. Allow me to show you what I mean:

Here we see 2 miners with diamond bids: https://gyazo.com/0768dfc91ddd0ded45ce7c63e3c243cd. Address 133u... has 34:247 and Address 1HE2.. 341:246. Therefore, Address 1HE2... should be on top AND win the diamond. However, that is not what happened. Here you see that the diamond was given to address 133u... with a LOWER bid: http://block.hacash.org/tx/fb12e3fe351841b6720040d2e0e68f1dc703b435a5328e10d6a13d2cb81f8828

Both addresses had an adequate amount of HAC to bid as shown in these screenshots taken just before the close of the 5 block period: https://gyazo.com/d88f7e2aec575c00cdeb607745866e96 and https://gyazo.com/8b84c11a613c9dca9f38e5874c45ece2

Please let me know if you need any additional info.

Image link: https://mega.nz/file/RbpGjayY#iH1qK6vHqx83zXvxoN8F1vPkoG-UsZyoqDkWwsmHVXs
https://mega.nz/file/FS5xUbrR#M_3-ghJmYhi-MbWRlhx2nJ-ZXtWlSyEBlxdKDuPYjVc

In fact this scenario is easy to replicate:

Step 1. Have a HACD showed up on current ranking.
Step 2. Stop your miner and edit the fee_amount on [diamond_miner]
Step 3. Run the miner again.

It will result into multiple entry of HACD with the same name of same address but different transaction hashes.

This error can be easily replicated by:

Setting Up:

http://rpcapi.hacash.org/
create?action=value_transfer_tx&
main_prikey="private key of 1NpcusWsFysWWoQXxTM21X8gn7d98xbkDC"&
fee=0.0001&
unitmei=true&
transfer_kind=hacash&
amount=200000000000000&
to_address=1NpcusWsFysWWoQXxTM21X8gn7d98xbkDC

Setting up:
amount = whatever you desire
main_prikey = private key of "from address"
to_address = address of "from address"

And posting the txbody on "send transaction section on wallet.hacash.org or by using curl"

Image:

: The transaction is recorded in the blockchain, but the transaction amount (HAC) is not transferred to the destination address. Only the transaction is shown in the blockchain plus fee deduction on the source address , are what I observed.