Topic: [ANN][FLO] A Worldwide Public Record | Alexandria | ETDB | Medici | 0.15 Segwit - page 71. (Read 516115 times)

Sia is up and running now, it's a little rough around the edges in terms of UX but it's all "functional".

The way I would put it is that FLO is used to store and secure the library index itself, and the meta token supplies the equity and voting mechanism to guide future development (of the nice GUI front end and the back end).

I'll check out UIA - please dm me your email address so I can invite you to our Slack team, i'd very much like to chat with you about this if you're interested.

Filecoin is not up and running yet - all of the files published in alexandria *are* pinned by our web servers, yes, but not *just* by our webservers - a number of alpha testers and other IPFS users have pinned them as well, so if our servers went offline, the files would still be available. But we are still planning to use Filecoin to create the permissionless incentive structure necessary for a user to treat the network similarly to a CDN, in which they submit a file and some money and can actually count on guaranteed uptime for the file in exchange.

Hi Banano - you are correct that we'll be launching another token that controls the distribution of Alexandria's equity/development. Most likely this will be a meta-token, like an NXT or XCP asset, but the decision has not been finalized yet.

Ah ok.

Post removed.

I've seen this being spammed a lot on twitter and other various social media websites. It looks questionable to say the least.


RE: libsecp256k1: openssl signatures are still valid signatures. For now it is OK to accept these transactions after they have a normal amount of confirms. The best course of action is to do the following:

• Test a new version of Florincoin with libsecp256k on a testnet environment.
• When ready, choose a block 2-3 weeks away to hard fork.
• Alert exchanges and pools. Ask to disable withdraw/deposit requests and upgrade two days in advance.

The only real danger in a hard-fork scenario of this type is a double-spend in the blocks leading up to the fork, or right after the fork if not everyone upgrades.

I'll work closely with the team to make sure this is pushed out reasonably soon without error. Luckily the exchanges have been responsive to our hard-forks in the past and we have an open line of communication with them.

I mine Florincoin and I'm fine with whatever doesn't cause me to lose my coins .

With over 10k invalid transactions we do run into the issue that there are too many transactions to just blindly whitelist, so I agree with you there.


I agree that it would be an issue if invalid transactions were still being generated, it would be bad.


If indeed the issue is with OpenSSL (like it seems to be) then it would be good to update to libsecp256k1, however instead of setting the hardfork at 1,600,000 set it closer to our current block.


There are currently only a few pools that mine Florincoin (with Alexandria being the main one I believe) and only a few solo miners. If we stated that there would be a hard fork at X date and had the main players update then we would be able to mitigate most of the fallout. I think that this would be the best option to move forward, though that is just one girls opinion.

It would be great to hear from the people that actually mine Florincoin or have been around with it.

Well, this sucks.


There are 10,000 confirmed transactions in the blockchain that do not validate in the new codebase.

Out of 2,086,758 total transactions that's only a half of one percent however they all seem to be in the recent blocks. The first one was in block 1,505,023 the most recent was just a couple blocks ago.


I'm pretty sure this is due to OpenSSl updating and changing how it handles signatures

In July OpenSSL released a new update which caused compatability issues with previous versions and forked the bitcoin blockchain http://cointelegraph.com/news/miners-lost-over-50000-from-the-bitcoin-hardfork-last-weekend
After the OpenSSL update florincoin had no updates until December 10th when a new checkpoint was added. https://github.com/florincoin/florincoin/commit/28443da787504436066d391e0d5e75054f8627d2
The first invalid transaction appears in block 1,505,023, on December 10th. http://florincoin.info/explorer/tx/?txid=6cba295dbd61a81c35ab994a94b6e758782661b976ee015043ea2314f84535bf
Since that point they've been scattered throughout various blocks.

From the looks of things when the new version of florincoin was compiled on December 10th it used the newest OpenSSL at the time which caused these new signatures to start appearing, whereas bitcoin/litecoin use libsecp256k1 for their signatures to maintain compatibility but florin waited a bit "too" long and is already filled with "invalid" signatures from libsecp256k1's perspective.


I'm not sure what the best means to move forward now is. My initial thought was if it were only a couple transactions I'd whitelist them to bypass verification but there are 10,000 of them so that seems a little ridiculous. My second thought was to bypass verification on these transactions if they were included in a block prior to the latest checkpoint, along with a newly released checkpoint however that was shot down with the idea that these transactions are still occurring fairly regularly unless we had a sort of instant fork to get around that but I don't know if that's reasonable. From my understanding bitcoin remedied this by advancing to block v3 and rejecting these invalid transactions, which at the time for them was only a couple block fork that was reworked and orphaned unlike the 300k blocks since December we are dealing with here.


One idea I haven't ruled out yet is to set a block such as 1,600,000 which is a ways out to transfer to block v2 and start rejecting v1's thereby forcing everyone to update to libsecp256k1 instead of openssl, the remaining issue being what to do with the blocks and transactions between now and "then".
Next idea is to just YOLO it and make an announcement then update instantly with a checkpoint to force the right side of the fork, with coordination from pool operators to ease the pain. Sort of like just ripping the band-aid off and getting it over.

Again, I'm not entirely sure the best course of action moving forward. Prior to a few days ago I knew nothing of florin so I don't know all of the details, are there many pools or solo miners? How hard would it be to pull off a YOLO update which blindly trusted any transaction prior to the new checkpoint and then began rejecting all v1 blocks from old nodes after the update?

----

Next point, I've only dealt with the linux daemon, I have not gotten into qt nor windows binaries yet. Although so long as the daemon is running properly it should be "easy" to get qt and windows going as well.


----

If any of my post doesn't make sense... well... I'm tired and it probably doesn't make sense.

As of right now I'm wondering if the issue comes back to openSSL vs libsecp256k1 and the handling of signatures. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html & https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki

As a dirty hack I set all transactions to pass verification which then allowed it to fully sync. I then deleted the blockchain and am now syncing again with validation checks back in but also some debug log statements.

I believe im running into a similar issue trying to port over a block explorer. Some Peers appear to be issuing txes with invalid inputs (invalid txids). If you have any thoughts please send me a PM. T

It shows up as an invalid or non-wallet transaction id.

http://i.imgur.com/NYMJbOZ.png

Yep, it got stuck.

This transaction is failing to pass verification so the block gets rejected and the peer banned for being malicious.

http://florincoin.info/explorer/tx/?txid=6cba295dbd61a81c35ab994a94b6e758782661b976ee015043ea2314f84535bf

Can someone with a synced node run this command in either debug console or florincoind?


While I was debugging that I also deleted my chainstate index so now it's redoing the entire blockchain, yay waiting.

I've not looked into qt yet and I think it may have gotten stuck again.

@bitspill does it seem successfully updated other than QT?

That is what I figured

I am honestly glad that you are updating it, as the main reason I wanted it updated was because it was impossible to build 64 bit Mac binaries on the old 0.8.7 version. I plan on keeping an eye on the repository and making pull requests to pull in any changes that litecoin makes

That's really solid of you Ostler .  It's more of boat race and we are all on the same ship.  (arghhhhh *pirate voice of course*)

Perhaps you could continue to try and learn.  Then you can compare and contrast with Bitspill. 

The more the Merry .

Just to clarify, I didn't mean that as "racing against you" I meant it in the sense that the daemon is racing through the blockchain.

Current height ~750k

I wish you the best of luck Bitspill, to be honest updating the code base was a little out of my leauge as I have never worked with C++, so I hope you are able to get this up and running

If you get stuck again, just post here and create an issue on Github and I will try to take a look at it.

And the race continues...

I'm pretty sure I found the problem while pondering it at work. Can someone run this command in their debug console or florincoind and post the output