Main > 中文 (Chinese)
目前已知的DAC经常利用的技术有哪些？
sfinder:
3I的DAC列表。
--- Quote from: bytemaster on February 11, 2014, 12:58:05 am ---
--- Quote from: sfinder on February 10, 2014, 10:26:48 pm ---
where can i find the list for upcoming DAC chains?
--- Quote from: currencydebt on February 10, 2014, 07:31:36 pm ---
--- Quote from: sfinder on February 10, 2014, 07:24:12 pm ---will angel-share donation still be on until reach 200 days ? if 02/28's btsx snapshot is successful then future donation to AGS will not be able to get BTS ,right ?
--- Quote from: bytemaster on February 10, 2014, 02:42:38 pm ---
--- Quote from: HCarvalho on February 10, 2014, 02:08:40 pm ---then what?
--- End quote ---
Then when you download BitShares X and open your wallet you will get your starting balance.
--- End quote ---
--- End quote ---
What happens on February 28th is only relevant to the first chain of Bitshares; all other Bitshares chains will be released in the future after February 28th. Invictus DAC's will be distributed to PTS holders and those who donate to AGS if the donation comes in before each one is released. So if you donate after February 28 you will be still in line to benefit from all the other chains and DAC's that are upcoming.
--- End quote ---
--- End quote ---
BitShares X - many of them with different variations and assets.
BitShares DNS - auction off domain names (one chain)
BitShares Bingo - (many chains)
BitShares Tunes - See recent thread about music / etc (many chains)
BitShares Vote - (many chains)
BitShares Me - Issue your own shares. (many chains )
BitShares Reddit - (many chains)
BitShares Ads - ad words ...
There are not white papers on these yet, but you can see there is plenty of work to do and lots of value to be produced for AGS and PTS holders.
--- End quote ---
nametooshort:
--- Quote from: HackFisher on February 12, 2014, 02:26:10 am ---关于实现Blockchain所用的DB，有很多有趣的讨论，Bitcloud最近比较活跃，有一些讨论，不同于levelDB和BDB此类key-value db， 有尝试用Sqlite此类的关系数据库：
--- Quote ---Javier R. Sobrino liberman@riseup.net via lists.sourceforge.net
11:58 PM (10 hours ago)
to Bitcloud
While I was designing the blockchain for Bitcloud, I realized that there
is no way that Bitcloud can work on a classical Blockchain structure.
Just imagine: Bitcoin with 1 million users needs 12Gbytes of data to
store the blockchain, and what it stores is just money
transactions. Bitcloud is going to store many other things, like node
statistics, user and publishers information, sophisticated contracts,
etc. If we use an immutable form of blockchain, in one month after the
release we will need hundreds of gigabytes only to store that.
Another limitation of the classical blockchain is that it is not
relational, so you can't do advanced queries without going into a lot
code. To see that, look at how I am designing the nodepool here:
https://github.com/wetube/bitcloud/blob/master/src/c/nodepool.sql
Handling the logic of all of that in a key-value database is very hard.
So my proposition here is to stop thinking in terms of the classical
blockchain and approach this project from a different perspective.
As I say in the paper: the Nodepool is a relational database, synced by
consensus, in which all the statistics, information and contracts are
stored.
In my investigations to find a proper database that could support all
the things we need, I found that SQLite is very nice, and can be easily
tweaked and extended.
SQLite supports the creation of custom checks, so something like this
can be possible:
CREATE TABLE publisher_grid_contracts (
id BLOB(16) PRIMARY KEY NOT NULL,
publisher TEXT NOT NULL REFERENCES publishers(public_key),
grid TEXT NOT NULL REFERENCES grids(public_key),
-- Signatures of this contract:
publisher_sig TEXT NOT NULL,
grid_sig TEXT NOT NULL,
-- Terms:
min_storage INTEGER NOT NULL,
min_bandwidth INTEGER NOT NULL,
start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
end_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
availability INTEGER NOT NULL, -- % of time online
ping_average INTEGER DEFAULT 0,
-- Coin terms
coin REFERENCES coins(id)
CHECK (signatures(publisher_sig, grid_sig,
publisher || grid || min_storage || min_bandwidth ||
start_date || end_date || availability || ping_average ||
coin )
);
Look at the last statement, the "CHECK(signatures...." one. Once we
define the extension "signatures" in plain C, we can ensure that nobody
can insert a contract into the database without the proper signature of
the two participants of the contract.
But there is even more. SQLite also allows to customize an authorization
function to allow or deny access to data from different sources, which
means that we can base the language of Bitcloud in SQL, and only allow
certain operations. Look at:
http://www.sqlite.org/capi3ref.html#sqlite3_set_authorizer
I strongly recommend everybody to have a look at this fantastic book:
http://evalenzu.mat.utfsm.cl/Docencia/2012/SQLite.pdf
Now, having SQLite resolving our problems for the language and the
database, we can concentrate on the sync process.
Any suggestion, questions or alternatives to all of this, please answer
to the list.
Thanks.
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Bitcloud-developers mailing list
Bitcloud-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcloud-developers
--- End quote ---
--- End quote ---
淘京币用的就是levelDB
HackFisher:
关于实现Blockchain所用的DB，有很多有趣的讨论，Bitcloud最近比较活跃，有一些讨论，不同于levelDB和BDB此类key-value db， 有尝试用Sqlite此类的关系数据库：
--- Quote ---Javier R. Sobrino liberman@riseup.net via lists.sourceforge.net
11:58 PM (10 hours ago)
to Bitcloud
While I was designing the blockchain for Bitcloud, I realized that there
is no way that Bitcloud can work on a classical Blockchain structure.
Just imagine: Bitcoin with 1 million users needs 12Gbytes of data to
store the blockchain, and what it stores is just money
transactions. Bitcloud is going to store many other things, like node
statistics, user and publishers information, sophisticated contracts,
etc. If we use an immutable form of blockchain, in one month after the
release we will need hundreds of gigabytes only to store that.
Another limitation of the classical blockchain is that it is not
relational, so you can't do advanced queries without going into a lot
code. To see that, look at how I am designing the nodepool here:
https://github.com/wetube/bitcloud/blob/master/src/c/nodepool.sql
Handling the logic of all of that in a key-value database is very hard.
So my proposition here is to stop thinking in terms of the classical
blockchain and approach this project from a different perspective.
As I say in the paper: the Nodepool is a relational database, synced by
consensus, in which all the statistics, information and contracts are
stored.
In my investigations to find a proper database that could support all
the things we need, I found that SQLite is very nice, and can be easily
tweaked and extended.
SQLite supports the creation of custom checks, so something like this
can be possible:
CREATE TABLE publisher_grid_contracts (
id BLOB(16) PRIMARY KEY NOT NULL,
publisher TEXT NOT NULL REFERENCES publishers(public_key),
grid TEXT NOT NULL REFERENCES grids(public_key),
-- Signatures of this contract:
publisher_sig TEXT NOT NULL,
grid_sig TEXT NOT NULL,
-- Terms:
min_storage INTEGER NOT NULL,
min_bandwidth INTEGER NOT NULL,
start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
end_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
availability INTEGER NOT NULL, -- % of time online
ping_average INTEGER DEFAULT 0,
-- Coin terms
coin REFERENCES coins(id)
CHECK (signatures(publisher_sig, grid_sig,
publisher || grid || min_storage || min_bandwidth ||
start_date || end_date || availability || ping_average ||
coin )
);
Look at the last statement, the "CHECK(signatures...." one. Once we
define the extension "signatures" in plain C, we can ensure that nobody
can insert a contract into the database without the proper signature of
the two participants of the contract.
But there is even more. SQLite also allows to customize an authorization
function to allow or deny access to data from different sources, which
means that we can base the language of Bitcloud in SQL, and only allow
certain operations. Look at:
http://www.sqlite.org/capi3ref.html#sqlite3_set_authorizer
I strongly recommend everybody to have a look at this fantastic book:
http://evalenzu.mat.utfsm.cl/Docencia/2012/SQLite.pdf
Now, having SQLite resolving our problems for the language and the
database, we can concentrate on the sync process.
Any suggestion, questions or alternatives to all of this, please answer
to the list.
Thanks.
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Bitcloud-developers mailing list
Bitcloud-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcloud-developers
--- End quote ---
nametooshort:
实际上可以不使用区块链构建一个DAC。区块链的一个重要作用是让每个人都看得见所有数据。而邮件之类的DAC实际上可以不使用区块链来构建。
去中心化实际上是为了防止单点失效。在中心化的系统里，要是中心服务器down掉了，整个系统就down掉了。
Musewhale:
看不懂的人只能默默学习
Navigation
[0] Message Index
[#] Next page
Go to full version