"if you think you're going to sell teh interwebz to the mass market because the general public wants a pseudonymous, distributed, relatively failsafe data transfer and publication protocol, I can proove to you, absolutely: they don't and you're completely wasting your time."  Is this a real quote? Who is this from? |
|
|
|
|
I tell you what though, short of writing my own berkeley db wrapper there is no decent way to abstract this libary. Their 'C++ API' is essentially the same as their C one except you don't call DB->put(mydb, ...) but instead do mydb->put(...). Nice. Not sure why they bothered.
|
|
|
|
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
I disagree. I think planning ahead always leads to better software even if the software development may be slower to start. Better to find a problem in your proposal and rewrite that than to discover a problem in your code and redo a ton of work there IMO Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once. You're advocating the ancient waterfall method which is basically out of fashion since the last decade. genjix:~$ python
Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
|
|
|
|
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
You have a fair point. But I'm extremely skeptical as to overall software architectural skills in the broad Bitcoin community. My absolute favorite is the inversion of control issue in Satoshi client exhibited by ThreadSafeAskFee(). Such a textbook case of an anti-pattern. https://bitcointalk.org/index.php?topic=44330.msg538044#msg538044The rationalization I heard why this "isn't a problem" or the workarounds proposed are quite enlightening and entertaining. Too bad that moderators deleted several flaming comments in that thread. The bitcoin codebase is terrible architecturally. You may be interested to review my codebase which is an asynchronous bitcoin toolkit library using proactors. Completion handlers using std::bind and std::function are passed to operations. https://bitcointalk.org/index.php?topic=30646.0Also a video on the design principles behind the API: http://www.youtube.com/watch?v=zyKcSpx5xDg |
|
|
|
The question here is not GPL or no GPL, the question is either: AGPL or lesser AGPL. I've been working with the Aaron Williamson of the SFLC and Richard Stallman of the FSF to fix a bug in the AGPL for bitcoin. Then I will weigh up the various arguments for adding or not adding a lesser clause. It is whichever will promote development of the library the most. *GPL licenses mean you can either contribute sourcecode or $$$ to benefit the library (by buying proprietary licenses). Right now as it stands, this library still needs to be completed so these arguments are a time waster  The bug I'm referring to is that the AGPL requires not only that you give the sourcecode on demand, but that you're proactive in providing the sourcecode visibly. This is problematic because if you make a small modification while developing or building on a compilation based system (like gentoo) then the act of connecting to the p2p network means you have to provide source. There is no means to do this in the bitcoin sourcecode and the idea itself is problematic; every build must store the sourcecode in a bundle which is served using custom bitcoin protocol extensions. From my understanding, modifying the AGPL for them is complicated and so far the last proposal was: > If the covered work has no means of communicating an offer to
> provide Corresponding Source to the users interacting with it
> remotely over a computer network, then you may comply with this
> requirement by making the Corresponding Source for your version
> available for anyone to copy, free of charge and under the terms of
> this License, through a publicly available network server or other
> readily accessible means. This means that you are able to provide the source code through some other means (such as sending it via email if requested) and it solves the issue. ------ In an ideal world, copyrights, patents, trademarks and censorship wouldn't exist. Proprietary software would not be able to support itself against rampant piracy. And I would put my sourcecode out in the open for anyone to use as they like. However, we don't live in that ideal world. And I will use what little power I have in the form of the GPL to fight this asymmetric warfare. The balance is totally tilted away from our favour, so why wouldn't you use the only protection afforded to you as a developer. Licenses like the GPL hack the law, twisting it to our will. It is the best example of subversion. When people talk about GPL or MIT licenses being free, they're talking about different kinds of freedom as they're essentially rivalrous freedoms. Being free does not always mean no rules necessarily: According to Assange, "It’s not correct to put me in any one philosophical or economic camp, because I’ve learned from many. But one is American libertarianism, market libertarianism. So as far as markets are concerned I’m a libertarian, but I have enough expertise in politics and history to understand that a free market ends up as monopoly unless you force them to be free." And this coming from a person with anarchist tendencies. |
|
|
|
|
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
|
|
|
|
|
While you know my suggestions:
Electrite (my favourite)
and
Electrolyte
|
|
|
|
|
Yes. It isn't a requirement to be compliant with the protocol, but it is a little extra added security which is nice.
|
|
|
|
That was yes AND no, both to the second question, right?
No :p There are checkpoints in bitcoin as an added security measure. If they didn't exist then there would be no limits to reverse the chain. However it isn't a concern. The longest re-organisation ever was 6 blocks deep. |
|
|
|
Why don't we start a quote pyramid?
Why should we? Ok, but am I first or is ineededausername first? Can someone ask dayfall to define first? |
|
|
|
|
Wouldn't work without modifying the protocol and sourcecode.
|
|
|
|
Is there any length after which a blockchain is 'permanent' in your code? Is it technically possible for a reorg after ten or one hundred blocks since the orphan-root?
Yes, theoretically. No, practically, because of the checkpoints in the block validation code. |
|
|
|
|
Weeeeeeeeeeeeeeee camping out here
|
|
|
|
|
No offense, but if you're asking what is needed in a new exchange then you probably shouldn't be in this already saturated market. It should be blindingly obvious.
|
|
|
|
Max of 80 characters. 4 space indents. Variables, functions, class-names, enums, typedefs are lowercase. Macros are uppercase. Private class member variables are suffixed with an _ Each line should be indented by either 1 or 2 levels on the next line, and 1 line for each successive indent. If you're going more than 3 levels deep with each new line of code, then generally you are doing something wrong and code should be siphoned off into functions. Always prefer: flat over nested, dumb over clever, slow+clear over fast+obtuse. Functions should never be defined in headers. Always in the implementation unless it's required to be in every translation unit (i.e template or constexpr functions). Format for header file: #ifndef LIBBITCOIN_FOO_H
#define LIBBITCOIN_FOO_H
// derived from project includes (i.e blaa.hpp)
// system includes:
// STD headers first
// boost headers second
// other headers last
// project bitcoin includes like <bitcoin/messages.hpp>
// local bitcoin includes "helper_foo.hpp"
// forward declarations
// class Db;
namespace libbitcoin {
// using ...
// typedefs
class foo
: public blaa
{
public:
// typedefs
// functions logically grouped into blocks
// variables
private:
// same as for public block
};
} // libbitcoin
#endif
Format for cpp file: #include <bitcoin/foo.hpp>
// same format as header files
namespace libbitcon {
foo::foo()
: blaa(xyz)
{
}
} // libbitcoin
Every { occupies a newline except for namespaces. Spaces between all operators: x = 5 * 8 + 4 * 2 ... If the order is confusing then use brackets: x = (5 *  + (4 * 2). Each : ; (in for loops) or , has a space after them. All flow control should always happen on new lines. // Bad
if (blaa) do_foo();
// Good
if (blaa)
do_foo();
// Bad
something(); another_thing(); yadayada();
// Good
something();
another_thing();
yadayada();
It's nice if function names read like a sentence when used: write_to_stream(data_packet); or say_hello_to(my_friend); Accepted short-handsThese are for variables and not for type names which should never use abbreviations. tx = transaction blk = block ec = error_code it = iterator |
|
|
|
A document describing the functioning of the organize algorithm.New blocks when they first come in are added to the orphans pool. The pool does not order the blocks. To trace a chain of blocks from an endpoint you have to keep looking up the previous block as you go backwards.  Assuming we have a valid genesis block, then this pool would produce 2 chains like this:  We loop through every block in the orphan's pool, setting each block to processed each loop. This stops us re-processing a block when a new block is added again to the pool, re-triggering the organize algorithm. The blockchain is only ever stored as one main chain. In the blockchain database is only stored the currently accepted history. Blocks added to the blockchain are taken out of the orphan's pool, and returned back to the pool when removed from the blockchain. If we have the chain: Then the remaining blocks in the orphan pool are 2b, 3b, 4b. Block 4b comes into the pool and will trigger a re-organize. When we run the organize algorithm, we find out that the chain 2b, 3b, 4b has greater difficulty. - Trace backwards through the pool until we cannot cycle backwards anymore. We call this the orphan-root.
- Organize will first find the fork point within the blockchain to be at block 1 using the orphan-root's previous block hash.
- The difficulty in the remaining blocks of the main chain and the chain in the orphan pool are calculated. If the main chain algorithm's difficulty is bigger than the orphan's, then the algorithm stops and the main chain is untouched.
- The new blocks in the orphan pool will replace the ones in the main chain. The end blocks from the main chain are popped off and returned back to the orphan pool. The blocks from the orphan pool are added to the main chain as the new chain.
- Reorganization has finished.
|
|
|
|
|
We'll see about the license afterwards. It's always easier to switch to weaker copyleft than vice versa. For now I want to build.
Post about new organize algorithm below.
|
|
|
|
|
Should I do this?
I changed my name on IRC briefly to AmirTaaki and it just felt awkward and strange. I've been using genjix over 10 years now, and the name is a part of my identity. It has a rich history which I don't quite want to give up now. Like a warm blanket wrapped around me.
I don't mind my real name either. It's interesting and different. But genjix also means a lot to me as a faceless identity I grew as a person with. I kind of like to be anonymous sometimes. I will occasionally change my name on IRC and pretend not to be me or obfuscate my identity to new people. I spend a lot of time on 4chan. It has a nice concept where it is more important what you say, rather than what you do.
If there is a reason for me to switch though, then I will. It isn't a huge deal.
|
|
|
|
|
Show Posts
