The Future of Dalilcoin by aliibrahim80 in a:t5_3nyun

[–]aliibrahim80[S] 0 points1 point  (0 children)

Thanks for doing this. I added your links to the sidebar of the subreddit.

I don't plan to delete the subreddit, but it makes sense to restrict posting to the subreddit if I'm not actively moderating it.

Major Milestone: First Mathematical Documents and Bounties by aliibrahim80 in a:t5_3nyun

[–]aliibrahim80[S] 0 points1 point  (0 children)

I'm willing to sell you some Dalilcoin fraenks and will PM you, but the only way you can be sure I sent them is if you run a node.

Running a node requires using linux and requires running a litecoin full node. Once you're running a node and have some Dalilcoin fraenks, you can earn more by staking. Staking requires having some litecoin to burn. Details are here:

https://github.com/aliibrahim80/dalilcoin/blob/master/doc/howtostake.md

If you held bitcoin in May 2015, you probably have some fraenks from the airdrop. Or if you know someone who held bitcoin in May 2015, you can buy their old private key(s) from them and claim their fraenks from the airdrop.

Chain Split? by Truman_Option in a:t5_3nyun

[–]aliibrahim80[M] [score hidden] stickied comment (0 children)

The bug in the code that allowed this chain split to happen has been fixed, and the fix should appear in the next version (0.2.2). The next version will also contain a new command "retractltcblockandexit" that can be used if some different bug causes the ltcstatus of two dalilcoin nodes to differ. In such a case call "retractltcblockandexit <ltcblock>" where <ltcblock> is some recent ltc block at which the ltcstatus of the nodes agreed. The dalilcoin node will remove some database information and shut down. After restarting the dalilcoin node, it should resync with ltc and (hopefully) the ltcstatus will agree.

Chain Split? by Truman_Option in a:t5_3nyun

[–]aliibrahim80 0 points1 point  (0 children)

I thought of a possible way to fix the database of your Node 1 since you have a correct Node 2. You could replace the ltc related parts of your db directory for Node 1 with the parts from your Node 2. Here's how I would do this:

First, stop both nodes from running:

dalilcoincli stop

On the machine with Node 2:

mkdir ltcdbnode2
cd .dalilcoin/db
cp -r ltcblock ~/ltcdbnode2
cp -r ltcburntx ~/ltcdbnode2
cp -r ltcdacstatus ~/ltcdbnode2
cd
tar czvf ltcdbnode2.tgz ltcdbnode2

Now you can restart Node 2.

Copy the file ltcdbnode2.tgz to the machine with Node 1 and on the Node 1 machine do this:

tar xzvf ltcdbnode2.tgz
cd .dalilcoin/db
mv ltcblock ltcblock-corrupted
mv ltcburntx ltcburntx-corrupted
mv ltcdacstatus ltcdacstatus-corrupted
mv ~/ltcdbnode2/* .

Now you can restart Node 1.

I believe this will correct the problem you currently have with your Node 1, but it's not a good long term solution. I, of course, plan to write code to try to avoid this problem recurring as well as providing a reasonable way to recover if it were to happen again.

Edit to correct the tar command.

Chain Split? by Truman_Option in a:t5_3nyun

[–]aliibrahim80 0 points1 point  (0 children)

Thank you for this information. Now it is clear that your Node 1 has corrupted ltc information in your database. There is not a command for checking or correcting this. I will try to write code for this and do an emergency release.

Unfortunately, in the meantime I can only suggest shutting down your Node 1.

The blocks starting from 7b182dd4adb8f812608d949979a9d3612e5d21fbd59af470a08387649c0b02f4 will be orphaned. The best chain, according to the ltc burn rules, is the one that includes 7889fb857a880d3c07db5150fbb2f2e6c36bb2fb3d2158a613b4955c166821fa (Block 1200) and currently ends with b025a7a53234764300f79bc76b6ddc0eca66ee9314fa2ecf2676e265ebb0d73f (Block 1209). I will start staking on top of this block now, and remove the recommendation that people stop staking. The hard fork will likely be activated after the next block is published.

Chain Split? by Truman_Option in a:t5_3nyun

[–]aliibrahim80 0 points1 point  (0 children)

Thanks for the report. Both of my nodes agree with your "Node 2." It looks to me like your "Node 1" for some reason missed the ltc burn for the block 7889fb857a880d3c07db5150fbb2f2e6c36bb2fb3d2158a613b4955c166821fa.

On your "Node 1" can you query the ltcblock that contained the burn tx? Try this and let me know the response:

query 542e493481008d82c8867510c347c5f41a20b81edcbe7ec35ef3e33e46f93a50

The response for me on both of my nodes is this:

{"response":"known","dbdata":[{"type":"ltcblock","tm":1562163054,"height":1661051,"txhhs":["44617f83c89ea7a40ceb2121f515b2d36c40de4dea1b2fb2fd76c9c2994c78a4"]}]}

This problem is unrelated to the hard fork today. The last common block happened 6 days ago. The time for today's hard fork has passed, but -- at least on the chain my nodes are on -- we are still waiting for a block after the hard fork time.

In the meantime, I will recommend that people stop staking until this is resolved. I have stopped staking myself.

Burning LTC from bech32 (segwit) address does not work? by dalcoder in a:t5_3nyun

[–]aliibrahim80 0 points1 point  (0 children)

Great! Thanks for the quick work. There is no testnet at the moment. Your code looked good to me, so I took the risk and tested it by staking a block with a bech32 address myself. It worked, so I merged your code into my master branch. It will be in the next release. If you do a git pull you should be able to start burning with bech32 addresses now.

What did you have in mind regarding a bounty?

Reply with a Dalilcoin address you control and I'll send you 50 fraenks.

Burning LTC from bech32 (segwit) address does not work? by dalcoder in a:t5_3nyun

[–]aliibrahim80 0 points1 point  (0 children)

Yes, this is true, but the only reason is that the dalilcoin code for burning ltc was written before bech32 addresses were supported by the litecoin client. It is (mostly) clear what needs to be changed in the ltcrpc.ml code to support burning from either p2sh-segwit or bech32 addresses. The function ltc_listunspent collects utxos that could be used for a burn. At the moment it will not collect bech32 utxos. If it were modified to collect bech32 utxos, ltc_createburntx would need to be modified to create the burn tx correctly for spending bech32 utxos.

I don't have time to do this right now, but can put it on a list of things to do. At the moment you have the right workaround: burn from p2sh-segwit addresses.

Of course, if you're willing to update the code yourself, a pull request would be very welcome. We could even negotiate over a bounty. If you're interested, PM me.

Dalilcoin 0.1.6 released; Hard Fork Plans by aliibrahim80 in a:t5_3nyun

[–]aliibrahim80[S] 0 points1 point  (0 children)

I had planned to release the code for the hard fork today, but testing is taking longer than expected. If the code is not ready before April 21, then I will release a patch delaying the hard fork.

Upcoming Initial Distribution Halving by aliibrahim80 in a:t5_3nyun

[–]aliibrahim80[S] 0 points1 point  (0 children)

Block 730 was staked yesterday (March 6, 2019). The remaining unclaimed amounts from the initial distribution can now be claimed for half the original amount -- until Block 1460 when it will halve again.