Jump to content

Tomas Brod

MEMBER
  • Content Count

    22
  • Joined

  • Last visited

  • Time Online

    53m 22s

Community Reputation

35 Great Reputation

Social Info

About Tomas Brod

  • Rank
    Member

Personal Information

  • Gender
    Male
  • Location
    Martin
  • Country
    Slovakia

Contact Methods

  • Website
    http://tbrada.eu/

Hardware

  • Operating System
    Linux
  • Motherboard
    MSI B350 PC MATTE
  • Processor
    AMD Ryzen 1700
  • RAM
    DDR4, not samsung, 16G
  • SSD / HDD Storage
    120 GB SSD SATA M2, 250 GB HDD, 500 GB HDD, 3 TB HDD

Recent Profile Visitors

750 profile views
  1. INVOICE Reviewing changes and debugging Oct 5h Not much, only one code change. TomasBrod, address SL77ns581aSyHsFWDYwSVS4RT3mY4icjPB
  2. INVOICE Constant Block Rewards experimental code: April, 4.5 hours. Monitoring superblock woring (no code): April, 3.5 Hours Addnode command and debugging address sharing issues "aries": April, 2 hours Blockindex Investor cpid corruption debugging/fix: April, 3 hours Superblock Contract Forwarding, testing: April/May, 21 hours (more than I should have) Remove unused fields from appcache, fix triplicate polls: April, 1 hour Added bunch of data acquisition commands: Feb/Mar/April, 10 hours TomasBrod, address Rz6LRCd3LWdEQX8F9eWK66rfm9YkTL51vT Signed version as paste here
  3. Tomas Brod

    Text Pastebin

    -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256   INVOICE   * Constant Block Rewards experimental code: April, 4.5 hours. * Monitoring superblock woring (no code): April, 3.5 Hours * Addnode command and debugging address sharing issues "aries": April, 2 hours * Blockindex Investor cpid corruption debugging/fix: April, 3 hours * Superblock Contract Forwarding, testing: April/May, 21 hours (more than I should have) * Remove unused fields from appcache, fix triplicate polls: April, 1 hour * Added bunch of data acquisition commands: Feb/Mar/April, 10 hours   TomasBrod, Tomáš Brada, address Rz6LRCd3LWdEQX8F9eWK66rfm9YkTL51vT   signed by previous invoice address SL77ns581aSyHsFWDYwSVS4RT3mY4icjPB and my GPG key signature: IMIEheBcWib+X9oqgkd5jd19jb8Rv0rb4Bcfwcb2vaH4hAbZexeGjAt05yaqe5RwPsVcNJx6oaeVH56bDKSwRzg= -----BEGIN PGP SIGNATURE-----   iHUEAREIAB0WIQRlxdlz3mOV3MknUMViNjLKI8C1kAUCWu7CfQAKCRBiNjLKI8C1 kK2MAP9C4Doc+3wpJw/0NttyNX4vFltXKdfA8KOAyZm7iMZuLgD/Sf+Iwf4MMwLf sX+Cbxh/YzqUqqPToRlv7O1VYgE5fN4= =2YSU -----END PGP SIGNATURE-----  
  4. I suggest you to wait few weeks. I am sorry for the inconvenience. This is a known problem which is/was happening right now.
  5. This error comes when the local blockchain index is corrupted. This happens quite often, unfortunately. The solution is to delete all files from the data directory, EXCEPT walletbackups folder, gridcoinresearch.conf and wallet.dat. Backup your wallet, to be safe. Then when you start the wallet again, the error should be gone. To speed up sync use the download chain option from the menu. No blkindex.dat file will be created, it is just in error message.
  6. INVOICE Research and work on fixing the recent forking issues: Jan/Feb 2018, 25 hours. Various contributions to strengthen the security during Dec17/Jan18, 29 hours. Unreleased user interface and stats additions during nov-jan, 8 hours. TomasBrod, address SL77ns581aSyHsFWDYwSVS4RT3mY4icjPB Signed version as paste here
  7. Tomas Brod

    Text Pastebin

    -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256   INVOICE   * Research and work on fixing the recent forking issues: Jan/Feb 2018, 25 hours. * Various contributions to strengthen the security during Dec17/Jan18, 29 hours. * Unreleased user interface and stats additions during nov-jan, 8 hours.   TomasBrod, Tomáš Brada, address SL77ns581aSyHsFWDYwSVS4RT3mY4icjPB   signed by previous invoice address SFr8UGhJmmYFKrQAr7JoP7QpuSFFjvbY7K and my GPG key   Signature: IBUopTfJiL4Z7jTa6lWVX9V2+v5hgm8f108VPFWC2BW8Guj+IeJX7UmW4C+kyhMrrHwhpd4oHXn2PKZIcz2EbhU= -----BEGIN PGP SIGNATURE-----   iHUEAREIAB0WIQRlxdlz3mOV3MknUMViNjLKI8C1kAUCWnc7uQAKCRBiNjLKI8C1 kIdLAP9cu392a8O6z5b9drG6unaxswnLuOYz5k8vnIbh4yUZgQD+JJ5l4nqElA9x qKOZ61og79DvbKhape3jNu1RvrJ4DOw= =uWDe -----END PGP SIGNATURE-----  
  8. The distributed storage and DHT keywords got me interested. The ambitions are great! Can I buy something right now? The min 2 BTC investment is too high. I will copy some code and ideas when you have something.
  9. Tomas Brod

    Moowrap

    Let me bring a similar-themed project to general attention. Anderson Attack Which is/was a practical demonstration of a attack algorithm on a specific cipher (A5/1).
  10. Tomas Brod

    Moowrap

    A poll has been created in topic of removing this project from the white-list.
  11. The poll has been created. Transaction There already exist thread on Moowrap, I will cross-post there. The idea came from another reddit thread.
  12. For the stakeminer: I looked at PIVX/src/miner.cpp and I can say that it is very similar to what we had (kernel v1/v3). Comment "// ppcoin: if coinstake available add coinstake tx" suggests that it is taken from PPCOIN codebase. At this point, our stakeminer is higher quality as the code-flow is untangled. And they are using, with some minor differences (constants, order...) THE SAME KERNEL as we currently do. For the masternodes: My observations suggest that there is no need for such masternodes. Again, there are enough nodes to support the flow of blocks and transactions. Even with most of the bootstrap mechanisms defunct (blame admin), there are enough nodes with public IP addresses to support a bootstrap. Every wallet there is in gridcoin is a full nodes, as there is no light or miner optimized wallet developed for gridcoin yet. The nature of P2P (that was inherited from bitcoin and purposely crippled) enables discovery of further, faster and closer connections as soon as at least one connection is made (via bootstrap).
  13. Yeah, but the CRC32 (or sha256 if boinc would provide it) is not going to help in that. The CRC32 is for the original file. Then this file is modified (filtered and consolidated). From definition of hash function, crc32 of this new file will not (most likely) match the new file. The old crc32 has no correlation to the filtered file. The filtered file can be verified only by downloading the original file (matching the crc), performing the same filtering+consolidation and comparing it (or it's hash) to the file in question. I understand. But do you yet have an idea of how these subsets will be selected? In other words What makes an ordinary node into the 500 neural nodes? (and then the 50 core...) If not, than that is ok. We can think about it later. (or use subset selection from dwp ;) ) What makes you select x11 instead of a standard sha256 hash, or is it just and example? What purpose will the stamping with orig crc, orig-x11, and new x-11 serve, how this info is going to be used? Lets assume everything went fine and all of the 50 nodes independently fetch equal files and come up with equal hashes. Will they all share this info to the 100 node validators set? Now do I understand it correctly that the 10% (core) will each download/process all projects stat and the 20% (validators) only one each? What is the purpose of this distinction? Do I understand correctly that 10% (core) will not vote on their file, only the validators? What would be the purpose of downloading by core 10% then? Once the validators reach vote consensus on their stamp (or even final stamp), the rest of NN (and network) can trust this. I agree that, assuming the validators worked with secure data sources, that this may secure. Have you thought about what makes the nodes actually download and process the files? Because they can just listen for another vote and repeat it without expending network and cpu. (I did - dwp)
  14. This is very hard. If you are rich in the real world, you can easily become poor and benefit. If you are poor, you must somehow earn the money to become rich. It is even harder in P2P, because not only one rich can become one poor, but moreover one rich can become thousands of poor. (Sybil attack)
  15. I agree that WU hoarding is not a big issue. However the problem of determining progression of project is significant. I would not call it flaw, but rather challenge. How to determine the progression of a project? By number of project credits gained (globally). I don't think this is a viable route as all projects are allowed to assign their credits however they want. Some projects give more credits for the same computation and some very little. In this approach, it would be most viable to crunch Collatz exclusively. Assume that each day every project progressed evenly: but that is the situation we have now. Allow grc admin (or committee) to assign how important every project is. Ye, seriously. Some projects do research "on the knee" and in narrow band (yafu?), while other do larger spectrum (WCG). I thin you should be more rewarded for crunching WCG than (something other). But this approach opens a lightning storm on the committee. Can you please elaborate on this?

Cryptocurrenytalk Logo

 

News, information, and discussions about cryptocurrencies, blockchains, technology, and events. Blockchaintalk is your source for advice on what to mine, technical details, new launch announcements, and advice from trusted members of the community. Cryptocurrencytalk is your source for everything crypto. We love discussing the world of cryptocurrencies.

 

   
×

Important Information

By using CRYPTOCURRENCYTALK.COM, you agree to our Terms of Use.