|
"Dr. Craig Wright", the inventor of BTC (he claims), says he got hacked and someone encrypted his passwords. He is suing "blockchain developers" to get access back to his BTC (in excess of £3.65 billion ... so he says).
What do Tesla, BTC and GameStop have in common? Tesla is "valued" at $1 Trillion. 
Does it get any better?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Should be easy to spot the culprit: just check the car park for a brand new gold plated Tesla ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Now if the bitcoin is recoverable then, by definition, it has now become traceable.
That throws a whole new lite on bitcoin, hackers, extortionists, and tax-dodgers living in Seychelles.
Hey kids! Look forward to something oh-so-exciting! If and when the coin is recovered and thus it's security drops to shyte, what will happen to the price of this in-reality-worthless commodity?
Crash, you say? Makes sense. This is, however, "the market" and it may increase in value cost because it will be assumed that even greater un-tracability will now be developed. Hold on to your head-wear !
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It's sort of traceable already. If the owner of a BTC address is identified and reveals whom he dealt with, then the owners of those BTC addresses are revealed, and so on transitively.
|
|
|
|
|
OK - now all we needs is
(1) a plan
(2) an island get-away
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
The "hope" is based on the suit being successful. But I thought the whole point was that "wallets" were anonymous.
"I found a wallet!"
"No, that's mine."
"Prove it. No Id. Finders keepers."
2 sides: you're anonymous or your not ... though they don't seem to know who all these "whales" are. Some are said to be worth 30B$ ... a sell-off would send a "ripple".
The big boys office pool.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I suspect it's lawyer led: they will make a fortune whoever wins, as usual.
But if he wins and gets "his" wallet back, then the value of bitcoin will probably crash as all the big players who use it for it's anonymity will divest it in a hurry. Heck that could happen anyway if they suspect that anonymity could be broken.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
he must have written down his passwords somewhere ? no ? ... no back ups ? no ? ... at least you cannot download gold...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
According to the article, his machine was supposedly hacked, and the password was changed by the hackers.
|
|
|
|
|
whatever the whole thing stinks
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Let me get this straight. The guy who supposedly 'invented' bitcoin to be an independent monetary system beyond the control of any government now wants Britain to step in and force the developers who 'control' bitcoin to reverse the changes made to his password? Hmmmm.....
|
|
|
|
|
if u go to the zdnet artcile and the pdf
As we set out in our 12 June Letter, on or around 5 February 2020, unknown hackers
stole the private keys for the Addresses and deleted copies of the keys on Dr Craig
Wright’s computer, preventing him from accessing the digital assets at those
Addresses, which he operated on behalf of TTL. Accordingly, TTL is (absent steps
being taken by the Developers) unable to access or control digital assets that are TTL’s
legal property.
he is supposed to protect his computers not some bit coin developers... the
public key private key senario... if you lose your private key what do you do ?
hxxps://www.ontier.net/ia/a1letter-before-action-from-ttl.pdf
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
News at 11: Lying liar lies.
With luck the judge will require the ![Sunshine | [little ray of sunshine]](https://www.codeproject.com/script/Forums/Images/sunshine.gif) to testify under oath and then lock him up for perjury. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: With luck the judge will require the [little ray of sunshine] to testify under oath and then lock him up for perjury.
This.
|
|
|
|
|
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart.
1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery.
2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals.
3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA.
4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead.
5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers.
6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project.
7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning.
8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster.
9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then.
10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work.
11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion.
12 - Don't go to developers directly without coordinating with the team lead first. Developers on a team need to be coding, not spending time so you can get some data bits for a report. In most cases, the team lead will get what you need.
13 - When a developer is interrupted for meetings or questions not directly dealing with getting code done, it takes anywhere from 15 minutes to 2 hours for the developer to get all the moving parts back in their mind so they can pick up where they left off. Software development is a complex work that takes a lot of intellectual horsepower.
14 - When deciding "we need a meeting" that interrupts developers, calculate the total cost in labor, and ask yourself if the cost is worth what you get out of it. Consider a team of 8 developers and one team lead, at an average labor cost (salary, benefits, etc.) of $100/hr. Your 1 hour meeting just cost $900 and delayed the project by at least 2 hours.
15 - An experienced team lead with business experience and able to describe the technical in non-technical terms can easily reduce the cost of a development team by replacing most, if not all, of what a BA, PM, SM, and PO does. And get it done better and sooner due to lack of overhead. If is far easier for a senior software engineer to learn the business side than for a BA, PM, SM, or PO to learn the software development side.
16 - Agile, Scrum, Kanban, agile frameworks, etc. are not recipes to be followed. They contain principles to be considered and used in the SDLC if and how they provide value. Just read the original Agile Manifesto and see how far today's agile has strayed from it.
17 - Look for generalists, not specialists, on the development team. Hiring specialists (those who work in the specific toolsets being used today) works for now, but not as technology changes. Hiring generalists (those who know software engineering but can adapt and learn whatever toolsets are in use today) gives you people who can efficiently adapt as technology changes.
18 - If you want to learn one new thing, learn what value engineering is.
These opinions are solely my own, and not necessarily those of any current or past employer.
|
|
|
|
|
There's a lot of good stuff in there.
why not a book?
Or at least an article?
I like #5 & #16 a lot.
Also, I took the advice of #18...
What Is Value Engineering?
Value engineering is a systematic, organized approach to providing necessary functions in a project at the lowest cost. Value engineering promotes the substitution of materials and methods with less expensive alternatives, without sacrificing functionality. It is focused solely on the functions of various components and materials, rather than their physical attributes. Value engineering is also called value analysis.
Key Takeaways
Value engineering is a systematic and organized approach to providing the necessary functions in a project at the lowest cost.
Value engineering promotes the substitution of materials and methods with less expensive alternatives, without sacrificing functionality.
It is focused solely on the functions of various components and materials, rather than their physical attributes.
|
|
|
|
|
Value engineering was a significant part of NASA in the 1960s, SkunkWorks in its original days, and in Rickover's Naval Nuclear Power. It has very useful applications in software engineering. One of the most illustrative is the "build vs buy" decisions made often in a project.
|
|
|
|
|
Still represents a master-slave relationship. I wear many hats and don't need a master even when I have to be a slave.
Or, main point: I don't need (want) a middle man to the "real" user.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I am not sure at your point.
If your point is that on a solo developer project, you don't need someone to tell you how to do it, and you can wear all the hats necessary, then I agree with you. My OP was in the context of larger projects where a team is necessary. If I am not understanding your point, please feel free to elaborate.
|
|
|
|
|
This "list" (prescription) has been circulating for years; only the phrasing changes.
It makes you think change is possible, when it isn't.
Office politics. You will never be allowed to be "smarter", or make a bigger contribution than your PM, BA, DBA, whatever.
The result: grinding boredom while you wait for someone else to come to a bad decision; and then having to live with those decisions.
Most of the people "involved", except the lowest levels, don't really care whether a project succeeds if it doesn't directly advantage them.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
What you describe is the painful reality too many have to experience, including me on more than one job.
FWIW, I have been able to make this work in a few organizations. The largest pushback comes from BAs because of the very reasons you cite (the others do, also, but my experience was they pushed back less once they knew they were getting what they wanted).
One tactic that I used successfully was to pick a project that I convinced the management above the BAs would be a "trial run" or "proof of concept". Once management saw how well it worked, they expanded on its usage. That may not work everywhere, but it is worth a try.
|
|
|
|
|
Yes, of course there are exceptions; and I've experienced a few. Unfortunately, even the good is always followed by the bad: in-fighting about who gets to build a department around the new system (Director, couple of supervisors, maintenance programmers, librarian, receptionist, office space, ...)
We implemented a Revenue and Royalty System: REVROY.
I would later hear stories about people asking: "Who is this Rev Roy and why is everybody always talking about him"?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: Or, main point: I don't need (want) a middle man to the "real" user.
Sometimes a middle finger is better than a middle man, and that not always towards users / customers.   
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
A have been known to take a "superior" aside and tell them never to blind-side me in a meeting. No "or else".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
