This simply shows yet again that, sorry, the implementation is not and cannot be the specification. That functioning in the heterogeneous wild might be a "hard problem" might suck, but probably is really a stronger call for standards and specifications than functioning in the land of fairies and unicorns might be. The more sure it is that we'll never never actually be able to be fully up to spec, the more important it probably is to actually have a spec to aspire to. If we don't even have "second star to the right and straight on 'til morning" things might not bode well, but if we do have it, ahhh, then, the land of never never might not actually be so very bad. So please, lets just admit we aren't up to spec and have never been up to spec, and focus on getting there instead of pretending that "the world is after all perfect, if requiring a little adjustment" is a bastion of software engineering. (Just because it is true doesn't mean it is computer science.  ) -MarkM- |
|
|
|
|
Use the search feature of the forum.
Try ultimate block chain pruning for example.
Nitty gritty inner developer conversations though apparently happen on the developer mailing list, which I believe a stickymewhere hereabouts is about.
But what do I know, I don't even follow the mailing list, tut tut.
-MarkM-
|
|
|
|
Someone did do it, they called it Ripple, they didn't do all the details exactly the way you maybe expected or envisoned. -MarkM- |
|
|
|
|
10 nBTC ?
(Ten nanobitcoins.)
-MarkM-
|
|
|
|
|
Basically to trade assets on one server for assets on another server you just find anyone who is on both servers and work out some kind of deal with them where you give them something on one server and they give you something on another server.
For example I have issued a few digiDevcoins on the OTdemo server as well as many on the Digitalis server so I could accept them from someone on one server and give them on the other server some that I have there.
Typically for any asset that is issued on more than one server the issuer is a logical person to check with as you know they must be on both servers since they issued their asset there.
(So far assets have only one issuer per asset; once the corporate/group entities stuff is done people might start creating asset contracts that any of various officers or members or representatives or whatever of the group is authorised to issue, maybe even specifying which officer exactly gets to issue the asset on which server(s). But right now each asset is issued by one issuer.)
-MarkM-
|
|
|
|
What would be really useful to a whole bunch of altcoins would be if the very first thing you do to a fresh new recent copy of bitcoin is apply the merged mining patches. Just plain bitcoin with those patches successfully applied is a stem cell type of thing, the first step every merged mined coin needs, thus a step that makes little sense for each to have to do separately. Once you get those patches applied to the latest bitcoin, all the merged mined coins can clone it and start changing into their latest new version, which should cause there to be plenty of folk who are at the perfect time to help you identify what you need to do to your copy to make it into your new type of (merged mine able) coin! They can walk you through the steps as they do them to theirs, and all doing it at the same time they can all serve as reminders to each other of exactly what all the little details are that one needs to change to turn bitcoin into an altcoin. Up for it? The most recent version of merged mining patches I have is online at https://sourceforge.net/projects/galacticmilieu/files/-MarkM- |
|
|
|
Open-Transactions is now installed.
There is one GUI test wallet (in Java) and others coming soon for various platforms.
The OT API is easy, with sample code, and can be used from most languages, and on most platforms. Including: Java, D, C++, Python, PHP, etc. On Android, iPhone, Mac, Windows, and Linux.
Markm: any DVC related suggestions?
Look in https://sourceforge.net/projects/galacticmilieu/files/The archive digitalis-assets.tgz is a gzipped tar-archive of Open Transactions contracts, including the server contracts for the Digitalis server and the OTdemo server and a whole bunch of assets that are issued on the Digitalis server. See http://galaxies.mygamesonline.org/digitalisassets.html for tables and plots featuring various assets that exist on the Digitalis server. In particular, dDVC, DigiDevcoins, are tokens backed by DeVCoins, ad sDVC is shares of DeVCorp, a devcoin-based "corp". All the assets are integer whether they are share/stock type assets or currency/commodity type assets. Partly this is to help showcase the "scale" feature of the markets, because you can use "scale" to achieve granularity of price. For example if you wanted to sell digiDevcoins, which are integers, for digiBitcoins, which are also integers, you could use a market scale of a million, thus selling "lots" or "batches" of one million devcoins for some integer number of bitcoins per million devcoins. Or you could use a market scale of a hundred million, to sell "lots" or "batches" of a hundred million devcoins for some integer number of bitcoins per hundred million devcoins. And so on. That in turn will hopefully encourage decent sized trades, instead of dicking around with fractions of a coin. (Remember "pieces of eight" from pirate milieus, where coins were chopped into pieces? Yuck! We use complete whole coins here!  ) The client uses the server contract to find out how/where to connect to the server, so just import a server contract into your client, register your nym at the server, and, if the server has usage credits aka usage tokens turned on, contact the server operator to negotiate the obtaining of some usage credits so your nym will be able to do other things such as look at markets, create accounts, or whatever other fun things you might be interested in doing. (I recently enabled the usage credits system on the DIgitalis server; it it not yet active on the OTdemo server.) -MarkM- |
|
|
|
|
I guess there is something to the Apollo mission movie analogies.
Maybe its time to watch that movie again more carefully?
-MarkM-
|
|
|
|
|
Its in the spec but maybe not provided yet with a user-interface in the GUI client.
-MarkM-
|
|
|
|
Aha, I figured it out! He's sick of that line of work and looking for a job as a PR person, like Josh and MPOE-PR!  -MarkM- |
|
|
|
|
What is Joe SIxpack's risk, and what his doubt, as he talks toward Mc SubKing's microphone from his car window to order a SubBurger?
That he might doubt that they accept bitcoins there is believable, also that he might doubt the microphone is equipped to process one-tap payments from a bitcoin one-tap card.
But how did he even come into possession of such things?
(I doubt he bought then a Mc SubKIng's...)
In short if its the consumer you are talking about, I am not sure how he ended up at Mc SubKing's at all in any context relating to bitcoins...
Lets maybe step back a bit, is here there to try to evengelise to them that they ought to accept his bitcoins?
Or is it assumed they already got talking into that yet their marketing department hasn't figure out how to motivate him to try this new currency they now espouse?
Or what?
(Is he wondering whether they are marking up the subs to cover the cost of finney attacks, or something?)
TL;DR Why is he even thinking about confirmation delay, is it a fast food joint or not?
-MarkM-
|
|
|
|
"GPS, how long to the nearest Mc SubKings?" "GPS, too soon, how long to the next on route?" "GPS, order Mc Sub from aforementioned Mc SubKings..." -MarkM- |
|
|
|
|
Okay, so, requirements specification:
1) Without producing zero-day exploits,
2) The network achieves consensus as to which blockchain fork is the "correct" one,
3) By means of ...
-MarkM-
|
|
|
|
Curses! Haha. Yeah its all very well to rail against voodoo black boxes but on another channel I am really starting to see why FellowTraveler's goal for Open Transactions is to have it be "the" finance layer that anything on the machine that touches finance goes through. (This will all just be "opentxs sendcoinstoaddress --blockchain bitcoin --address 1234dghdtjhj --amount 5.4321") -MarkM- |
|
|
|
|
If bitcoind cannot do sendcoins on behalf of shell scripts, apps, other machines on the local net, other machines anywhere that are authorised, and so on, then a walletd would be needed...
-MarkM-
|
|
|
|
I'd prefer "The Satoshi client is open source, regularly updated, peer reviewed and provides the basis for a self-certifying ecosystem, but does not itself actually meet the specification [...]
I would prefer it to be called a protocol description rather than specification until the majority of the network meets it. Sorry if I seem to be emulating MPOE-PR, but... No. If it is just a description of what the current mess actually does, then the current mess already meets it, and in fact it would be more a case of it meeting the current mess than the current mess meeting it. We can even start at the code level as I did with the BDB misconfiguration example above, in which I separated out the specified max block size as being a specification then checked the BDB configuration to see whether it actually properly met that specification. On the other hand... semantics. A specification is a description. It probably should first describe requirements before then going on to describe a protocol which it intends should meet the requirements but which could turn out itself to not meet the requirements if it itself turns out to be buggy. It is styled a "specification" to indicate that it is a description of what it intends ought to be, not necessarily a description of something that has actually yet been accomplished / implemented in actual running code. -MarkM- |
|
|
|
From a business perspective, I suppose the bitcoin story sounds a lot better if one can say something like:
There is at least one high level documentation of the protocol (wiki run by the Bitcoin Foundation or else) AND any bitcoin client implementation can be tested for compliance with a single reference implementation called the Satoshi client.
The Satoshi client is open source, regularly updated, peer reviewed and provides the basis for a self-certifying ecosystem.
Through the reference implementation, bitcoin can free online merchants and payment processors from the burden of costly certification requirements imposed by proprietary, legacy payment schemes.
I'd prefer "The Satoshi client is open source, regularly updated, peer reviewed and provides the basis for a self-certifying ecosystem, but does not itself actually meet the specification at this time, due to certain bugs errors or omissions that have been discovered, and furthermore may contain more such bugs errors or omissions yet to be discovered. Nonetheless it is currently the most accurate rendition of the spec in implementation form that we currently have, and work proceeds apace on bringing it fully up to spec and correcting all bugs errors or omissions in as timely a manner as the need to allow users plenty of time to upgrade to the newer, more-correct versions - and our development and certification budget - allows." Or something along such lines. -MarkM- |
|
|
|
I'll chime in: Mike Hearn is absolutely right.
There's nothing wrong with writing "documentation" to help describe at a higher level what is going on. As a developer of a non-validation client, such documentation has been quite useful. I fully support "extra stuff the describes at a high level what's going on". But you must understand that once you put the word "specification" on any such document, you are promising the reader that the document is sufficient for creating a compliant implementation of what is being described. But with Bitcoin, anything short of the source code itself is not sufficient for implementing it. And worse, the consequences of not doing so will result in people losing money -- because if there's an inefficiency in the system an attacker will exploit it, guaranteed (especially one where your target uses code that validates differently than much of the rest of the network). This is why Satoshi did not support alternative implementations.
Write all the "documentation" you want, and put as many comments into the code as you want. But do not use the word "specification" because nothing except the code can qualify for it.
This still seems like superstition. You are basically stating that if the specification specifies that on zero day all your money is forfeit, then sorry, all your money is forfeit, look at the specification (the code) and see right there, the exact code the zero day hacker used? Its in the spec, so the hacker was correctly using the system and correctly took all your money exactly as the spec intended him or her to. Bullshit. Before even getting to the protocol specification part of the docs, the requirements specification should specify that zero day exploits are not intended to be part of the spec, regardless of which implemention or how many implementations, or how many users use such implementations or how much money rides on them. So I guess top of the protocol spec should say "first, read the requirements specification carefully..." -MarkM- |
|
|
|
Someone should just write a spec and stop debating it.
+1 If you want a spec then write something. That's what's happening by default anyway on the bitcoin wiki. But Mike Hearn makes two key points that are nonetheless valid: - You can write a spec, but you can't guarantee it actually matches the behaviour of the majority implementation.
- The consequences of getting details wrong is far more severe than that which most programmers are used to; there is simply no comparison to, e.g., POP3.
If it were an IETF draft, I would add a section at the top that states "the reference implementation is canonical, this spec is subordinate. any differences are spec bugs." I would prefer to assert that the reference implementation might not itself actually meet the spec, it is merely the closest thing we have so far to a correct implementation of the spec. We already do not nitty-gritty verify blocks prior to the most-recent checkpoint, so all we need to be able to derive from pre-checkpoint spans of the blockchain is the unspent outputs, isn't it? Is there anything else in that midden of ancient archaeological relics that we need? About the negative signatures thing, has OpenSSL already turned them positive by the time they get enshrined in the blockchain, or are they in the blockchain as negative? -MarkM- |
|
|
|
and not much easier to read.
You can't possibly be serious. To make a point I guess everyone familiar with the Bitcoin source can explain what this does and why something like it is needed for a "smart pointer" class? class bool_test
{
public:
bool_test( ) { }
private:
void operator delete( void* );
};
operator bool_test*( ) const
{
if( !p_instance )
return 0;
static bool_test test;
return &test;
}
(hint: you might want to take a look at http://www.artima.com/cppsource/safebool2.html as even the above doesn't solve all the potential problems for a simple "bool" operator in a smart pointer class in C++) This mostly shows how a specific implementation of a spec can make it really hard to even figure out what the actual spec is that it is attempting to implement. If we write an actual spec it does not matter whether verifying some prespectoric span of blocks from the dark ages needs to use some ancient ritual mumbo-jumbo to verify that it is indeed a span of blocks that totally violates the spec due to violating the spec having been superstitiously worshipped as heroic back in the dark ages. The spec will make it clear that in the dark ages, the blockchain was totally broken, which led to a shaman caste that made dark and ugly sacrifices to propitiate the invisible hand that brings the cargo upon which they prospered. The number of locks in the Berkeley DataBase seems a modern example of the shamanic cargo-cult approach too. When you notice that some to whom the cargo is the all-important thing, the raison d'etre for the cult whether or not for the experiment it purports to administer, seem to consider that to be part of the spec instead of a clear bug, it becomes clear that the implementation cannot be the spec: the implementation clearly specifies in capital letters that blocks can be up to one megabyte in size, but clearly neglected to ascertain exactly how many BDB locks are actually in real life required in order that blocks of that size be incapable of needing more locks than are configured. There we have a clear case of the spec, the in capital letters constant specifying the max block size the functions and classes and such are intended to enable, not actually being met by the code intended to meet it. -MarkM- |
|
|
|
|
Show Posts
