BALL

search results

25 ( ) from offset 0 out of 50

550 The only **real** shortcoming of the current system left over from the prototype stage is the missing support for decentralized authentication (A.k.a. Web Of Trust). ## Problem Assessment gcrypt is created 2013-07-19 21:44:34 +0200
562 The old one has been retired. The bugtracker is now better configured. But noticed: it can not yet display ongoing issues. Thus it fits well for personal and soho use, but here this is a serious limi created 2013-07-19 21:53:24 +0200
983 I've been working for a while on an arguable tamper-proof system. It's designed to following closely the ethical and judicial ideas which form the foundation of *at least* western democracies. (To be created 2013-07-24 13:17:42 +0200
1022 ### Same To an application programmer storm-topologies of *bolts* are similar to topologies of *places* in Askemos. ### Different A storm cluster is **one** peer (because it's admin is a SPOF) in an created 2013-07-26 09:32:25 +0200
1035 At least the agreement and resync protocol should have an alternative implementation. Protocol buffers look promising here. Note: This must not supercede the HTTPS/XML, which should be developed into created 2013-07-26 22:45:56 +0200
1084 Ae6dccbc439ce4600932b2e0411c6f5fa created 2013-08-02 21:14:47 +0200
1105 ## Problems with the conversion to hygienic syntax ### 1. Captured Literals While attempt to replace non-hygienic syntax (`` define-macro `` ) I discovered that this requires a huge amount of undesir created 2013-08-03 12:14:07 +0200
1137 Explicit Renaming created 2013-08-03 13:57:29 +0200
1169 Copying a 35MB file back after upload ran into a "negative destination offset" (from mmap handling under Chicken). The process of splitting the input into blocks seems buggy. When the first (the "*d created 2013-08-03 21:35:51 +0200
1200 CoreOS looks at a first glance quite like a substrate for an alternative BALL implementation. A *container* in CoreOS terms would be a *place* in Askemos words. However: the raft protocol does **not created 2013-08-22 08:43:05 +0200
3995 http://bft-smart.github.io/library/ created 2009 (unknown day)
1304 Observed at the `` chicken `` version: the blob file contained wrong content. Once zero size, once the correct length but unrelated data. Hint: at the chicken list there was recently a report about s created 2013-09-10 18:49:22 +0200
1324 use of 1024-bit RSA is deprecated through to the end of this year and disallowed subsequently, precisely because it is susceptible to being broken. 2048-bit RSA, in comparison, is approved until 2030 created 2013-09-10 18:56:22 +0200
1336 The procedure `` make-local-entry-point! `` does not work anymore for the case where a well known id from some other node is to be replicated and granted user privileges locally. It does however work created 2013-09-11 15:02:11 +0200
1356 The optimistic latency of Byzantine Paxos can be reduced from three communication steps to two, without using public-key cryptography. This is done by making a decision when more than (n+3f)/2 accepto created 2013-09-16 12:07:32 +0200
1382 Sun, 29 Sep 2013 11:19:55 +0200 system-clock port already closed (port already closed (#< output port "/home/jfw/clear/A5/56/A556916925f56990cfa1ddd81b6ea1198.rdf,n">) display) display created 2013-09-29 11:39:25 +0200
1410 A1dd0a10da5b0370d803f4aebbdf5910a created 2013-10-07 19:39:53 +0200
1570 This version of Chicken came with modifications to signal handling. As a workaround I replaced the "fork failed" exception with a restart. So far only one of the Sheeva plugs appears effected. Howe created 2013-11-18 09:31:06 +0100
1626 The DHT implementation currently forwards lookups to the next peer. The peer having the entry eventually replies directly to the query origin. That is repeating a decades old mistake. If peer can pre created 2014-01-09 09:17:04 +0100
1765 #### Point raised during the review of the *Stone Age Accounting* #### demo. >>> 1. a token of agreement. AKA a signature. There needs to be >>> some convention that indicates the offerer's intent created 2014-07-20 09:12:23 +0200
1776 There is a [Demo Wallet][1] in the works to show BALL implementing a payment system based on contracts. [1]: /A0cd6168e9408c9c095f700d7c6ec3224/?_v=search&_id=1856 created 2014-07-25 12:29:56 +0200
1783 revise created 2014-07-25
4373 Hyperledger – Version I created 2014-05-14
1833 BALL is an open source platform for creating software controlled by contracts. Anyone can create a nodes, agents and messages as they wish. The system guarantees that state changes of agents are always correct wrt. the contract. While control over the agents is centralised in one party, the system as a whole is decentralised. There are a number of nodes (peers termed notary) connected to each other in the consensus pool. Every request to one of them is broadcast to all notaries commissioned to the agent in question. Once a critical number of nodes (more than two thirds) agree that the change is permissible, the transaction is considered committed. created 2014-08-11
1834 The Wallet is an open source application for creating private currencies. Anyone can create an account, and issue units to it as they wish. The script guarantees that transfers between accounts are always correct (no account can have a negative balance). created 2014-08-11