Wallet Compile Service

[CHAOSiTEC]

I think I have explained my point pretty well. The context you are talking about is irrelevant, since my point would be valid in any context you could possibly try to invoke. Should I repeat it again that validating one executable doesn't in the least deprive you of the capability to inject some arbitrary code next time (or any time you see fit)? In which context this statement wouldn't be valid?

If the same code is compiled on different architectures (e.g. Intel vs AMD), you may get different executables even if you are you using the same compiler flags

Seems like you do not fully comprehend how compilers work.. if you optimise for a specific cpu then yes.. if you use exactly the same optimisations the compiler (of course has to be compiled from the exact same codebase) will produce exactly the same executable the cpu does not have anything to do with how code is optimised.. only what compiler optimisations you use... please find someone that knows about compilers and ask them..

Actually it's not irrelevant since you started talking about proof

Regarding compilers and optimization flags, I guess you may want to start your learning curve from here. There is a whole bunch of compiler flags which produce different binaries for different architectures. You may even get different results depending on whether you compile source files in a batch mode (multiple files at once) or each file separately...

I've started talking about the lack of proof, to be precise. As you can see, this perfectly validates my point

notice what ive hilighted.. to compile for a specific architecture IS an optimisation, you decide WHEn you compile to optimise, and what to optimise, even if you want to optimise for a SPECIFIC architecture see this link https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

as i said, if you USE THE SAME optimisations on a given program compile, with the same libraries compiled with the same compiler from the same source, you will get identical executables.... platform optimisations are only activated IF you either ask for a compile for current platform, or for a specific platform.. the compiler will not decide by itself what to optimise in regard to cpu if you ask for a generic cpu type.. i.e. compile for i686 or amd64 will produce the exact same code. as long as we use the exact same versions for libraries and compilers.

[1714761771]

1714761771

[1714761771]

1714761771

[deisik]

I think I have explained my point pretty well. The context you are talking about is irrelevant, since my point would be valid in any context you could possibly try to invoke. Should I repeat it again that validating one executable doesn't in the least deprive you of the capability to inject some arbitrary code next time (or any time you see fit)? In which context this statement wouldn't be valid?

If the same code is compiled on different architectures (e.g. Intel vs AMD), you may get different executables even if you are you using the same compiler flags

Seems like you do not fully comprehend how compilers work.. if you optimise for a specific cpu then yes.. if you use exactly the same optimisations the compiler (of course has to be compiled from the exact same codebase) will produce exactly the same executable the cpu does not have anything to do with how code is optimised.. only what compiler optimisations you use... please find someone that knows about compilers and ask them..

Actually it's not irrelevant since you started talking about proof

Regarding compilers and optimization flags, I guess you may want to start your learning curve from here. There is a whole bunch of compiler flags which produce different binaries for different architectures. You may even get different results depending on whether you compile source files in a batch mode (multiple files at once) or each file separately...

I've started talking about the lack of proof, to be precise. As you can see, this perfectly validates my point

notice what ive hilighted.. to compile for a specific architecture IS an optimisation, you decide WHEn you compile to optimise, and what to optimise, even if you want to optimise for a SPECIFIC architecture see this link https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

I guess you should read again what I've written, namely

If the same code is compiled on different architectures (e.g. Intel vs AMD), you may get different executables even if you are you using the same compiler flags

That is, the same compilation flags may produce different binary codes, since an architecture you compile on (or for) may not support instruction sets which are used for optimizations invoked with these flags (cf. SSE vs 3DNow!). Optimization flags may be the same (think -O3), the output is not (even if the compiler version is the same)...

Is it really so hard to understand, and what are you trying to argue with?

[CHAOSiTEC]

I think I have explained my point pretty well. The context you are talking about is irrelevant, since my point would be valid in any context you could possibly try to invoke. Should I repeat it again that validating one executable doesn't in the least deprive you of the capability to inject some arbitrary code next time (or any time you see fit)? In which context this statement wouldn't be valid?

If the same code is compiled on different architectures (e.g. Intel vs AMD), you may get different executables even if you are you using the same compiler flags

Seems like you do not fully comprehend how compilers work.. if you optimise for a specific cpu then yes.. if you use exactly the same optimisations the compiler (of course has to be compiled from the exact same codebase) will produce exactly the same executable the cpu does not have anything to do with how code is optimised.. only what compiler optimisations you use... please find someone that knows about compilers and ask them..

Actually it's not irrelevant since you started talking about proof

Regarding compilers and optimization flags, I guess you may want to start your learning curve from here. There is a whole bunch of compiler flags which produce different binaries for different architectures. You may even get different results depending on whether you compile source files in a batch mode (multiple files at once) or each file separately...

I've started talking about the lack of proof, to be precise. As you can see, this perfectly validates my point

notice what ive hilighted.. to compile for a specific architecture IS an optimisation, you decide WHEn you compile to optimise, and what to optimise, even if you want to optimise for a SPECIFIC architecture see this link https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

I guess you should read again what I've written, namely

If the same code is compiled on different architectures (e.g. Intel vs AMD), you may get different executables even if you are you using the same compiler flags

That is, the same compilation flags may produce different binary codes, since an architecture you compile on (or for) may not support instruction sets which are used for optimizations invoked with these flags (cf. SSE vs 3DNow!). Flags may be the same (not even speaking about compiler version), the output is not...

Is it really so hard to understand, and what are you trying to argue with?

Host optimisation.. meaning if you compile for a generic group of crus result will be the same.. if you start adding more specific cpu optimisations then you are also optimising.. platform specific else your arguing that you cannot compile for different crus on the same machine..

Also see https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md


DETERMISTIC recognise that word?

Means you can verify by compiling yourself that a given executable was compiled from the same source will give same end result.

[deisik]

DETERMISTIC recognise that word?

Means you can verify by compiling yourself that a given executable was compiled from the same source will give same end result.

You are trying to clutch at minute details while choosing to ignore the major issue, which I have to repeat again. It doesn't matter if someone is able to produce the same executable since in no case this can prevent you from changing the code next time. Thereby, it can't be a proof the way you want it to look...

Further, I think I can safely assume that those who can follow the steps required to reproduce the same binary from source code can pretty much compile for themselves

[CHAOSiTEC]

DETERMISTIC recognise that word?

Means you can verify by compiling yourself that a given executable was compiled from the same source will give same end result.

You are trying to clutch at minute details while ignoring to address the major issue, which I have to repeat again. No matter if someone is able to produce the same executable, this in no case prevents you from changing the code next time...

Thereby, it can't be a proof the way you want it to look

And that is why I'm trying to tell you that the only way to make proof is by having source compiled by 2 different people... and I didn't say only once... you seem so determined to proof me wrong and argue about details you clearly have no real grasp of, it is quite simple I provide  a service use it if you need this service.. if you want get someone else also do a compile verify the sources are the same... all your points are basically moot and therefore you only try to show yourself as right no matter the facts... ergo troll

[deisik]

DETERMISTIC recognise that word?

Means you can verify by compiling yourself that a given executable was compiled from the same source will give same end result.

You are trying to clutch at minute details while ignoring to address the major issue, which I have to repeat again. No matter if someone is able to produce the same executable, this in no case prevents you from changing the code next time...

Thereby, it can't be a proof the way you want it to look

And that is why I'm trying to tell you that the only way to make proof is by having source compiled by 2 different people... and I didn't say only once... you seem so determined to proof me wrong and argue about details you clearly have no real grasp of, it is quite simple I provide  a service use it if you need this service.. if you want get someone else also do a compile verify the sources are the same... all your points are basically moot and therefore you only try to show yourself as right no matter the facts... ergo troll

As I've explained earlier, you would more often than not get different binaries even if they are actually compiled from the same source, for a multitude of reasons, some of which I have mentioned. To sum it up, you claim innocence in a world where the assumption of innocence usually doesn't end very well...

And surely is not the way to go

[CHAOSiTEC]

DETERMISTIC recognise that word?

Means you can verify by compiling yourself that a given executable was compiled from the same source will give same end result.

You are trying to clutch at minute details while ignoring to address the major issue, which I have to repeat again. No matter if someone is able to produce the same executable, this in no case prevents you from changing the code next time...

Thereby, it can't be a proof the way you want it to look

And that is why I'm trying to tell you that the only way to make proof is by having source compiled by 2 different people... and I didn't say only once... you seem so determined to proof me wrong and argue about details you clearly have no real grasp of, it is quite simple I provide  a service use it if you need this service.. if you want get someone else also do a compile verify the sources are the same... all your points are basically moot and therefore you only try to show yourself as right no matter the facts... ergo troll

As I've explained earlier, you would more often than not get different binaries even if they are actually compiled from the same source, for a multitude of reasons, some of which I have mentioned. To sum it up, you claim innocence in a world where the assumption of innocence usually doesn't end very well...

And surely is not the way to go

And we are back to the same discussion again about compilers... to sum it up..

Your guilty until proven otherwise.. you cannot trust people... and we might as well expect you to cheat on someone tomorrow...

In my country we have a saying... thief thinks everyone is stealing..

So I might as well assume your going to cheat someone out of coins..

At least I have some faith in people.. I double check but I am not paranoid.. you on the other hand assume everyone is guilty.. therefore you should not use any wallets since who knows someone on the inside might tamper with the official bitcoin wallets. So I would suggest to keep away from any cryptocoin.

[defunctec]

DETERMISTIC recognise that word?

Means you can verify by compiling yourself that a given executable was compiled from the same source will give same end result.

You are trying to clutch at minute details while ignoring to address the major issue, which I have to repeat again. No matter if someone is able to produce the same executable, this in no case prevents you from changing the code next time...

Thereby, it can't be a proof the way you want it to look

And that is why I'm trying to tell you that the only way to make proof is by having source compiled by 2 different people... and I didn't say only once... you seem so determined to proof me wrong and argue about details you clearly have no real grasp of, it is quite simple I provide  a service use it if you need this service.. if you want get someone else also do a compile verify the sources are the same... all your points are basically moot and therefore you only try to show yourself as right no matter the facts... ergo troll

As I've explained earlier, you would more often than not get different binaries even if they are actually compiled from the same source, for a multitude of reasons, some of which I have mentioned. To sum it up, you claim innocence in a world where the assumption of innocence usually doesn't end very well...

And surely is not the way to go

You raise issue's that are well known in the world.

Trust.

Trust is needed to conduct business, no trust no business.

Banks lend large amounts of money to people for over 30 years. There's a huge amount of trust needed here, but banks take precautions, they vet the person, check his credit history.

You as a customer to chaositec can hire someone to vet his code (If you're not able to yourself).

Fundamental business operation is based on trust, it's that simple. If you can't trust people, good luck.
If you don't trust chaos, don't use his service, but for everyone else, i can recommend chaositec.

[deisik]

At least I have some faith in people.. I double check but I am not paranoid.. you on the other hand assume everyone is guilty.. therefore you should not use any wallets since who knows someone on the inside might tamper with the official bitcoin wallets. So I would suggest to keep away from any cryptocoin.

In fact, you are not very far from truth. I had been successful at trading (multiplied my capital a few times), but it was pure luck that I got my money back from Bter, a Chinese exchange that got allegedly hacked in February, 2015. After that, Crapsea went belly up, but I had already withdrawn my funds from there...

Because it is not a matter of if but rather when you get scammed or otherwise lose your money in the Bitcoin world

[deisik]

You raise issue's that are well known in the world.

Trust.

Trust is needed to conduct business, no trust no business.

Banks lend large amounts of money to people for over 30 years. There's a huge amount of trust needed here, but banks take precautions, they vet the person, check his credit history

Yeah, and you know, they never forget to take collateral, which covers the bank losses in case their client defaults on his debt (and often with a vengeance at that). Just business, as you like it...

So, no need to paint banks as charities when they are ruthless vultures in reality

[CHAOSiTEC]

So I'm still thinking what are you doing in this thread, you should be posting in ALLE threads especially those involving escrow because.. you cannot trust the escrow either with your line of thinking...

Or any service involving paying with bitcoins..

Nor goods sold for bitcoins.. because who knows they might scam you tomorrow...

You sound more and more like  a guy that should stick to paper money and creditcard

[deisik]

So I'm still thinking what are you doing in this thread, you should be posting in ALLE threads especially those involving escrow because.. you cannot trust the escrow either with your line of thinking...

I'm wondering if you really don't understand what people are risking using your service, or you are deliberately trying to make it look harmless?

So, anyone using this service be warned and aware of the risks it possibly involves

[CHAOSiTEC]

So I'm still thinking what are you doing in this thread, you should be posting in ALLE threads especially those involving escrow because.. you cannot trust the escrow either with your line of thinking...

I'm wondering if you really don't understand what people are risking using your service, or you are deliberately trying to make it look harmless?

So, anyone using this service be warned and aware of the risks it involves

It seems more to me that I have at some point stepped on your toes. Might have been an alt.. you, without knowing who I am, basically point a finger at me, and accuse me of wanting to steal people's coins. And why should people care what you think... I'm looking at your trust level.. people have trusted me with their wallets because I was helping them recover their coins.. I could, if I wanted to,  have stolen those and claimed I could not recover them. But I am not that kind of person.. I recovered that persons coins, and send all of them back to his new wallet.. I am known to help people out with no regards of earning a coin out of their misery.

So tell me once again, did I bother one of your alts.. because it does seem like your on some kind of vendetta.

I welcome everyone to look through my posting history.. that talks for more than cheap words from someone who doesn't really know me.. and pretends to know how compilers and their optimisations work.. because you surely seem clueless.. you have tried every attack angle you can think of.. and when I put forward an article about gitian written by the devs of bitcoin on how the compile process is verifiable by doing another compile on another machine you decide to ignore it..

[freedoge.co]

just hit ignore on deisik, he is just troll and signature spammer who likes to argue with anyone 

[deisik]

So I'm still thinking what are you doing in this thread, you should be posting in ALLE threads especially those involving escrow because.. you cannot trust the escrow either with your line of thinking...

I'm wondering if you really don't understand what people are risking using your service, or you are deliberately trying to make it look harmless?

So, anyone using this service be warned and aware of the risks it involves

It seems more to me that I have at some point stepped on your toes. Might have been an alt.. you, without knowing who I am, basically point a finger at me, and accuse me of wanting to steal people's coins. And why should people care what you think... I'm looking at your trust level.. people have trusted me with their wallets because I was helping them recover their coins.. I could, if I wanted to,  have stolen those and claimed I could not recover them. But I am not that kind of person.. I recovered that persons coins, and send all of them back to his new wallet.. I am known to help people out with no regards of earning a coin out of their misery.

So tell me once again, did I bother one of your alts.. because it does seem like your on some kind of vendetta.

You can rest assured, I've never encountered you here before (if only your alts, lol), there is nothing personal. My trust score is irrelevant since I don't sell anything, but I've seen users with much higher trust than yours (e.g. a certain TradeFortress) which didn't stop them from scamming on people in the end. And just like you, they all claimed innocence and trustworthiness...

As I said, better safe than sorry

[CHAOSiTEC]

So I'm still thinking what are you doing in this thread, you should be posting in ALLE threads especially those involving escrow because.. you cannot trust the escrow either with your line of thinking...

I'm wondering if you really don't understand what people are risking using your service, or you are deliberately trying to make it look harmless?

So, anyone using this service be warned and aware of the risks it involves

It seems more to me that I have at some point stepped on your toes. Might have been an alt.. you, without knowing who I am, basically point a finger at me, and accuse me of wanting to steal people's coins. And why should people care what you think... I'm looking at your trust level.. people have trusted me with their wallets because I was helping them recover their coins.. I could, if I wanted to,  have stolen those and claimed I could not recover them. But I am not that kind of person.. I recovered that persons coins, and send all of them back to his new wallet.. I am known to help people out with no regards of earning a coin out of their misery.

So tell me once again, did I bother one of your alts.. because it does seem like your on some kind of vendetta.

You can rest assured, I've never encountered you here before (if only your alts, lol), there is nothing personal. My trust score is irrelevant since I don't sell anything, but I've seen users with much higher trust than yours (e.g. a certain TradeFortress) which didn't stop them from scamming on people in the end. And just like you, they all claimed innocence and trustworthiness...

As I said, better safe than sorry

Well.. at least I know I do not have any alts.

But I have already pointed  out how to double check... you on the other hand have only tried to spread fud.

And I have said what needs to be said.. anyone can double check by comparing same compiler from someone else.. your argument about compilers producing different result based on where they run and not about which optimisations are used is still fud. Because compilations are and will always be reproduce able under same conditions for source, library and compiler ... and host architecture does nothing to change those facts..

[deisik]

And I have said what needs to be said.. anyone can double check by comparing same compiler from someone else.. your argument about compilers producing different result based on where they run and not about which optimisations are used is still fud. Because compilations are and will always be reproduce able under same conditions for source, library and compiler ... and host architecture does nothing to change those facts...

Lol, it doesn't only depend on host architecture (welcome -O3), it actually depends on the compile-time environment, here and now, on the same machine. I understand you think that compiling is totally deterministic, but this is simply not the case. You are just flat-out wrong about that. I didn't want to raise this issue again but you obviously seem to be asking for more, lol. For example, optimization usually requires a lot of memory, and still more memory for higher optimisation methods. If memory allocation fails (e.g. due to a lot of other memory hungry processes), then the compiler may omit some optimizations, which results in a different binary that would be produced if all optimizations had been made...

Does this also pass as FUD? If not, what about the "verification" process of double check you suggest to run and its results?

[CHAOSiTEC]

And I have said what needs to be said.. anyone can double check by comparing same compiler from someone else.. your argument about compilers producing different result based on where they run and not about which optimisations are used is still fud. Because compilations are and will always be reproduce able under same conditions for source, library and compiler ... and host architecture does nothing to change those facts...

Lol, it doesn't only depend on host architecture (welcome -O3), it actually depends on the compile-time environment, here and now, on the same machine. I understand you think that compiling is totally deterministic, but this is simply not the case. You are just flat-out wrong about that. I didn't want to raise this issue again but you obviously seem to be asking for more, lol. For example, optimization usually requires a lot of memory, and still more memory for higher optimisation methods. If memory allocation fails (e.g. due to a lot of other memory hungry processes), then the compiler may omit some optimizations, which results in a different binary that would be produced if all optimizations had been made...

Does this also pass as FUD? If not, what about the "verification" process you suggest to run and its results?

And again I point you to gitIan.. and the compile process that uses fake time...

[CHAOSiTEC]

Gitian is the deterministic build process that is used to build the Bitcoin Core executables. It provides a way to be reasonably sure that the executables are really built from the source on GitHub. It also makes sure that the same, tested dependencies are used and statically built into the executable.

Multiple developers build the source code by following a specific descriptor ("recipe"), cryptographically sign the result, and upload the resulting signature. These results are compared and only if they match, the build is accepted and uploaded to bitcoin.org.

Since you apparently do not read very well I have for your enjoyment pasted part of the bitcoin build process using gitian.

[deisik]

Gitian is the deterministic build process that is used to build the Bitcoin Core executables. It provides a way to be reasonably sure that the executables are really built from the source on GitHub. It also makes sure that the same, tested dependencies are used and statically built into the executable.

Multiple developers build the source code by following a specific descriptor ("recipe"), cryptographically sign the result, and upload the resulting signature. These results are compared and only if they match, the build is accepted and uploaded to bitcoin.org.

Since you apparently do not read very well I have for your enjoyment pasted part of the bitcoin build process using gitian.

Bitcoin Core is not the same as Bitcoin wallet which is based on Qt framework (at least, the last time I checked), right? I assume that it uses these binaries as a backend, but what about the wallet itself? Isn't that what you offer precisely?

In other words, where is Gitian for Bitcoin wallet (if that was your point)?