The XBR Protocol - blockchain protocol for decentralized open data markets
Home Page: https://xbr.network
License: Other
Welcome to the Web Application Messaging Protocol (WAMP) GitHub repository. If you are new to WAMP, please find out more at our homepage here.
For opening (and closing) payment channels, the client needs to call into XBRNetwork contract functions with respective data, and a signature over that data.
We could come up with some ad-hoc signing mechanism - or we could use EIP712 with the new eth_signTypedData function.
0.5.2 there https://github.com/xbr/xbr-protocol/blob/1189b0a0ecac4a523dba22dcd25d976d8274c7ea/truffle.js#L48pragma solidity ^0.5.2; here (and similar): https://github.com/xbr/xbr-protocol/blob/master/contracts/XBRNetwork.sol#L19Add a CI run test (to be run in the repo here) with:
Using ecrevoer to check a signature created with eth_sign.
signature over keccak256("\x19Ethereum Signed Message:\n" + len(givenMessage) + givenMessage)))
We want to use a token standard that is widespread and accepted in the market - which at the moment is ERC20.
At the same time, newer token standards may provide features that we need/can use to make our life easier.
Candidates for evaluation:
Expand all gas consuming (write transactional) SC functions in XBR smart contracts with bytes signature to allow delegated ETH/gas-less operation
For companies using XBR, market operators, as well as corporate buyers/sellers will likely need/want integration into existing processes rgd financial authority/oversight.
We need to hash out how this works in xbr ..
Eg https://www.bitgo.com/services/business-wallet provides hosted wallets with:
differrent roles:
different policies:
on-chain multisig contracts:
for crossbarfx (administrative) domains and nodes, we originally had code in XBRNetwork:
this code was removed because:
this code should be rather be revived, but on a new contract XBRDomain ..
The "XBR protocol" is largely defined by the API surface and semantics exposed by the smart contracts XBR develops and deploys to Ethereum as the global blockchain underpinning XBR powered open data markets.
The question arises as to what license these smart contracts (the sour code) should be licensed under.
The viable options include:
I am leaning towards LGPL currently, but lets discuss the pros and cons!
Currently, the XBR token is the sole means of payment in XBR data markets. An alternative design would look like this:
XBRNetwork.createMarket, we allow specifying the ERC20 token that is to be used in that market as a means of paymentCentrally give an overview of the constituent parts of XBR and how they interact to form the whole.
Here is a payment transaction over 35 XBR failing - leaving the payment channel nevertheless non-zero (at remaining 20 XBR):
Errors thrown in contract code (eg via revert()) can be seen in the blockchain node log, including the error reason, but currently pop up as generic errors on ABJS side which don't expose the original error reason anymore.
Here is what the node log shows
ganache_1 | eth_sendRawTransaction
ganache_1 |
ganache_1 | Transaction: 0x5c06c12827e680d1508c9a978b20f19854c87a579be59ba2bc3991267aed0979
ganache_1 | Gas usage: 1194773
ganache_1 | Block Number: 18
ganache_1 | Block Time: Tue Oct 08 2019 08:28:05 GMT+0000 (Coordinated Universal Time)
ganache_1 | Runtime Error: revert
ganache_1 | Revert reason: SafeMath: subtraction overflow
ganache_1 |
or
ganache_1 | eth_sendRawTransaction
ganache_1 |
ganache_1 | Transaction: 0x6542831ca8a37817791b5d7ae6f2a165245dc3df4bf9e52bd62bd64038dd12b1
ganache_1 | Gas usage: 26813
ganache_1 | Block Number: 16
ganache_1 | Block Time: Tue Oct 08 2019 08:26:11 GMT+0000 (Coordinated Universal Time)
ganache_1 | Runtime Error: revert
ganache_1 | Revert reason: INVALID_CHANNEL_RECIPIENT
ganache_1 |
while here is what ABJS console in browser shows (for the first of above):
MetaMask - RPC Error: Internal JSON-RPC error. {code: -32603, message: "Internal JSON-RPC error.", data: {…}, stack: "Error: Error: [ethjs-rpc] rpc error with payload {…method":"eth_sendRawTransaction"} [object Object]"}
10:34:38.198 inpage.js:1 MetaMask - RPC Error: Internal JSON-RPC error. {code: -32603, message: "Internal JSON-RPC error.", data: {…}, stack: "Error: "message" must be a nonempty string.↵
10:34:38.200 autobahn-xbr.js:165973 Uncaught (in promise) Error: Internal JSON-RPC error.
{
"originalError": {}
}
async function (async)
test_open_payment_channel @ xbr-market.js:296
aux info:
APIs are central for XBR, as that is what XBR services implement. A XBR Consumer naturally will need information on the API to consume, and depending on kind of API, the expectation regarding the typing strictness of the API could range to "fully statically typed".
So what we need in XBR is an interface definition language to specify more or less typed WAMP interfaces with additional XBR related information.
The steps:
The generated docs should include API reference for XBR client library for Python.
This depends on cag/sphinxcontrib-soliditydomain#4
For metadata, eula and terms documents, we currently only support IPFS mutlihashes, as in
* to a ZIP archive file with market documents.
* @param meta The XBR market metadata published by the market owner. IPFS Multihash pointing
* to a RDF/Turtle file with market metadata.
In addition to IPFS, we should also support plain HTTP URLs pointing to files.
To save gas, we should remove all manually written getters, and simply rely on the auto-generated ones for public state variables (see https://ethereum.stackexchange.com/a/46031/17806)
tryin to get coverage running, I wasted like 3h getting over the "gas limit exceeded" problem (the instrumented smart contracts require more gas to deploy, sure, but the gas settings are already high):
(cpy371_1) oberstet@thinkpad-x1:~/scm/xbr/xbr-protocol$ make coverage
#./node_modules/.bin/solidity-coverage
npm run coverage
> [email protected] coverage /home/oberstet/scm/xbr/xbr-protocol
> solidity-coverage
Generating coverage environment
Running: truffle compile --network coverage
(this can take a few seconds)...
Compiling ./contracts/Migrations.sol...
Compiling ./contracts/XBRMaintained.sol...
Compiling ./contracts/XBRNetwork.sol...
Compiling ./contracts/XBRNetworkProxy.sol...
Compiling ./contracts/XBRPaymentChannel.sol...
Compiling ./contracts/XBRToken.sol...
Compiling openzeppelin-solidity/contracts/access/Roles.sol...
Compiling openzeppelin-solidity/contracts/cryptography/ECDSA.sol...
Compiling openzeppelin-solidity/contracts/math/SafeMath.sol...
Compiling openzeppelin-solidity/contracts/token/ERC20/ERC20.sol...
Compiling openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol...
Compiling openzeppelin-solidity/contracts/token/ERC20/IERC20.sol...
Writing artifacts to ./build/contracts
Skipping instrumentation of ./coverageEnv/contracts/Migrations.sol
Skipping instrumentation of ./coverageEnv/contracts/XBRMaintained.sol
Skipping instrumentation of ./coverageEnv/contracts/XBRNetwork.sol
Skipping instrumentation of ./coverageEnv/contracts/XBRNetworkProxy.sol
Skipping instrumentation of ./coverageEnv/contracts/XBRPaymentChannel.sol
Instrumenting ./coverageEnv/contracts/XBRToken.sol
Running: truffle compile --network coverage
(this can take a few seconds)...
Compiling ./contracts/Migrations.sol...
Compiling ./contracts/XBRMaintained.sol...
Compiling ./contracts/XBRNetwork.sol...
Compiling ./contracts/XBRNetworkProxy.sol...
Compiling ./contracts/XBRPaymentChannel.sol...
Compiling ./contracts/XBRToken.sol...
Compiling openzeppelin-solidity/contracts/access/Roles.sol...
Compiling openzeppelin-solidity/contracts/cryptography/ECDSA.sol...
Compiling openzeppelin-solidity/contracts/math/SafeMath.sol...
Compiling openzeppelin-solidity/contracts/token/ERC20/ERC20.sol...
Compiling openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol...
Compiling openzeppelin-solidity/contracts/token/ERC20/IERC20.sol...
Compilation warnings encountered:
...
Writing artifacts to ./build/contracts
Launched testrpc on port 8555
Running: truffle test --network coverage
(this can take a few seconds)...
Using network 'coverage'.
Error: Exceeds block gas limit
at Object.InvalidResponse (/home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/web3/lib/web3/errors.js:38:1)
at /home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/web3/lib/web3/requestmanager.js:86:1
at /home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/packages/truffle-migrate/index.js:225:1
at /home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/packages/truffle-provider/wrapper.js:134:1
at XMLHttpRequest.request.onreadystatechange (/home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/web3/lib/web3/httpprovider.js:128:1)
at XMLHttpRequestEventTarget.dispatchEvent (/home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:64:1)
at XMLHttpRequest._setReadyState (/home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:354:1)
at XMLHttpRequest._onHttpResponseEnd (/home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:509:1)
at IncomingMessage.<anonymous> (/home/oberstet/scm/xbr/xbr-protocol/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:469:1)
at emitNone (events.js:111:20)
at IncomingMessage.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickCallback (internal/process/next_tick.js:180:9)
Cleaning up...
Shutting down testrpc-sc (pid 8921)
Event trace could not be read.
Error: ENOENT: no such file or directory, open './allFiredEvents'
Exiting without generating coverage...
npm ERR! Linux 4.15.0-39-generic
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "run" "coverage"
npm ERR! node v8.10.0
npm ERR! npm v3.5.2
npm ERR! code ELIFECYCLE
npm ERR! [email protected] coverage: `solidity-coverage`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] coverage script 'solidity-coverage'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the xbr package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! solidity-coverage
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs xbr
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls xbr
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /home/oberstet/scm/xbr/xbr-protocol/npm-debug.log
Makefile:55: recipe for target 'coverage' failed
make: *** [coverage] Error 1
(cpy371_1) oberstet@thinkpad-x1:~/scm/xbr/xbr-protocol$
moved from https://github.com/xbr/xbr-network/issues/13
needed in https://github.com/xbr/xbr-network/issues/8, and there is only ECDSA built in.
The latest Ethereum hard fork should have brought the features needed in Solidity (or the VM under the hood) to implement Ed25519, which is used by WAMP-cryptosign and WAMP-cryptobox.
What changes are included in the Byzantium hard fork? https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/
https://ethereum.stackexchange.com/questions/42771/ed25519-in-smart-contracts
From: https://media.consensys.net/metamask-at-devcon-privacy-standards-mobile-and-more-d826225b9b4b
Easy token tracking (EIP 747)
Many of our users struggle with manually adding token addresses so that MetaMask can display their token balances. Instead, dapps can now suggest specific tokens directly to MetaMask to track
We should go through all of
Further, for an external audit, we should consider
when log events are processed in ABPy or ABJS, we currently get this error:
web3.exceptions.MismatchedABI: ("The function 'members' was not found in this contract's abi. ", 'Are you sure you provided the correct contract abi?')'
this happens despite using the latest/matching ABI files ..
MismatchedABI: Raised when an ABI does not match with supplied parameters, or when an attempt is made to access a function/event that does not exist in the ABI.
A seller delegate may offer an instance of a service that provides data, conforming to an API (which is available in a given market).
Eg seller 7 registered in a market 3 may announce that one of its (seller 7) seller delegates is providing a service that implements API 6.
This announcment is a willing commitment of seller 7 to provide the respective data - in other words, seller 7 gives his consent to that.
We need to track this consent on-chain in a SC.
Providers (sellers) of data provide that data by implementing and running services which implement a given API.
The API definition allows buyers to write consuming services (which use the data providing service) against a known interface.
Thus, service APIs exist independently of markets, sellers and buyers.
A service API must be identifyable using a globally unique ID and may also provide strict interface schemata and developer documentation.
Once a service API is defined and pubslihed, market operators may chose to allow the API in a market, and once that is done, data service providers joined to that market may announce that they provide seller delegates which implement that API (see #38)
docs build currently breaks for me. contents of docs/api/python.rst are responsible (commenting out all the definitions for classes leads to the build running fine)
reading sources... [ 9%] api/python
Exception occurred:
File "/home/goeddea/venvs/cpy370/lib/python3.7/site-packages/sphinx/ext/autodoc/__init__.py", line 296, in can_document_member
raise NotImplementedError('must be implemented in subclasses')
NotImplementedError: must be implemented in subclasses
limit total amount the market maker is willing to open paying channels for a seller
Currently, every payment/paying channel runs on its own deployed contract instance. IOW, opening a payment/paying channel leads to a new contract instance being deployed, which is expensive in gas cost.
| Gas price (Gwei / unit gas) | 8 | |||
|---|---|---|---|---|
| ETH price (EUR / ETH) | 175,00 € | |||
| Deploy XBRToken | 812.557 | 1,14 € | ||
| Deploy XBRNetwork | 6.664.891 | 9,33 € | ||
| Send ETH | 21.000 | 0,03 € | ||
| Send XBR | 51.852 | 0,07 € | ||
| all users | XBRNetwork.register | 138.393 | 0,19 € | |
| market operators | XBRNetwork.createMarket | 175.167 | 0,25 € | |
| buyers + sellers | XBRNetwork.joinMarket | 80.330 | 0,11 € | |
| buyers | XBRNetwork.openPaymentChannel | Tx 1: approve tokens | 45.913 | 0,06 € |
| Tx 2: open channel | 1.266.775 | 1,77 € | ||
| sellers | XBRNetwork.requestPayingChannel | Tx 1: approve tokens | 33.758 | 0,05 € |
| market makers | XBRNetwork.openPayingChannel | Tx 2: open channel | 30.913 | |
| 1.266.854 |
An alternative design would only deploy 1 XBRChannel contract instance per market.
Doing so would lead to ~ 0.20-0.30 USD (20-30 cents) gas cost per channel open.
Participants should be able to be both data consumer and data provider in a single market.
This is a central part of the data value chains we champion: A participant consumes data in a market and provides insight based on this - in the same market.
It is also something that we explicitly mention throughout the whitepaper.
Design: compute a hash from the (ordered) concatenation of all off-chain transaction IDs (in the market maker) and include that hash when closing a payment channel - so that the hash is stored along on-chain.
This allows to close the audit loop of what exactly has been billed at the single transaction level - not only the ultimate amount cleared on-chain.
Financially, it doesn't matter: whether I earned/spent 100 XBR in a payment channel as 1x 100 XBR transaction or 100x 1 XBR transaction doesn't matter. Also the order doesn't matter. It is the 100 XBR I care about.
However, if and when the market maker provides an itemized bill down to the single XBR transaction level to the stakeholder, that stakeholder might want to cross-check that itemized bill and the individual transactions versus on-chain information.
Technically, the XBR (on-chain) API consists of
XBRNetworkProxy instance as deployed to the Ethereum mainnet (eg 0x254dffcd3277c0b1660f6d42efbb754edababc2b), andThe code from which the ABI files are generated can be found in this repository (under the MIT license) and is deployed to Ethereum mainnet and published by the XBR project.
The XBRNetworkProxy instance points to the (current) XBRNetwork instance, which contains the address of the XBRToken instance, and creates instances of the XBRChannel smart contract.
(cpy373_1) oberstet@intel-nuci7:~/scm/crossbario/xbr-protocol$ ll abi/
insgesamt 4296
drwxr-xr-x 2 oberstet oberstet 4096 Jul 24 15:38 ./
drwxr-xr-x 15 oberstet oberstet 4096 Jul 23 11:03 ../
-rw-r--r-- 1 oberstet oberstet 101834 Jul 24 15:38 ECDSA.json
-rw-r--r-- 1 oberstet oberstet 54266 Jul 24 15:38 ERC20Detailed.json
-rw-r--r-- 1 oberstet oberstet 478435 Jul 24 15:38 ERC20.json
-rw-r--r-- 1 oberstet oberstet 69280 Jul 24 15:38 IERC20.json
-rw-r--r-- 1 oberstet oberstet 52462 Jul 24 15:38 Migrations.json
-rw-r--r-- 1 oberstet oberstet 90030 Jul 24 15:38 Roles.json
-rw-r--r-- 1 oberstet oberstet 144670 Jul 24 15:38 SafeMath.json
-rw-r--r-- 1 oberstet oberstet 333666 Jul 24 15:38 XBRChannel.json
-rw-r--r-- 1 oberstet oberstet 97211 Jul 24 15:38 XBRMaintained.json
-rw-r--r-- 1 oberstet oberstet 2865518 Jul 24 15:38 XBRNetwork.json
-rw-r--r-- 1 oberstet oberstet 26042 Jul 24 15:38 XBRNetworkProxy.json
-rw-r--r-- 1 oberstet oberstet 58911 Jul 24 15:38 XBRToken.json
Using above information, any programming language and run-time with Ethereum support (such as web3.js or web3.py) can be used to talk to the XBR smart contracts on-chain.
EIP712 contains the chain ID in signed typed data to prohibit cross-chain replay attacks.
We should run-time read the chain ID from within Solidity in the channel contract - currently, its hard-coded:
unfortunately, the ABI file generation currently includes a timestamp:
"updatedAt": "2019-07-25T13:20:34.084Z"
is it possible to disable inclusion of updatedAt?
here is the full diff of simply rerunning make compile without any change to sources:
(cpy373_1) oberstet@intel-nuci7:~/scm/crossbario/xbr-protocol$ git diff
diff --git a/abi/ECDSA.json b/abi/ECDSA.json
index be896e4..2344edd 100644
--- a/abi/ECDSA.json
+++ b/abi/ECDSA.json
@@ -2343,7 +2343,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.084Z",
+ "updatedAt": "2019-07-25T17:42:15.331Z",
"devdoc": {
"details": "Elliptic Curve Digital Signature Algorithm (ECDSA) operations. * These functions can be used to verify that a message was signed by the holder of the private keys of a given address.",
"methods": {}
diff --git a/abi/ERC20.json b/abi/ERC20.json
index 6d65bb5..3d0312b 100644
--- a/abi/ERC20.json
+++ b/abi/ERC20.json
@@ -11015,7 +11015,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.085Z",
+ "updatedAt": "2019-07-25T17:42:15.332Z",
"devdoc": {
"details": "Implementation of the `IERC20` interface. * This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using `_mint`. For a generic mechanism see `ERC20Mintable`. * *For a detailed writeup see our guide [How to implement supply mechanisms](https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226).* * We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. * Additionally, an `Approval` event is emitted on calls to `transferFrom`. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. * Finally, the non-standard `decreaseAllowance` and `increaseAllowance` functions have been added to mitigate the well-known issues around setting allowances. See `IERC20.approve`.",
"methods": {
diff --git a/abi/ERC20Detailed.json b/abi/ERC20Detailed.json
index 0745bec..109aed5 100644
--- a/abi/ERC20Detailed.json
+++ b/abi/ERC20Detailed.json
@@ -1526,7 +1526,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.086Z",
+ "updatedAt": "2019-07-25T17:42:15.334Z",
"devdoc": {
"details": "Optional functions from the ERC20 standard.",
"methods": {
diff --git a/abi/IERC20.json b/abi/IERC20.json
index ce8e101..589d139 100644
--- a/abi/IERC20.json
+++ b/abi/IERC20.json
@@ -1853,7 +1853,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.086Z",
+ "updatedAt": "2019-07-25T17:42:15.334Z",
"devdoc": {
"details": "Interface of the ERC20 standard as defined in the EIP. Does not include the optional functions; to access them see `ERC20Detailed`.",
"methods": {
diff --git a/abi/Migrations.json b/abi/Migrations.json
index b8bd8be..6b2872d 100644
--- a/abi/Migrations.json
+++ b/abi/Migrations.json
@@ -1368,7 +1368,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.069Z",
+ "updatedAt": "2019-07-25T17:42:15.317Z",
"devdoc": {
"methods": {}
},
diff --git a/abi/Roles.json b/abi/Roles.json
index 01147fa..765ff56 100644
--- a/abi/Roles.json
+++ b/abi/Roles.json
@@ -2163,7 +2163,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.083Z",
+ "updatedAt": "2019-07-25T17:42:15.331Z",
"devdoc": {
"details": "Library for managing addresses assigned to a Role.",
"methods": {},
diff --git a/abi/SafeMath.json b/abi/SafeMath.json
index 2905c2a..a18d5b3 100644
--- a/abi/SafeMath.json
+++ b/abi/SafeMath.json
@@ -3495,7 +3495,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.084Z",
+ "updatedAt": "2019-07-25T17:42:15.332Z",
"devdoc": {
"details": "Wrappers over Solidity's arithmetic operations with added overflow checks. * Arithmetic operations in Solidity wrap on overflow. This can easily result in bugs, because programmers usually assume that an overflow raises an error, which is the standard behavior in high level programming languages. `SafeMath` restores this intuition by reverting the transaction when an operation overflows. * Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always.",
"methods": {}
diff --git a/abi/XBRChannel.json b/abi/XBRChannel.json
index c7ec039..28b4afd 100644
--- a/abi/XBRChannel.json
+++ b/abi/XBRChannel.json
@@ -8232,7 +8232,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.069Z",
+ "updatedAt": "2019-07-25T17:42:15.318Z",
"devdoc": {
"methods": {
"constructor": {
diff --git a/abi/XBRMaintained.json b/abi/XBRMaintained.json
index f7becf9..18df830 100644
--- a/abi/XBRMaintained.json
+++ b/abi/XBRMaintained.json
@@ -2486,7 +2486,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.071Z",
+ "updatedAt": "2019-07-25T17:42:15.319Z",
"devdoc": {
"methods": {
"addMaintainer(address)": {
diff --git a/abi/XBRNetwork.json b/abi/XBRNetwork.json
index e8ff975..12c657b 100644
--- a/abi/XBRNetwork.json
+++ b/abi/XBRNetwork.json
@@ -63614,7 +63614,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.071Z",
+ "updatedAt": "2019-07-25T17:42:15.319Z",
"devdoc": {
"author": "The XBR Project",
"methods": {
diff --git a/abi/XBRNetworkProxy.json b/abi/XBRNetworkProxy.json
index dd0be98..da5c3c9 100644
--- a/abi/XBRNetworkProxy.json
+++ b/abi/XBRNetworkProxy.json
@@ -550,7 +550,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.083Z",
+ "updatedAt": "2019-07-25T17:42:15.331Z",
"devdoc": {
"author": "The XBR Project",
"methods": {
diff --git a/abi/XBRToken.json b/abi/XBRToken.json
index 8abad92..35f9dfc 100644
--- a/abi/XBRToken.json
+++ b/abi/XBRToken.json
@@ -1207,7 +1207,7 @@
},
"networks": {},
"schemaVersion": "3.0.5",
- "updatedAt": "2019-07-25T13:20:34.083Z",
+ "updatedAt": "2019-07-25T17:42:15.331Z",
"devdoc": {
"methods": {
"allowance(address,address)": {
eth-abi 1.2.2 has requirement eth-typing<2, but you'll have eth-typing 2.0.0 which is incompatible.
One feedback we got from early app developers is that the terms "payment channel" and "paying channel" are confusing.
We should rename those as in:
All XBR network members must accept our XBR EULA when registering:
The EULA must be stored on IPFS .. as a ZIP file containing:
oberstet@thinkpad-x1:~/scm/crossbario/xbr-protocol$ ipfs cat QmU7Gizbre17x6V2VR1Q2GJEjz6m8S1bXmBtVxS2vmvb81 > /tmp/eula.zip
(cpy373_1) oberstet@thinkpad-x1:~/scm/crossbario/xbr-protocol$ unzip /tmp/eula.zip
Archive: /tmp/eula.zip
creating: xbr-eula/
inflating: xbr-eula/README.txt
inflating: xbr-eula/XBR-EULA.txt
inflating: xbr-eula/COPYRIGHT.txt
contracts diff: git diff v19.9.3 v19.9.2 -- contracts/
new contract addresses (see below):
export XBR_DEBUG_TOKEN_ADDR="0x513e562afeF8e000dcA06FCb246Cff3ec76CC088"
export XBR_DEBUG_NETWORK_ADDR="0xA7C21Bf0a7ec32f4c86C83c1F990a50aa8Aa069a"
new EULA: QmV1eeDextSdUrRUQp9tUXF8SdvVeykaiwYLgrXHHVyULY
Deploying contracts from 0xf766Dc789CF04CD18aE75af2c5fAf2DA6650Ff57 with gas 6900000 ..
Deploying 'XBRToken'
--------------------
> transaction hash: 0xd464a4d655fc2e863b1ba1af0dab1afb789c84c5a6961f52f8cd016a7febaed5
> Blocks: 1 Seconds: 28
> contract address: 0x513e562afeF8e000dcA06FCb246Cff3ec76CC088
> block number: 6350652
> block timestamp: 1567935922
> account: 0xf766Dc789CF04CD18aE75af2c5fAf2DA6650Ff57
> balance: 2.172221712
> gas used: 812621
> gas price: 20 gwei
> value sent: 0 ETH
> total cost: 0.01625242 ETH
Deploying 'XBRNetwork'
----------------------
> transaction hash: 0x2e22099495b383c5e918ca3f56c7b49a1b80724b3f50d3ab11dec9a6e107202b
> Blocks: 1 Seconds: 16
> contract address: 0xA7C21Bf0a7ec32f4c86C83c1F990a50aa8Aa069a
> block number: 6350654
> block timestamp: 1567935957
> account: 0xf766Dc789CF04CD18aE75af2c5fAf2DA6650Ff57
> balance: 2.038925172
> gas used: 6664827
> gas price: 20 gwei
> value sent: 0 ETH
> total cost: 0.13329654 ETH
> Saving migration to chain.
> Saving artifacts
-------------------------------------
> Total cost: 0.14954896 ETH
Summary
=======
> Total deployments: 3
> Final cost: 0.15397238 ETH
We should allow to upgrade our contract logic in the field (after deployment to mainnet):
core api fixed and frozen via #43
Analyze scenarios such as:
Above is the standard process.
Now, when the payment channel is closed (say upon manual trigger from the seller side), the earned amount M (minus transaction fees) is transferred to the seller, and the channel is closed on-chain.
The latter (on-chain clearing) requires (in the market maker driven process) an on-chain transaction - and that consumes G gas (in ETH), which (again, in the regular process) is paid by the market maker.
What if G > M_ETH?
Here, the notation of M_ETH is the value of M XBR as converted to ETH.
sidenote: 2 things come into play here: the on-chain "current gas rate" (in ETH) / the actual gas paid by the market maker, and the conversion rate of XBR=>ETH. both of which are not globally unique rates, but the effective actual rates depend on the actual exchange rates (eg XBR<=>ETH), on the exchange. This is a non-trivial side aspect to follow up ..
So the "attack" here is about the seller tricking the market maker into accepting and processing paying channels and payments in a way that is net negative financially for the market maker.
Obviously, something the market maker would not want to do;)
We do already have a general safeguard in this, simply because there can be a hard minimum amount (in XBR) for payment channels (via the market definition).
That is, if PC_min (in XBR) > M (in XBR) > G (in XBR converted from ETH), everything is fine.
NodeLicense_NULL = 0
NodeLicense_INFINITE = 1
NodeLicense_FREE = 2
with
xbr.xbrnetwork.functions.pairNode(_node_id, _domain_id, _nodeType, _nodeLicense, _pubkey, _config).transact({'from': acct, 'gas': 200000})
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.