Key generation question ..

[ChiBitCTy]

Sol Noctis coins sold their second set of funded coins recently and we’ve seen some very troubling things going on. The question I have is, why would they possibly choose to generate the keys the way they did? Is it just a lazy way of doing it, or is there something possibly fishy about it? Confused a lot of really smart dudes too (I smell potential scam). The info can be found in the last post ..thanks in advance! https://bitcointalk.org/index.php?topic=5231305.100

[ranochigo]

Might be incompetent as well. I find it hard to believe that they would include a non-WIF key, because that includes extra steps to import it into any wallets and use it. At the very least, they should provide a key that is widely supported by the various wallets, be it WIF or just mini-private key. The private key still corresponds, so it is more of a making it harder for the user to sweep their coins rather than an outright scam.

[ChiBitCTy]

Might be incompetent as well. I find it hard to believe that they would include a non-WIF key, because that includes extra steps to import it into any wallets and use it. At the very least, they should provide a key that is widely supported by the various wallets, be it WIF or just mini-private key. The private key still corresponds, so it is more of a making it harder for the user to sweep their coins rather than an outright scam.

Well I believe that is part of it..others have done this same thing before. That thread was started when someone's unpeeled coin had funds moved off it, then were put back on a few days later..and the company has no explanation for it.  My thoughts are they accidently did it, but that also means they've stored the keys. I think they panicked when we brought this to their attention so they funded it back in hopes of us just letting it go.  

Making it hard to redeem gives them time to sell out of inventory.  It also will prevent most buyers from sweeping as the majority will have no clue what to do or who to ask for help. Some will just say "f it, I'll deal with it later, it's not a ton of bitcoin atm"  This scam tactic has been used several times before already and very recently by a mint in S Korea.  The seller has been shady and not very cooperative about it all from the start and has already stated.. "if it wasn't bought from us directly we will not honor moved/lost funds" .. they sent these coins out to a lot of retailers, which then, by their rules, limits their liability.  They also used a new company to generate the keys from the previous version. Having scam busted coin companies, spending countless hours doing so ..I've gotten good at spotting the signs..they are all there.

btw I appreciate your input!

[pooya87]

Might be incompetent as well. I find it hard to believe that they would include a non-WIF key, because that includes extra steps to import it into any wallets and use it. At the very least, they should provide a key that is widely supported by the various wallets, be it WIF or just mini-private key.

The method would have made sense if it were providing some benefit, keep in mind that mini-private key format (starting with S) didn't exist before someone invented it but that method provides a big benefit that it cuts the private key length (compared to a WIF) by 50% or more in case of shorter keys. This method on the other hand only reduces the length by 7 characters but the total is still very high (44 chars based on the example posted in the other thread) so it can't really be called beneficial.

[ranochigo]

The method would have made sense if it were providing some benefit, keep in mind that mini-private key format (starting with S) didn't exist before someone invented it but that method provides a big benefit that it cuts the private key length (compared to a WIF) by 50% or more in case of shorter keys. This method on the other hand only reduces the length by 7 characters but the total is still very high (44 chars based on the example posted in the other thread) so it can't really be called beneficial.

I don't think it makes much sense either, to consider this a benefit at all. I've researched on this coin prior, before the warning thread and I always thought that it would've just been a WIF private key. AFAIK, they never did specify how to import those keys so I'm assuming that they never intended their users to redeem the coins easily.

[LoyceV]

The question I have is, why would they possibly choose to generate the keys the way they did? Is it just a lazy way of doing it, or is there something possibly fishy about it?

I don't think it's being lazy:

It looks like Sol Noctis took a private key in hex format and converted it to base58 without any of the necessary preprocessing to generate a WIF-encoded key. The 0x80 mainnet flag is not prepended, nor is the 0x01 flag to denote a compressed public key appended. Lastly the checksum is missing.

It sounds like more work for them to generate the private key, which they needed to know the funding address. I can't think of any reason to use a non-standard key format.

My thoughts are they accidently did it, but that also means they've stored the keys.

I've never owned any collectible coins, partially because of privacy, but also because I couldn't possibly be sure I am the only one who knows the private key. I'd always wonder: "what if ....".

This makes it even worse:

I learned that the hologram and assembly was done by "another firm" but that is all I know.

Even if you trust the coin creator, it turns out there's an unknown third party that had (or has!) access to all private keys!

I think they panicked when we brought this to their attention so they funded it back in hopes of us just letting it go.

This doesn't match the events on the blockchain:
2019-11-07 10:02: coin funded with 0.001 BTC
2019-12-14 02:53: coin funded with 0.014 BTC
2020-02-20 11:31: 0.015 BTC (including fees) swept (by suspicious unknown party)
2020-02-20 11:31: coin funded with 0.001 BTC, coming from the address the 0.015 BTC was withdrawn to.
2021-01-07 17:10: 0.001 BTC (including fees) swept (by cwil, to secure funds after the private key was published)

Sweeping 0.015 BTC happened in the same block as depositing back 0.001 BTC, so it can't have anything to do with bringing it to their attention.
I wonder why they didn't sweep 0.014 BTC only. With coin control, it's very easy to leave the 0.001 BTC when sweeping the newer funds.

Collectibles are like the opposite of "not your keys, not your coins".

[ChiBitCTy]

Thank you guys very much and extra thanks to Loyce for doing all of that research. I obviously had my timeline mixed up a bit. Rushed it a little as I spent a couple hours researching/exposing another potential scam coin at the same time.

Yeah Loyce I feel you about the not your keys not your coins.  I have coins in my collection I trust, and others not so much, and willing to take the risk..smart or not.  But I am souring on everything a bit.  The amount of time I've had to spend researching and exposing these scams and potential scams is ridiculous.

I am fully convinced the keys were generated like they were to set up a sweep of everything in due time. The coins moving under a sealed hologram tells you only one thing...they stored all the keys. This all reminds me very much of Prypto CryptoScratchCards and HyperionGold "companies"..they both had ridiculous redemption processes and took their time to make sure they sold their inventory before they pulled the rug.

Another thing that is really making me questions things even more so, all of a sudden a bunch of peeled Sol Noctis coins both first and second versions popped up on ebay.. a bunch of them.. so I think they peeled them all and likely took the keys from a database and I think they just copy/pasted maybe one extra address on accident.

[LoyceV]

Yeah Loyce I feel you about the not your keys not your coins.  I have coins in my collection I trust, and others not so much, and willing to take the risk..smart or not.  But I am souring on everything a bit.

How about creating "DIY collectibles"? You buy a coin, it comes with a hologram, and you create and print your own private key to store under the hologram. That way you know for sure it's secure, but you can't ever resell it.
An alternative would be if you provide the coin creator with a BIP38 encrypted private key. That way the coin can be completed before you buy it, and only you can access the funds. But it still means you can't resell it.
The more I think about it, the more I'm convinced it's all just a bad idea

Another thing that is really making me questions things even more so, all of a sudden a bunch of peeled Sol Noctis coins both first and second versions popped up on ebay.. a bunch of them.. so I think they peeled them all and likely took the keys from a database and I think they just copy/pasted maybe one extra address ton accident.

Do you have the addresses of those coins? If so: where they emptied around the same time?

[ChiBitCTy]

Yeah Loyce I feel you about the not your keys not your coins.  I have coins in my collection I trust, and others not so much, and willing to take the risk..smart or not.  But I am souring on everything a bit.

How about creating "DIY collectibles"? You buy a coin, it comes with a hologram, and you create and print your own private key to store under the hologram. That way you know for sure it's secure, but you can't ever resell it.
An alternative would be if you provide the coin creator with a BIP38 encrypted private key. That way the coin can be completed before you buy it, and only you can access the funds. But it still means you can't resell it.
The more I think about it, the more I'm convinced it's all just a bad idea

Another thing that is really making me questions things even more so, all of a sudden a bunch of peeled Sol Noctis coins both first and second versions popped up on ebay.. a bunch of them.. so I think they peeled them all and likely took the keys from a database and I think they just copy/pasted maybe one extra address ton accident.

Do you have the addresses of those coins? If so: where they emptied around the same time?

DIYs exist, bunch of them out there.  People like funded stuff because they don't want to have to go through the hassle or in some cases know how to do it. I don't trust myself enough yet to make a paper wallets either ( why I asked this to be a topic for the Btalk YouTube project ).

No those coins just come blank.  They look like they had been cleaned. I messaged the seller asking how they came across so many of them and got no response.

[LoyceV]

I don't trust myself enough yet to make a paper wallets either ( why I asked this to be a topic for the Btalk YouTube project ).

It's so easy
The real problem is trusting the software you use, especially since 2 out of 3 "paper wallet sites" turned into a scam.

I've been thinking about creating my own for a while now, I have an old version of the latest site that turned into a scam, but I'm not sure if it would be legal to publish it.

[HCP]

With regards to the "weird" privkey format, I'm wondering if it was some sort of coding error where, for whatever reason, the pure Hex encoded key was converted to Base58 and then printed.

They skipped the whole mainnet and compressed key bytes (ie. 0x80 + hexkey + 0x01)... and also failed to create/append the checksum bytes.

Possibly a regression bug with code where someone was testing each step in the process at some point and then didn't "uncomment" their code and/or accidently used the wrong version of a script or something?

Possibly a test batch that were accidently used/shipped instead of being destroyed?


I generally like to go with Hanlon's Razor:

never attribute to malice that which is adequately explained by stupidity

So, one would hope that the "non-standard" privkey was just a simple mistake of some sort... and not necessarily and exercise in trying to prevent people from actually redeeming their coins.


However, even ignoring the "weird" privkey format, the really troubling aspect to all of this... the coins were swept (and partially returned and then swept again)... with what appears to be an intact hologram!!?!

But then, there only seems to be this single case... although I suppose without a list of addresses it is impossible to check if this is actually an isolated case, or simply the only reported case.

[NotATether]

The question I have is, why would they possibly choose to generate the keys the way they did? Is it just a lazy way of doing it, or is there something possibly fishy about it?

I don't think it's being lazy:

It looks like Sol Noctis took a private key in hex format and converted it to base58 without any of the necessary preprocessing to generate a WIF-encoded key. The 0x80 mainnet flag is not prepended, nor is the 0x01 flag to denote a compressed public key appended. Lastly the checksum is missing.

It sounds like more work for them to generate the private key, which they needed to know the funding address. I can't think of any reason to use a non-standard key format.

Sadly there aren't many tools available that'll safely convert a private key to an address.

I'm not talking about wallets that do that for you and manage the balance in them. I mean small standalone utilities you can download from somewhere that take care of all these complexities, because it's really easy to get it wrong by hand.

[LoyceV]

Sadly there aren't many tools available that'll safely convert a private key to an address.
I mean small standalone utilities

I've used bitcoin-tool years ago, it does all kinds of conversions. But I wouldn't trust it completely without thoroughly checking the source. For practical use, when used offline, verifying several addresses with for instance Electrum should give a pretty good impression about it's reliability.

Command line options:

Code:

  --input-type : Input data type, must be one of :
      mini-private-key : 30 character Casascius mini private key
      private-key      : 32 byte ECDSA private key
      private-key-wif  : 33/34 byte ECDSA WIF private key
      public-key       : 33/65 byte ECDSA public key
      public-key-sha   : 32 byte SHA256(public key) hash
      public-key-rmd   : 20 byte RIPEMD160(SHA256(public key)) hash
      address          : 21 byte Bitcoin address (prefix + hash)
  --input-format : Input data format, must be one of :
      raw         : Raw binary
      hex         : Hexadecimal encoded
      base58      : Base58 encoded
      base58check : Base58Check encoded (most common)
  --output-type  : Output data type, must be one of :
      all              : All output types, as type:value pairs, most of which
                         are never commonly used, probably for good reason.
      mini-private-key : 30 character Casascius mini private key
      private-key      : 32 byte ECDSA private key
      private-key-wif  : 33/34 byte ECDSA WIF private key
      public-key       : 33/65 byte ECDSA public key
      public-key-sha   : 32 byte SHA256(public key) hash
      public-key-rmd   : 20 byte RIPEMD160(SHA256(public key)) hash
      address          : 21 byte Bitcoin address (prefix + hash)
  --output-format : Output data format, must be one of :
      raw         : Raw binary
      hex         : Hexadecimal encoded
      base58      : Base58 encoded
      base58check : Base58Check encoded (most common)

  --input               : Specify input data on command line
  --input-file          : Specify file name to read for input ('-' for stdin)
  --batch               : Read multiple lines of input from --input-file
  --ignore-input-errors : Continue processing batch input if errors are found.

  --public-key-compression : Can be one of :
      auto         : determine compression from base58 private key (default)
      compressed   : force compressed public key
      uncompressed : force uncompressed public key
    (must be specified for raw/hex keys, should be auto for base58)
  --network        : Network type of keys, one of :
      bitcoin
      bitcoin-testnet
      litecoin
      litecoin-testnet
      feathercoin
      feathercoin-testnet
      dogecoin
      dogecoin-testnet
      quarkcoin
      quarkcoin-testnet
      darkcoin
      darkcoin-testnet
      jumbucks
      jumbucks-testnet
  --fix-base58check : Attempt to fix a Base58Check string by changing
                      characters until the checksum matches.
  --fix-base58check-change-chars : Maximum number of characters to change
                                   (default=3)

[HCP]

Yeah, given that it's a simple c commandline tool, it's pretty easy to compile and then use it "offline"... so at worst it might just give an incorrect result for one of the conversions... but like you say, even that would be relatively easy to double check.

I was fairly sure I actually had a compiled version of that floating about somewhere, but I think I lost it in one of my system rebuilds

Thanks for reminding me that I should go and create some new ones

[ChiBitCTy]

I don't trust myself enough yet to make a paper wallets either ( why I asked this to be a topic for the Btalk YouTube project ).

It's so easy
The real problem is trusting the software you use, especially since 2 out of 3 "paper wallet sites" turned into a scam.

It is, but to do it correctly is where I struggle a bit.  Plus I don't feel like I've got the proper equipment to do so.  I want to make a coin myself so I'll have to get the equipment and learn the setup here before long. I have generated paper wallets before, but I can't remember which site it was from and with my luck probably one that ended up becoming a scam.  I moved the funds off of it some time agao.

With regards to the "weird" privkey format, I'm wondering if it was some sort of coding error where, for whatever reason, the pure Hex encoded key was converted to Base58 and then printed.

They skipped the whole mainnet and compressed key bytes (ie. 0x80 + hexkey + 0x01)... and also failed to create/append the checksum bytes.

Possibly a regression bug with code where someone was testing each step in the process at some point and then didn't "uncomment" their code and/or accidently used the wrong version of a script or something?

Possibly a test batch that were accidently used/shipped instead of being destroyed?


I generally like to go with Hanlon's Razor:

never attribute to malice that which is adequately explained by stupidity

So, one would hope that the "non-standard" privkey was just a simple mistake of some sort... and not necessarily and exercise in trying to prevent people from actually redeeming their coins.


However, even ignoring the "weird" privkey format, the really troubling aspect to all of this... the coins were swept (and partially returned and then swept again)... with what appears to be an intact hologram!!?!

But then, there only seems to be this single case... although I suppose without a list of addresses it is impossible to check if this is actually an isolated case, or simply the only reported case.

See that's the thing.  It's of course one thing to make the keys the way they did, but another entirely that coins moved off of a coin that had a hologram intact.  Most of these coins were sold to people whom aren't on this forum, have no idea how they really work etc.  So there is certainly a possibility that it's happened to others but we'll never know.  This hobby is filled with scams, so when stuff like this happens, it's a huge red alert.  Two scams that I've seen/exposed before did this same type of thing..making the items hard to sweep in hopes of no one doing so until they were ready to pull the rug.

I appreciate you guys looking in to this for me!  I am obviously not very good at this type of stuff and would have no clue where to even begin with this.

[LoyceV]

It is, but to do it correctly is where I struggle a bit.  Plus I don't feel like I've got the proper equipment to do so.  I want to make a coin myself so I'll have to get the equipment and learn the setup here before long. I have generated paper wallets before, but I can't remember which site it was from and with my luck probably one that ended up becoming a scam.

It could be as simple as using Electrum or Bitcoin Core on an offline computer to generate keys, but you'll need to make sure the system won't ever go online afterwards. So either run from RAM or even without a hard drive, or wipe/shred the disk afterwards.

[cwil]

With regards to the "weird" privkey format, I'm wondering if it was some sort of coding error where, for whatever reason, the pure Hex encoded key was converted to Base58 and then printed.

They skipped the whole mainnet and compressed key bytes (ie. 0x80 + hexkey + 0x01)... and also failed to create/append the checksum bytes.

Possibly a regression bug with code where someone was testing each step in the process at some point and then didn't "uncomment" their code and/or accidently used the wrong version of a script or something?

As I was reversing this, I was thinking that they wrote some custom software to create keys and print labels in batch, and maybe monitor those addresses.

[PrimeNumber7]

The post you cited is only how the private key is displayed, not how it was generated. There could be a number of reasons why the private key is displayed the way it is, however, this has nothing to do with the bitcoin being stolen from snarfbag's physical coin. In snarfbag's case, either the private key in question was generated in a flawed way, the manufacturing process is flawed in a way that allows an employee (or vender) acting maliciously to access the private key, the creator of the physical coin retained the private key, or the private key was somehow otherwise compromised.

Collectibles are like the opposite of "not your keys, not your coins".

Collectable physical coins are exactly this way. When someone buys a physical coin, they are trusting the manufacturer with their bitcoin the same way a trader trusts an exchange with their bitcoin. It would be prudent to require a similar amount of trust in a manufacturer before trusting them with your bitcoin.

[HCP]

As I was reversing this, I was thinking that they wrote some custom software to create keys and print labels in batch, and maybe monitor those addresses.

Yeah. There is certainly something extremely suss about this whole thing.

part of the "danger" of "pre-printed" physical coins I guess... At some point, some one other than the coin holder has had the private key... which means the coin holder has to trust that no records were ever kept.