bitshares / bitshares-core Goto Github PK
View Code? Open in Web Editor NEWBitShares Blockchain node and command-line wallet
Home Page: https://bitshares.github.io/
License: Other
BitShares Blockchain node and command-line wallet
Home Page: https://bitshares.github.io/
License: Other
From @theoreticalbts on July 22, 2015 15:10
Create an annual membership, renew it before expiration, make sure the date is pushed back the proper amount regardless of when the renewal occurs.
Then try renewing a lapsed annual membership. Make sure fees have reasonable semantics in the gap between expiry and renewal.
Copied from original issue: cryptonomex/graphene#180
From @theoreticalbts on August 19, 2015 17:9
Some big fat TODO's in db_market.cpp
here: https://github.com/cryptonomex/graphene/blob/eeeab17477a635fcff7f2d294dff8ecf25449b10/libraries/chain/db_market.cpp#L89-L116
This is basically to generate a virtual cancel op to inform account history listeners that orders have been cancelled due to certain asset management actions.
Copied from original issue: cryptonomex/graphene#250
From @theoreticalbts on July 31, 2015 15:22
Any operation with potentially unbounded size needs to charge a size fee. Determining whether an operation is variable-size is non-trivial. An operation is variable size if it contains a vector
, flat_set
or other potentially variable-size element.
Note that this containment may be through any number of intermediate struct
s. For example, any operation which contains an authority
has potentially unbounded size.
We should be able to audit this in a semi-automatic way with logic similar to js_operation_serializer
which traverses all operations, and noting any variable-size types found (in any number of sub-structures), allowing us to flag each operation as variable-sized (or not). We will still have to manually specify whether any base type is variable-size or not.
Copied from original issue: cryptonomex/graphene#216
From @theoreticalbts on July 22, 2015 15:21
Importing balance using PTS address needs to be tested. Since it is migration related, assigning to @vikramrajkumar
Copied from original issue: cryptonomex/graphene#185
From @bytemaster on July 2, 2015 17:14
The CLI cookbook instructions do not work because they have fallen behind the latest code changes. We need to update the cookbook and verify that following the instructions will work as advertised.
Copied from original issue: cryptonomex/graphene#129
From @theoreticalbts on August 20, 2015 21:47
witness_node
object_database
is created in the wrong placeCopied from original issue: cryptonomex/graphene#257
From @theoreticalbts on July 22, 2015 15:29
Specifically the withdraw permission shouldn't allow withdrawing of whitelisted asset when either source or destination account isn't whitelisted.
Copied from original issue: cryptonomex/graphene#188
From @pmconrad on July 3, 2015 14:58
I stumbled across this bitcoin-core/secp256k1#254 (comment) :
That said, your question makes it clear that the intended use isn't clear. That should definitely be clarified in the header file and perhaps a README. I guess it should list this:
- Do not create/destroy contexts for each call. Their creation is far slower than any library call, and part of their purpose is to reuse precomputed values across calls.
- If you perform signing, you should call context_randomize after initialization of the context, and perhaps on a regularly basis (daily?).
- When calling context_randomize pass in external entropy (perhaps from the operating system, perhaps from user input).
- You are responsible for locking. After initialization, only context_randomize requires exclusive locked, but the caller is responsible for not calling any other functions that use the context during randomization.
- If you do both validation and signing, you can either use a shared context for both, or separate contexts. One reason for using separate contexts if that for signing, calling context_randomize requires an exclusive lock on the context. If you need to do validation at the same time, it may be useful to separate them, so validation is not blocked by context randomization.
Apparently we need to call context_randomize regularly (for signing), with proper synchronization.
Copied from original issue: cryptonomex/graphene#131
From @theoreticalbts on July 22, 2015 15:31
Specifically you should trigger the test in the last two for
loops: https://github.com/cryptonomex/graphene/blob/dffc83cca9e710e509c307237a3767b966da2505/libraries/chain/proposal_object.cpp#L57-L60
Copied from original issue: cryptonomex/graphene#189
From @theoreticalbts on August 17, 2015 15:4
Negative block number -> relative to head
Copied from original issue: cryptonomex/graphene#236
From @bytemaster on June 30, 2015 20:54
These calls need to remain available only for authenticated connections.
Copied from original issue: cryptonomex/graphene#118
From @vikramrajkumar on June 25, 2015 16:29
can use the bitshares ones as starting points
Copied from original issue: cryptonomex/graphene#89
From @vikramrajkumar on June 9, 2015 17:40
No new shorts No forced settling No margin calls.
TODO: create test.
Copied from original issue: cryptonomex/graphene#8
From @valzav on July 6, 2015 18:19
It would be nice to have exceptions that we can translate to other languages in GUI.
In order to do this an exception may require to have some code or symbol and parameters, e.g. exception object might look like this:
{
error: "not-valid-address",
param1: "1EDJEW3508324LJDSF908342L",
eng: "Not valid address: %1",
message: "Not valid address: 1EDJEW3508324LJDSF908342L",
stack: ...
}
Copied from original issue: cryptonomex/graphene#135
From @theoreticalbts on August 20, 2015 21:42
broadcast
is false
, then place transaction into a local storeThe motivation here is to provide some way for cli_wallet
users to inspect fees before authorizing the transaction.
Copied from original issue: cryptonomex/graphene#256
From @theoreticalbts on July 22, 2015 16:7
Coverage claims unit tests don't hit cdd_vesting_policy::on_deposit_vested
. Why?
Copied from original issue: cryptonomex/graphene#197
From @abitmore on August 22, 2015 23:19
That's probably why it's hard to get into sync after got out of sync?
2015-08-22T22:20:33 p2p:message read_loop on_closing_connectio ] Peer 45.55.6.216:1776 is disconnecting us because of an error: You offered us a block that we reject as invalid, exception: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"fork_database.cpp","line":69,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-08-22T22:20:33"},"format":"item->num > std::max<int64_t>( 0, int64_t(_head->num) - (_max_size) ): attempting to push a block that is too old","data":{"item->num":174057,"head":174075,"max_size":10}},{"context":{"level":"warn","file":"db_block.cpp","line":176,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-08-22T22:20:33"},"format":"","data":{"new_block":{"previous":"0002a7e8b9613cd334a36aeccdb1d32460d8fa53","timestamp":"2015-08-22T22:20:14","witness":"1.6.4","next_secret_hash":"a6b9319cdc3465202c6ee6ba20f6fcfb4eb26211","previous_secret":"d879b9f9a141a1f9edc662fad77dcfa068e6562c","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2055c39c86e1dd8acc632ea55d010ce56dd01601106c3367fa5ae6b3d08d35a5567a545a0a23a1bace2bf651c049a2559ba75f8ba87b0e597fe9ca88f113a2804e","transactions":[]}}},{"context":{"level":"warn","file":"application.cpp","line":379,"method":"handle_block","hostname":"","thread_name":"th_a","timestamp":"2015-08-22T22:20:33"},"format":"","data":{"blk_msg":{"block":{"previous":"0002a7e8b9613cd334a36aeccdb1d32460d8fa53","timestamp":"2015-08-22T22:20:14","witness":"1.6.4","next_secret_hash":"a6b9319cdc3465202c6ee6ba20f6fcfb4eb26211","previous_secret":"d879b9f9a141a1f9edc662fad77dcfa068e6562c","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"2055c39c86e1dd8acc632ea55d010ce56dd01601106c3367fa5ae6b3d08d35a5567a545a0a23a1bace2bf651c049a2559ba75f8ba87b0e597fe9ca88f113a2804e","transactions":[]},"block_id":"0002a7e934a552405ffc797448a046e0bbf916d9"},"sync_mode":true}}]} node.cpp:2666
Copied from original issue: cryptonomex/graphene#262
From @theoreticalbts on July 22, 2015 15:17
The get_impacted_accounts()
function needs to be tested with all operation types. This will be an enormous test!
Copied from original issue: cryptonomex/graphene#183
From @theoreticalbts on July 22, 2015 16:8
Specifically, the unit tests need to hit this code: https://github.com/cryptonomex/graphene/blob/d827c5df281eafe43d6d0d00533ea0a0f2643c1c/libraries/chain/db_update.cpp#L256-L260
Copied from original issue: cryptonomex/graphene#198
From @theoreticalbts on July 22, 2015 15:5
The unit test should create several checkpoint(s) and verify the following:
Copied from original issue: cryptonomex/graphene#178
From @bytemaster on July 7, 2015 19:50
Can they resign, should they be able to, and if so how?
Copied from original issue: cryptonomex/graphene#143
From @bytemaster on August 18, 2015 19:32
The original purpose was to track blocks that get pushed and are then found to be invalid and then to prevent the fork database from accepting any additional blocks on top of that block.
Under BTS 0.x we had some issues where a block would get marked as invalid when it shouldn't have and then we would never be able to switch back to that fork. So there is some risk for marking things as invalid, but in theory the BTS 2 undo architecture shouldn't have the same issues.
Copied from original issue: cryptonomex/graphene#248
From @clayop on December 6, 2016 0:15
If a UIA issuer has authority to allow or deny users with whitelisting, a possibility of spam attack can be significantly reduced and easily controlled out. In this case, a UIA issuer may want to remove transaction fees from users to facilitate UIA usage, while the issuer pays the fee through the fee pool.
There is a potential customer in Korea(a local government) and if this feature is implemented, we are going to push it more.
Copied from original issue: cryptonomex/graphene#667
In this constructor, when the condition is false
, the content
field of the object won't be initialized, then it will lead to undefined behavior.
From @theoreticalbts on July 22, 2015 15:20
All predicates in assert.hpp need to be exercised by unit tests.
Copied from original issue: cryptonomex/graphene#184
From @theoreticalbts on August 17, 2015 18:8
Vote counts have no meaning for validation. Thus, c0c36ca should be a plugin.
Copied from original issue: cryptonomex/graphene#239
From @bytemaster on July 1, 2015 21:18
In the event of an bug in certain operations, witnesses need the ability to respond quickly and filter transactions that contain those operations.
Copied from original issue: cryptonomex/graphene#122
From @theoreticalbts on July 22, 2015 15:45
It doesn't really do anything, but the custom_operation
should be tested.
Copied from original issue: cryptonomex/graphene#194
I guess it's safe to do so. See steemit/fc@b07f429
From @theoreticalbts on July 22, 2015 15:23
The whitelist_markets
and blacklist_markets
are properties on an asset. But first we must ask, what are the intended semantics of these fields?
Assigning to @bytemaster to answer this question.
Copied from original issue: cryptonomex/graphene#186
From @clayop on August 7, 2015 21:55
Followed instruction in Readme.md
CMake Error in libraries/fc/CMakeLists.txt:
Imported target "secp256k1" includes non-existent path
"/home/clayop/graphene/libraries/fc/vendor/secp256k1-zkp/include"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
Copied from original issue: cryptonomex/graphene#226
From @vikramrajkumar on June 9, 2015 17:44
Here are the problems with database_fixture:
Copied from original issue: cryptonomex/graphene#11
From @theoreticalbts on July 22, 2015 16:6
The account_transfer_operation
needs to be tested as follows:
Copied from original issue: cryptonomex/graphene#196
If a UIA issuer has authority to allow or deny users with whitelisting, a possibility of spam attack can be significantly reduced and easily controlled out. In this case, a UIA issuer may want to remove transaction fees from users to facilitate UIA usage, while the issuer pays the fee through the fee pool.
There is a potential customer in Korea(a local government) and if this feature is implemented, we are going to push it more.
Note: The original issuance is here
From @vikramrajkumar on June 23, 2015 22:1
Copied from original issue: cryptonomex/graphene#77
From @theoreticalbts on June 24, 2015 14:46
We should provide a rigorous mode to check invariants at each op, each tx, or each block. This can be used as a debugging tool on both test cases and live networks.
Copied from original issue: cryptonomex/graphene#82
From @theoreticalbts on July 22, 2015 15:14
In particular it appears no test in chain_test creates a new linear vesting policy.
Copied from original issue: cryptonomex/graphene#181
From @theoreticalbts on July 22, 2015 15:37
Make sure there is reasonable behavior if witness budget is equal to zero. This unit test may need to artificially change the block interval or witness budget variables by directly affecting the database, as this condition may not be possible in the real blockchain.
This may already be implemented somewhere...
Copied from original issue: cryptonomex/graphene#190
From @theoreticalbts on July 22, 2015 15:42
Specifically, https://github.com/cryptonomex/graphene/blob/dffc83cca9e710e509c307237a3767b966da2505/libraries/chain/db_maint.cpp#L110-L116 should be covered by this test.
Copied from original issue: cryptonomex/graphene#191
From @theoreticalbts on August 20, 2015 22:9
cli_wallet
does not save the private key for a new witness until the witness is registered on chain; this is wrong.
Copied from original issue: cryptonomex/graphene#259
From @theoreticalbts on August 18, 2015 16:21
Implementation of cryptonomex/graphene#236 has revealed a general issue when extending API calls. When adding parameters to an API call, it has been noted that we should have a cycle of introducing a new call, deprecating the old call, waiting for web UI code to be updated, and then removing the old call.
The deprecation cycle is necessary because adding parameters to an API call breaks every API client that uses that call, even if the new parameters have default values, because the FC reflection API does not understand how to interact with default values due to underlying deficiencies in C++
In this ticket, I propose a solution to this problem: Most or all API calls should be rewritten to take a single struct
, containing the values that were previously passed as separate arguments. Defaults can then be placed in the C++ struct
definition, and if some fields do not occur in the JSON dictionary provided by the client, then those fields should not be assigned by the API framework and thus will have their default values.
I should test that the API framework does in fact give fields that do not exist in the JSON object their default values.
Copied from original issue: cryptonomex/graphene#245
From @theoreticalbts on July 22, 2015 15:25
MIA's can have their backing asset changed, but only when there is no supply. The unit test should verify:
Copied from original issue: cryptonomex/graphene#187
From @theoreticalbts on July 14, 2015 22:24
After fixing generally obsolete app_test
in cfd9dd0 I notice that every few runs, I get the following error:
$ sudo -u graphene -H tests/app_test --log_level=message
Running 1 test case...
Creating temporary files
Creating and initializing app1
Creating and initializing app2
Starting app1 and waiting 500 ms
1209829ms th_a application.cpp:190 operator() ] Initializing database...
1209838ms th_a application.cpp:63 create_example_genes ] Allocating all stake to 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
1209843ms th_a thread.cpp:95 thread ] name:p2p tid:139731355076352
1209845ms th_a application.cpp:118 reset_p2p_node ] Configured p2p node to listen on 127.0.0.1:3939
Starting app2 and waiting 500 ms
1210345ms th_a application.cpp:190 operator() ] Initializing database...
1210345ms th_a application.cpp:63 create_example_genes ] Allocating all stake to 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
1210349ms th_a thread.cpp:95 thread ] name:p2p tid:139731255420672
1210350ms th_a application.cpp:107 reset_p2p_node ] Adding seed node 127.0.0.1:3939
1210351ms th_a application.cpp:118 reset_p2p_node ] Configured p2p node to listen on 127.0.0.1:4040
/home/cc/graphene/src/graphene/tests/app/main.cpp(74): fatal error in "two_node_network": critical check app1.p2p_node()->get_connection_count() == 1 failed [0 != 1]
1210852ms th_a thread.cpp:115 ~thread ] calling quit() on p2p
1210852ms th_a thread.cpp:160 quit ] destroying boost thread 139731255420672
1210890ms th_a thread.cpp:115 ~thread ] calling quit() on p2p
1210890ms th_a thread.cpp:160 quit ] destroying boost thread 139731355076352
1210890ms p2p thread.cpp:246 exec ] thread canceled: 9 canceled_exception: Canceled
cancellation reason: [none given]
{"reason":"[none given]"}
p2p thread_d.hpp:463 start_next_fiber
*** 1 failure detected in test suite "Test Application"
This does not happen on every run, but usually shows up after several runs, if you don't see it after ~10 runs then I would assume your environment is unable to reproduce it.
A similar bug in the past was cryptonomex/graphene#55
Copied from original issue: cryptonomex/graphene#159
From @theoreticalbts on August 18, 2015 18:19
Currently our plugin architecture is not well encapsulated. Here are some problems I found:
operation_history_object
in the core.most_recent_op
in account_object
as noted in the comment here.meta_account_object
.market_history
and account_history
plugins use the same space ID.account_history_plugin.hpp
noting that an object ID definition applies to the market history plugin!witness_node
binary with no account_history_plugin
, and in fact should encourage active witnesses to run the stripped-down version without unnecessary indexes.Copied from original issue: cryptonomex/graphene#246
From @theoreticalbts on August 20, 2015 21:59
We need a witness_update_operation
to be able to update block_signing_key
and url
field of a witness
object.
Setting the block_signing_key
to zero should not be allowed (this will be reserved for when/if we implement witness resignation). There should also be a memo field in the operation which contains the secret, encrypted to the new signing key. The memo field should be vector<char>
.
Copied from original issue: cryptonomex/graphene#258
From @nathanhourt on August 17, 2015 20:49
Following up on #237, there are some limitations of the initial implementation. Primarily, that the delayed node does not handle forking right now.
Optimally, the delayed node will check that the block ID's match for a given block number between its trusted node and itself, and, if they don't, pop blocks until they do. If it runs out of undo history, it needs to resync (this is currently hard to do without restarting the process, as it's impossible to clear the object graph from memory without destroying the database
). Then it will resume syncing from the trusted node as usual.
Copied from original issue: cryptonomex/graphene#240
From @theoreticalbts on July 22, 2015 15:43
The unit test should cover https://github.com/cryptonomex/graphene/blob/dffc83cca9e710e509c307237a3767b966da2505/libraries/chain/db_market.cpp#L439-L446
Copied from original issue: cryptonomex/graphene#192
From @theoreticalbts on July 28, 2015 15:9
generate_empty_blocks
queries the implementation for the time of the next block. The time of each block (including maintenance intervals) should be verified by some test (perhaps added to generate_empty_blocks
, perhaps a new test case).
Copied from original issue: cryptonomex/graphene#208
From @theoreticalbts on July 22, 2015 15:8
Create a unit test for an MIA backed by a non-CORE asset.
Copied from original issue: cryptonomex/graphene#179
From @bytemaster on June 30, 2015 18:18
Right now a test checking for an exception will pass regardless of what type of error actually occurred. For the tests to be valid every exception that we test for needs to be explicit.
Copied from original issue: cryptonomex/graphene#113
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.