Management of the seck256k1 dependency.

[bostontrader]

Hello folks,

I'd like to start a discussion about the management of the seck256k1 dependency. I've just wrestled with a problem because of this and it got me thinking about a better way to do this.

As you know, the code is presently embedded in the IXCoin software. And this is a very common practice with many of the other cryptos as well. However, I have found this to be a rather clumsy approach because it becomes tedious to compare the code to other variations and to apply updates. This is complicated and important code and I don't think it ought to be hacked on a project-by-project basis. But if we rely on using a definitive edition instead, is there a better way to include it as a dependency, and where is the definitive source anyway? I suggest https://github.com/bitcoin-core/secp256k1 as an obvious choice, but that still leaves the inclusion-as-a-dependency question open.

So, that said...

Is there any appetite out there to re-engineer how this dependency is included? Or is the consensus simply "suck it up and deal with it" as the best choice?

[ArchimedesIX]

Hi Thomas Agree with the definitive source. Will look at dependency question. Working on a new version and will include as a to do.  Any suggestions are apprwcuated! Sent from Yahoo Mail on Android On Thu, Jan 17, 2019 at 7:14 PM, Thomas Radloff<notifications@github.com> wrote: Hello folks, I'd like to start a discussion about the management of the seck256k1 dependency. I've just wrestled with a problem because of this and it got me thinking about a better way to do this. As you know, the code is presently embedded in the IXCoin software. And this is a very common practice with many of the other cryptos as well. However, I have found this to be a rather clumsy approach because it becomes tedious to compare the code to other variations and to apply updates. This is complicated and important code and I don't think it ought to be hacked on a project-by-project basis. But if we rely on using a definitive edition instead, is there a better way to include it as a dependency, and where is the definitive source anyway? I suggest https://github.com/bitcoin-core/secp256k1 as an obvious choice, but that still leaves the inclusion-as-a-dependency question open. So, that said... Is there any appetite out there to re-engineer how this dependency is included? Or is the consensus simply "suck it up and deal with it" as the best choice? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vladroberto]

Living in the binary of the block chain will not add to a revolutionary approach. Its seemingly more acceptable and accurate to use already written code. But the presumption remains, so its like "suk it up" with the other peers faults in their system. Post more when i get a broader understanding.

[vladroberto]

Writing a new management plan is the revolutionary approach. But how many others are doing this? If we keep stalling in forks we are overcome with faults of others on the network. I want to implement a win64 and Linux version, also an add to direct IP to the node, this is done simply by writing into the block core of IXCoin for a chain handle.