Warning: Tuppence worth follows…
DBCs are VERY interesting - potentially a killer app for SAFE
A working testnet for MVP is MUCH more interesting. I do not consider DBCs part of an MVP-oriented testnet (does that even make sense?)
Unwanted backseat driver management advice follows:
Unless we suddenly found spare devs, then everything should go into getting a testnet running WITHOUT DBCs.
HODL 80-90% and surf the waves with the rest.
Think I might buy some more and take up surfing 
Testnet anxiety is clearly mounting but lets not force a rushed attempt to appease the community, something stable that gets taken down instead of fails rapidly is worth a wait in my opinion.
The optics are way better.
I expressed that fear the other day
Well someone was disappointed in the update, thats for sure. 
for a timeline until test net next week. Soon was already mentioned, so a fixed date of e.g 1st December can’t be too much to ask for a test net.
Instead we will probably get more “Were working on this exciting new feature, stay tuned”
Maybe it was something entirely unrelated. Correlating real-world events with the behaviour of crypto markets is like pinning the tail on a donkey
Maybe, on the “upside” it’s comforting to know our never ending downward trend has returned.
that we can still buy in cheap 
Pump and dump was called and happened. Not sure if there is much deeper to read into. I hope there weren’t too many suckers panic buying in.
Well called.
Hey @zeroflaw
As one in the team, and right now the only guy working on DBCs (among things), I can say this:
We have a few essential properties in AT2 that are less aligned with the fundamentals of the project (as guessed/mentioned somewhere recently by @Nigel).
We’ve looked into fixing that in our current AT2 impl, as well as looking through our archive of options, where DBC is one, to home in on our goal.
Before I started this specific task I was probing for priorities and mentioned that one of my preferred tasks was continuing pushing next testnet out the door. Happens though, that there is just so much a bunch of people can accomplish on a specific set of problems. At some point all just do the same things, and there is no increasing of speed by more people doing the same thing.
Basically, that was the conclusion at that time. Tomorrow there might be something that requires my attention and will benefit from me jumping in. Probably won’t be mentioned in an update, so you won’t see that.
We thought it valuable for people to know the status of the payments system implementation, that we haven’t forgotten DBCs, and that in our view it is still an option. That’s why it was mentioned.
It is work going on in parallel with our testnet RC. When it comes to the payment system we are more or less in code freeze until testnet.
I totally get your impression of a perpetual
“Were working on this exciting new feature, stay tuned”
That thing is not exactly unheard of in software development (meaning: oh boy, is it common…), and this project has not been immune to it either.
But as described above, it’s not as simple as just throwing people at a problem, you always need to keep long term and short term goals balanced with regards to priorities, bandwidth etc., which will be a constant challenge to any manager anywhere.
That said, I for one will keep prodding at testnet resource allocation, and similar related to shorter iterations, release etc.
Exactly. Appeasement is as flimsy for a working product as these pumps and dumps.
Surely, a lot of aspects will work, given a more quickly released test net; but the devs seem pretty keen lately on implementing very good recent tech that they see as a perfect fit for Safe, especially after learning absolutely everything negative from PARSEC. The main detriment is if even the recent tech seems so shiny that sleep is lost over trying to implement them, i.e. “It’s so good potentially that we can’t give up,” and then more months somehow pass by haha.
Thanks for spending the time to write that. Interesting and insightful. I’m glad test net has full focus.
Probably helpful that this is confirmed IMO. People speculate either way as we can see but from my perspective if it gets us in line with the fundamentals/full featured network with added benefits, then why not? Especially with something effective and proven. Implementing and adapting it to the network adds time but in the scheme of things how much really? I’m pulling for you guys. Keep up the amazing and really exciting work.
Yep, so a quick take at this:
Data Consistency, Byzantine Fault Tolerance (BFT), Anonymity, Performance are a few of the things that we require of our payment system (some would argue Verifiable History, but that might be at odds with some of the previously mentioned).
Our current AT2 implementation seems to have have BFT, Verifiable History, maybe Performance and maaaybe Data Consistency.
DBCs in our system seem to have most except maybe Verifiable History (currently unsolved AFAIK, but might be possible).
Phew. Unfortunately, when it comes to “proven”, we’re not fat stacked at this side of evolution. We do search for exactly that, when looking for components, solutions, patterns. The entirety of it though, keeps being something unproven, until we do it.
I am one of those suckers, ugly -18,5%. Ooups… 
Anyway, I am going to continue buying at these levels and I dont mind this unrealised loss too much… I will sell first 1% of my stash at 1,15$, or when I hear again about MAID burning conversion to Safecoin.
In terms of price yes, but looking at volume it’s a bit of a different story
Looking at 1h time periods, the pump was 5.577 btc volume, dump was 0.268 btc volume. That means there was a lot of buying and not much selling (about 20x more buying than selling).
I hadn’t seen that, but that is interesting. I suppose moving the price in either direction doesn’t take much atm.
