Bitcoin Forum
May 26, 2024, 02:07:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 164 »
  Print  
Author Topic: BiblePay - New Coin Launch - Official Thread  (Read 119795 times)
inblue
Full Member
***
Offline Offline

Activity: 462
Merit: 103


View Profile
August 10, 2017, 07:36:32 PM
Last edit: August 11, 2017, 01:37:04 PM by inblue
 #661

I think there's definitely something wrong (or at least strange) with this algo. My observations:

  • This GMT 24 hour day will be finished with approximately 140 blocks found, instead of the intended 205. Yesterday it was 148. The day before 136, etc. I went back a few days more and I think it was below 150 repeatedly. Why are blocks not catching up to the 7 minute rule? Even though I know we humans are bad at evaluating true randomness, this pattern of only ~70% found blocks every day consistently doesn't seem like a minor difference or a random occurrence.
  • The thing happy_merchant mentioned about not having blocks for almost an hour, then suddenly 2-3 blocks are found in a couple of minutes. Then also about 2-3 more blocks in the next ~5-15 minutes, then again nothing for almost an hour.
  • I think difficulty is behaving strangely - I don't think it drops after one hour like it should, because the first block after a long pause shows a high difficulty, but then the immediate next block shows a much lower difficulty, which is in line with my point above about sudden quick blocks.
  • I am solo mining for about 30 hours with about 12% nethash (1000k) and I found 1 block instead of statistically about 30 blocks. I didn't find like 10 blocks to say "eh, it's bad luck", this is a huge 30x difference. And yeah, even if I calculate the real statistic using the actual daily blocks found (which is around 70% of 205), still 70% of 30 is 21 blocks, not 1. I also see everyone else complaining about bad luck, so maybe it's not bad luck after all, but something could be wrong? Especially when you consider my previous points. I wonder what will happen in the upcoming pool.

Otherwise, I really like this project and the highly active dev, keep it up!
viljy
Hero Member
*****
Offline Offline

Activity: 1764
Merit: 893


View Profile
August 10, 2017, 07:50:36 PM
 #662

Updated to new wallet. What  am wondering. On previous coins when setting mining active it did not mine/use CPU power before blocks were synced.
Here it is showing mining as active when there is no block source available / not yet synced and it utilize cpu 100%.

I am asuming mining done until sync is waste, but will it start mining real blocks when synced?
We have a setting in our consensus params that will stop the wallet from mining on a dead chain.
Right now, that setting is Off since we allow debugging.  We can turn that On when we enable the sanctuaries.
As far as syncing, I belive the problem is the external node just hit 501 connections this morning and thats more than it can handle.
Please try:
addnode=biblepay.inspect.network

In the mean time I will raise our limit here to 800 connections.


Thank you for the response. It synced shortly after, but i let the question stay for the next time i reboot and others.
If i start mining before sync it mines a dead chain. When it is synced, will it then auto go for the live chain? I waited for sync to be sure and restartet mining.

Exciting to hear you have contacted bittrex! If it goes live there we can see a nice increase in volume, and probably big pumps of price. More for the miners, but also more for charity!

Yeah, the miner actually checks the tip of the chain every 15 seconds and creates a new block based on the active chain, so no worries there.

10-4 on Bittrex.

So, I think for us to run a fair and transparent charitable DAO, I would like to add a ground rule for BiblePay dumping the foundation orphan wallet on the exchange, so that we are fair for investors and miners.  We will dump the orphanage wallet on the third Friday of every month through the day.  That is August 18th this month, all coins get dumped.  So buyers be ready.  100% of the resulting BTC goes to sponsor orphans at compassion.com.  (We will have a dedicated compassion account, so it is easier for us to post the pictures and orphan IDs back on the site and in-wallet within approx 7 days of the dump- this will give us time to set up our database with orphan IDs and pictures, etc).



To reduce the negative impact on prices on the exchange, perhaps you should offer to buy the entire package of charity coins in bulk at an affordable price? In a special branch. Buy one whose offer will be higher. How do you look at it?
Plainkoin
Member
**
Offline Offline

Activity: 116
Merit: 10


View Profile WWW
August 10, 2017, 08:26:45 PM
 #663

Can anyone confirm whether or not this is the most recent wallet version?

Biblepay Core version 1.0.1.9 (64-bit)

For some reason after rebooting the wallet it gets stuck on the synchronization at 0 hours behind?

I got the same, but it only took some time. Try to leave it on for some time.

Same here as well.  If in a rush go to Roaming/BiBlePay copy out the Biblepay.conf and your Wallet.dat.  Delete the rest.  paste back in the two files and the rest rebuilds on launch.

inblue
Full Member
***
Offline Offline

Activity: 462
Merit: 103


View Profile
August 10, 2017, 08:33:44 PM
 #664

Can anyone confirm whether or not this is the most recent wallet version?

Biblepay Core version 1.0.1.9 (64-bit)

For some reason after rebooting the wallet it gets stuck on the synchronization at 0 hours behind?

I got the same, but it only took some time. Try to leave it on for some time.

Same here as well.  If in a rush go to Roaming/BiBlePay copy out the Biblepay.conf and your Wallet.dat.  Delete the rest.  paste back in the two files and the rest rebuilds on launch.
The wallet seems to be synchronized even though it shows the progress bar with "0 hours behind" because it starts to mine at that time.

Also I figured out that the wallet will display correctly simply after one block has been found on the network while it's running.
ProsperousWealth
Member
**
Offline Offline

Activity: 65
Merit: 10


View Profile
August 10, 2017, 08:43:27 PM
 #665

what kind of mining rig would one use for
PROOF OF BIBLEHASH (POBh)
I'm assuming its GPUs but just wanted clarification, thanks in advance
Plainkoin
Member
**
Offline Offline

Activity: 116
Merit: 10


View Profile WWW
August 10, 2017, 08:47:50 PM
 #666

what kind of mining rig would one use for
PROOF OF BIBLEHASH (POBh)
I'm assuming its GPUs but just wanted clarification, thanks in advance

Its an X11 modified.  You are not likely to find anything in the forums until someone writes something up in OpenCL - hopefully not for a long time.

For now its CPU hashing power.

GeniusX
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
August 10, 2017, 10:06:35 PM
 #667

i rent              2x       Intel® Xeon® E5-2620 v3

what you think about hashpower? 2 hours later pc gonna be ready for mine?
fpsnerd
Member
**
Offline Offline

Activity: 69
Merit: 10


View Profile
August 10, 2017, 10:24:12 PM
 #668



ahahahaha nice one  Grin
Bannedseller
Sr. Member
****
Offline Offline

Activity: 581
Merit: 250


View Profile
August 10, 2017, 11:20:30 PM
 #669

i rent              2x       Intel® Xeon® E5-2620 v3

what you think about hashpower? 2 hours later pc gonna be ready for mine?

Will it be possible to mine this coin BiblePay using GPU or is it strictly CPU. If someone has to buy a good CPU  to mine a coin what do you recommend. 
m4tsby
Member
**
Offline Offline

Activity: 126
Merit: 10


View Profile
August 11, 2017, 01:43:22 AM
 #670

typically, more threads means more hash with x11.
Xeons work great, but to me, you paint yourself into an investment for a niche.
I say go threadripper and let us know hash rate.
m4tsby
Member
**
Offline Offline

Activity: 126
Merit: 10


View Profile
August 11, 2017, 01:45:33 AM
 #671

Recompiling for the wallet update on linux.. what does that look like? Im a linux noob but somehow managed to get it all working...just dont want to screw it up.

thanks!
togoshigekata
Full Member
***
Offline Offline

Activity: 1260
Merit: 115



View Profile
August 11, 2017, 02:36:26 AM
 #672

Is the explorer reporting correctly? http://biblepay.inspect.network/
Im seeing some weird behavior,
blocks with same timestamp, blocks with multiple recipients, amounts higher than 19k

unstreet
Full Member
***
Offline Offline

Activity: 250
Merit: 100



View Profile
August 11, 2017, 03:35:04 AM
 #673

this algo strange. maybe its about luck.  Grin
togoshigekata
Full Member
***
Offline Offline

Activity: 1260
Merit: 115



View Profile
August 11, 2017, 04:40:49 AM
 #674

Something strange is definitely happening, saw blocks jump from 2618 to 2625

happy_merchant
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
August 11, 2017, 06:07:32 AM
Last edit: August 11, 2017, 06:24:56 AM by happy_merchant
 #675

Something strange is definitely happening, saw blocks jump from 2618 to 2625

The biblepay daemon on the block explorer died for some reason so I had to restart it, which is why several blocks updated at once.

The front page lists all transactions, not just mined blocks. A single block contains the block reward transaction to the miner, as well as transactions where BBP is transferred from one address to another. That's why you see multiple transaction entries listed under a single block.

-edit-
Guess those blocks actually did get mined in pretty quick succession.

2619 -> 2017-08-11 04:34:04
2620 -> 2017-08-11 04:35:06
2621 -> 2017-08-11 04:35:18
2622 -> 2017-08-11 04:35:54
2623 -> 2017-08-11 04:36:00
2624 -> 2017-08-11 04:36:34
2625 -> 2017-08-11 04:37:32

A little unusual, looks like the difficulty dropped down about an order of magnitude during those blocks. Seems to happen occasionally.
inblue
Full Member
***
Offline Offline

Activity: 462
Merit: 103


View Profile
August 11, 2017, 07:01:13 AM
Last edit: August 11, 2017, 07:38:10 AM by inblue
 #676

Guess those blocks actually did get mined in pretty quick succession.

2619 -> 2017-08-11 04:34:04
2620 -> 2017-08-11 04:35:06
2621 -> 2017-08-11 04:35:18
2622 -> 2017-08-11 04:35:54
2623 -> 2017-08-11 04:36:00
2624 -> 2017-08-11 04:36:34
2625 -> 2017-08-11 04:37:32

A little unusual, looks like the difficulty dropped down about an order of magnitude during those blocks. Seems to happen occasionally.
Yes, that's what I wrote about on the previous page in detail, it's weird and I think something is not set up correctly in the algo.

And I think togoshigekata was talking about seeing the same block number listed 2-5 times in a row, not the transactions inside one block. Also about multiple recipients of the 19k reward, higher amounts, same time stamps...

Edit: Blocks 2640 and 2641 have the same time stamps. Is it even practically possible to mine two blocks in the same second and for one of them to not become an orphan? Because that means you first have to receive the information from the network that a new block has been found, with all the latency, then to find a new block exactly in a few milliseconds after that, then to send that to the network again with the latency, and all that to happen in the same second?
Ginzink
Full Member
***
Offline Offline

Activity: 462
Merit: 118


View Profile
August 11, 2017, 07:45:24 AM
 #677

Well i got two blocks this night, finally some more return Smiley
happy_merchant
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
August 11, 2017, 07:58:39 AM
 #678

Yes, that's what I wrote about on the previous page in detail, it's weird and I think something is not set up correctly in the algo.

And I think togoshigekata was talking about seeing the same block number listed 2-5 times in a row, not the transactions inside one block. Also about multiple recipients of the 19k reward, higher amounts, same time stamps...

Edit: Blocks 2640 and 2641 have the same time stamps. Is it even practically possible to mine two blocks in the same second and for one of them to not become an orphan? Because that means you first have to receive the information from the network that a new block has been found, with all the latency, then to find a new block exactly in a few milliseconds after that, then to send that to the network again with the latency, and all that to happen in the same second?

People seem to get confused by the explorer sometimes. Maybe this mspaint edit will help explain it a little



Two blocks can have the same timestamp if the second one is mined quickly enough. There's even a possibility that a block can have an earlier timestamp than the preceding block without being an orphan block, if the miners' clocks are slightly out of sync. Information moves fast, if the difficulty for a block is low or the miner is really lucky it's not unusual to mine a block within the same second of accepting the previous block. You can verify that the blocks were processed in order because the higher block will contain the previous block's hash.
inblue
Full Member
***
Offline Offline

Activity: 462
Merit: 103


View Profile
August 11, 2017, 08:22:58 AM
 #679

Thanks for the image, it helped. You are right, I thought I was looking at the block list, not the transactions list. It confuses me because I am mostly used to the bitcoin explorers where you have just a list of blocks with the number of transactions beside it. And yeah, I forgot that block hashes begin with zeroes so here those are clearly transaction hashes.

But I still think Iquidus is strange because why would they make the interface such that the block column in the table is first, if the main data which is used for the table are transactions? The first column should be a transaction hash, which is unique, and then in that row the block number where the transaction is included could be written on the right. Wouldn't that make more sense?

Especially because this page exists: http://biblepay.inspect.network/movement
So I don't understand why the transactions are listed again on the main page, and also why there isn't simply a block list page.

Also, could you maybe explain why the second transaction in this block is not shown in the "Movement" page?
happy_merchant
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
August 11, 2017, 09:31:02 AM
 #680

Thanks for the image, it helped. You are right, I thought I was looking at the block list, not the transactions list. It confuses me because I am mostly used to the bitcoin explorers where you have just a list of blocks with the number of transactions beside it. And yeah, I forgot that block hashes begin with zeroes so here those are clearly transaction hashes.

But I still think Iquidus is strange because why would they make the interface such that the block column in the table is first, if the main data which is used for the table are transactions? The first column should be a transaction hash, which is unique, and then in that row the block number where the transaction is included could be written on the right. Wouldn't that make more sense?

Especially because this page exists: http://biblepay.inspect.network/movement
So I don't understand why the transactions are listed again on the main page, and also why there isn't simply a block list page.

Also, could you maybe explain why the second transaction in this block is not shown in the "Movement" page?

I have the movement page configured to only show transactions above 20k BBP so that it won't just be cluttered with mining reward payouts. Once the trading volume is higher I'll lower the limit on the filter, but for now the ratio of mining reward transactions to user transactions doesn't really make it practical. Ideally you'd be able to filter the mining rewards from the movement page, but Iquidus doesn't seem to have a configuration option for that.

As far as the layout, that's just the way the author designed it. The transactions are sorted by the block they're included in, so it's not really weird to have that as the first column. Also makes it easy to see what the latest block is from the explorer page. In most typical usage I'm just using the search bar to search a specific block in any case, lists of hashes don't really tell you much. You can navigate up and down the blockchain while inspecting a block using the arrows and see the raw blockdata by clicking the information icon.

I'd like to customize the explorer specifically for Biblepay eventually, but I'm going to hold off until the dev irons out the details of charity-related features. Something like a script specifically for tracking the charity wallet with its estimated value and a donation history list which catalogs whatever information is made available. If messages to and from orphans end up getting inserted in the blockchain, it'd be nice to have a page dedicated to exploring those.

And actually, that reminds me, since BBP is listed on an exchange now I need to see if I can start pulling price data from c-cex into the explorer.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 164 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!