We’re already seeing people submit LLM generated security vulnerability reports in the hope they will get them a bounty.
Each can take a lot of effort to evaluate.
One just caused the curl maintainers to scrutinise their code three times before they realised it was nonsense.
The dangers of plausible output will continue to grow and grow.
Yes thats fair enough.
In this case I had already identified the lack of validation, the hard-coded key and outdated dependencies myself on a quick look through the code myself and I am certainly no security guy.
Some of the issues raised may be trivial but all in all I think this was worthwhile.
I share your general disapproval of those who use LLMs to win bounties and cause needless code reviews - please pass my sympathies to the curl maintainers.
Could this be mitigated by the maintainers themselves running this kind of check via a variety of models?
The problem with unreliable yet plausible output is that you have to understand what it is telling you, know enough to evaluate it, and expend the time to do so, including when using it to validate the output of another LLM.
True, but like coding itself, nobody said code maintenance was easy. Everything is a trade-off but it seems to me that using LLMs in this way is one more tool in the maintainers bag. Like all tools it needs knowledge and skill to use it effectively. LLMs are a very new tool, it will take time for their usage to become mature and efficient.
The problem is that using this tool enables much more ‘disinformation’ than good output at this point. And given anyone can now generate plausible information on any topic for any purpose, we are about to see an explosion in the unreliability of any source.
I don’t see the idea that before you read anything you have a trusted LLM filter it for bullshit as likely to be practical or effective.
A few, who know enough to use them will do so effectively in a gradually expanding set of fields. That’s fine and good. So far I’ve not found them useful but I accept some will.
But that doesn’t change the problems they are just beginning to create.
In this specific case, I do not think there is more disinformation than good output and hence the tool is useful for my purposes right now. The basic question I need answered is.
“Is it worth my while attempting to fork GitHub - tektite-software/omni-trezor: OMNI Wallet for Trezor with a view to applying a variable Tx fee and to address any security vulnerabilities?”
I may not have come to a decision yet but overall I feel I have a better grasp of the situation and that is partly due to the LLM output. If nothing else it confirmed my suspicions about the more obvious vulnerabilities - and as I said before, I have no particular security skills.
I think when used carefully, these will be very capable and powerful tools but with which a lot of damage can get done. - reminds me somewhat of my first unsupervised attempts on a lathe… Thankfully the damage was mainly to the workshop walls and the tool itself rather than any humans - could have been very different… But now I am confident to safely do simple turning and facing to reasonable accuracy. If I still had access to a lathe…
You saying, that is possible, to leak private key from trezor? I thought it’s impossible and always safe when u use hw wallet. Thx for clarification
IIUC the potential problem is with the Omni-Trezor software if it is used on a public or otherwise compromised PC.
A bigger problem right now is the Tx fee was fixed at a max 8000 sats - which made sense back then - shades of “640k should be enough for anyone” - Bill Gates
I asked ollama-mistral how to go about fixing this, but given the other security hassles it may be better to rewrite this from scratch. Thats probably above my skill level even with substantial AI help.
Of course if any human who is more fluent with Typescript etc wanted to help…
Thanks for this clearer explanation
bro i have my maidsafe coins on a Native segwit (bc1) bitcoin adress, please say you will implement the convertion with those in mind also.
can you view your maid safe coins on your bc1 address @sundata87 ?
as far as I know bc1 addresses are not supported by omni protocol
I can see them on omniwallets lookup, I have send them there by mistake didnt know omni dont support bc1, but someone here said it doesnt matter for the conversion of maidsafecoin to the safecoin later on beta, so Im just asking the team direct to be sure the coins are safe and not lost.
That has not come up yet, but presents and interesting angle. If they are effectively burned and you still have the original key then you can prove you owned them. So you could sign a message to receive SNT in a SAFE wallet. It’s some work mind you for you and somebody else who needs paid.
So technically I would think it’s possible
not sure Im happy with that answer , that means maybe I lost them. 5500 not a small amount for me tbh. I guess I pay for my stupidity.
I think you misunderstand. The coins are still there but you might not be able to move them.That doesn’t mean you will not receive SNT when conversion occurs.
You should be happy for 2 reasons:
Im worried because I cannot move the coins, and there is no certain the SNT conversion will include those maid on bc1, I thank maid CEO for his time to reply thats for sure. I wrote on omni protocol github 6 months ago but no one seems to bother replying to me or others, as there were few ppl asking the same thing about supporting bc1 adresses by the omni protocol.
The MAID conversion process isn’t finalised yet (so you are asking at the right time!) but it may well not involve actually sending coins anywhere. As @dirvine is saying, if you can prove ownership by virtue of holding the keys, and having ther ability to sign a message to prove so, then there may still be hope!
you said you can view them can you explain how ? possibly with a link
I have a few coins I sent to a bc1 address when I first got my Trezor but luckily I only sent a small test transaction to test things out before I realised bc1 addresses are not supported.
I think you are misunderstanding.The fact you cannot move the coins is actually good as we can consider them burned (dead). What would need to happen is you can prove they were yours. So with your old keys (where you transferred from ) then you can prove that. In which case there is a route to help you.
Seems to me that this has been successful. I have no nodes that scream lottery winner.
Not entirely sure if the faucet issue is a contributing factor, I really should keep historical data from past nets for comparison, bit of a novice mistake, but well so it is.
(My nodes are getting a fair bit of traffic)