Topic: Request for Standardization - page 2. (Read 4670 times)

I think Mike is sceptical because we saw a lot of alternative clients announced already, in Python and various other languages, but none was ever finished.

Well the Java and .NET implementation work, though it doesn't function as a full node yet doesn't do validation/mining.

This is being covered by making it easier to interface with alternative GUIs by making the current client into a library and supporting an easier external interface... If you just want to slap another face on it I don't see why you'd want to re-implement the whole thing.

Then again, you might have a good reason, good luck with your work!

I don't think I'm underestimating at all -- I know it's a massive amount of work.  that's why I think we need a community-maintained "standards" document (wiki) that will allow developers to see what it will take to get there.  In return, such clients can conform to the "rules of the land" and make sure that the network stays "pleasant."

I don't think Bitcoin has much of a future without the ability for devoted developers to develop their own, full clients.  I think having only a single "real" client will stifle the development of the Bitcoin in general.  The ability for individuals, groups and companies to develop their own implementations, tailored for a variety of different use-cases is going to help BTC succeed.  Some people want to just spend and receive coins without even seeing address strings or wallet details.  Others will be power users, and want more fine-grained control over their wallet(s), keys, encryptions, and super-security techniques.  And there's a million shades of gray in between.  I don't think all this can be achieve with one client.
 
I have the intent to do one myself, even if it takes me 2 months to get the details right.  And I think we should promote it.  And I think the best way to promote it is to have a thoroughly-hashed-out description of these details, with as many unit-tests as possible for developers to apply to their code.  The alternative is for developers to create clients but not know they weren't supposed to forward transactions of unknown validity, then open up the door for people to start flooding the network.

-Eto

Hey, why not help me with the better GUI instead of starting yet another one?
Yes
No, never forward potentially invalid transactions.
All flexibility you want, you can require any fee you want for putting the transaction in a block, and you can add any fee you want to a transaction (though the chances it'll be included under the minimum fee/kb of the standard client are slim)

See here for some:

https://en.bitcoin.it/wiki/Protocol_rules

However, I think you're underestimating how much work is involved in reimplementing the Satoshi client from scratch. So far no credible reimplementation has appeared.

Hi all, I'm mostly active in the parent discussion group, but I am working on an alternative client in python, so I should be spending more time here.  In recent days, I have realized that alternative clients could seriously disrupt BTC network unless their is very high standards for what it does.   What I'm concerned about is someone making a really great GUI (like I plan to), that has a subtle vulnerabilities that the base group of developers have tried so hard to avoid (which I don't plan to do).  The last thing we want is to have 30% of users switch to a client that has a scripting bug in it that evaluates certain scripts to true that should be false, then the block chain starts getting messy with hundreds of invalid blocks and "reversed" transactions. 

So, of course, I would ask if there is an existing description like what I ask for.  If not, or if it's not complete, I would like to start one here.  I want to create a living, master checklist for developers to use, that they need to conform to before declaring their client "correct."  This would include flood defense techniques, community-agreed transaction fee schedules, scripting unit-tests, network broadcast/forwarding rules, etc.  I recognize a lot of this is in the C++ source code, but that's not the best way to document the standard...

I will start here with a short a short list of questions, and I'd like to get feedback concerning what is needed for a new client to be considered safe & "correct."


-- Node connection protocols:  node-discovery techniques, node-cycling, suggested IP-rules, backwards-compatibility handling
-- Scripting: 
    - Would like to see a list of OP_KEYWORDs to be supported by the scripting engine (are they all the non-"Currently Disabled" words on the scirpting wiki?)
    - Would like to see/create a set of reasonably-complex unit-test scripts that can be used to check the scripting engine, including most required keywords
         - Tests would look like (scriptBinaryTest1, True), (scriptBinaryTest2, True), (scriptBinaryTest3, False), etc,
-- Reduced-memory nodes
    - If a node is not intended to hold the entire blockchain, how should its network-protocols be adjusted?
    - What classes of nodes can we define, and what are the associated capabilities:
       -- A node that only holds it's own transaction list should only connect for getting information, not forwarding transactions or blocks (or maybe forwarding blocks, but not transactions?)
       -- A reduced-footprint node should identify itself in some way on the network -- and other nodes would be aware and pick it's peers diversely... how?
-- Flood-disconnect conditions: 
    -What conditions should be applied before disconnecting a node (besides the bug currently disconnecting those downloading the block chain)
    -What conditions determine whether a broadcast transaction is forwarded to other nodes/peers?  Blocks forwarded?
         - Does a node have to be able to check validity of all blocks/transactions to forward them?
         - If a node is a reduced-memory-footprint node (not holding the entire blockchain), should it forward transaction even if it can't verify they are valid?
-- Transaction Fees:
    - What is the current acceptable fee schedule?
    - How much flexibility will we allow for developers to implement their own fee schedule?
    - If a transaction fee is not included where we think it should be, should it be forwarded to other nodes?
-- Other:
    -What are the timeout rules for peer nodes?
    -What are the timestamping rules for creating new blocks (I know there's a median calculation based on a bunch of peers)
    -Would like to see a list of checks required before declaring a transaction valid.  A developer could easily remember to check the merkle tree root, but not that sum(TxIn)==sum(TxOut)


I know I'm forgetting a ton of stuff, but that's why this is a discussion and not a monologue

-Eto