signum-network / signum-node Goto Github PK

This would give miners the option to, when solo mining, set their passphrase in the configuration of their local node and when submitting nonces only provide their account id. BRS would then lookup their account ID in the config and use the stored passphrase. This would prevent miners from submitting their passphrase over a network at all.

Currently, there are 36 classes in the brs package. This should be reduced to 4 or 5:

• Burst.java

• BurstGUI.java

• BurstLauncher.java

• Constants.java

• (Perhaps) BurstException.java

The rest of the classes need to be sorted into relevant packages correctly.

In order to help aid a smooth user experience, a user should be able to run a node on a desktop outside of a command line / terminal.

We should have an extra class with a main function that starts a JavaFX GUI which stdout and stderr are piped to, and then start the main of the Burst class. There should also be a button to restart the program if needed.

Shutdown hooks etc. Should also be handled correctly by the GUI wrapper. It should be simple, just have a text area where stdout/stderr is displayed, and is should be the Main-Class of the jar so that it launches when double clicked.

This is NOT supposed to be a way to interact with the node, and is not an alternative to the standalone GUI that is being developed. It is simply there to provide a better user experience.

The window for "Payout Dividend" is not working properly.
I can´t set a Dividend date nor an account i want to disclose.
All fields are greyed out and not selectable.

Also the fee is one BURST per account i need to send the dividend!
As this is an ordinary payment i should be able to use the normal fee structure from BURST

I use Version 2.3.0.
I tried via localhost and internal within the wallet - both show the same result

Can someone also check the query behind please - it is terrible slow take 3702027329806229573 as reference

Coverage is currently less than 25% - this needs to be improved.

It is an issue for certain users to get protoc running.

1 Burst now by default

Eg. we are using two classes from our two Apache Commons dependencies

Alpha 1 starts just fine with no configuration changes. Unpacking the zip for Alpha2, and launching burst.cmd with no config changes yield this.

Is pointing to PoCC's account...

• The change view from 24 hour option doesnt toggle the view under firefox, chrome, etc, nor under qbundle. It also has a graphical black glitch in the drop down. PoC-Consortium/Qbundle#67

• Assets never load under Qbundle. It appears to be the wallet doesnt like the chromium pocket browser. PoC-Consortium/Qbundle#66

This would come in the form of the II service analyzing a transaction on the fly using an isIndirectRecipient method or similar.

Currently, there is a bug in QBundle where setting Reward Recipient fails when the call is made against a remote node.

Users are shown a success message, which makes this bug even more dubious. We should fix this as it prevents users from mining, and is a very bad user experience.

Looks like it happens only on subsequent attempts. so maybe its the finger print stuff removing duplicates. been going over the changes since 2.2.4. main differences is the peer stuff and the message encryption

At the moment all nodes listed as bootstrap must be using standard port (8123).

We also need to check the bootstrap list and add/remove as necessary.

We should have a V2 gRPC API for clients to use (NOT for P2P). This will not only give us an opportunity to improve the API but also will make it much more efficient.

Currently the port number is hardcoded when running in testnet mode. This should be customizable via a property. For now we should only change the API port as we do not want to break testnet P2P (needs more research).

• Add the property DEV.API.Port to conf/brs-default.properties with a value of 6876 (please update the comment saying that API port is hardcoded)

• Add a new Prop<Integer> to src/brs/props/Props.java (preferably under the testnet prop) called DEV_API_PORT with a default value of 6876

• In src/brs/http/API.java, remove the static variable TESTNET_API_PORT and replace the usage of the variable in both API.java and BurstGUI.java with a call to propertyService.getInt()

Atm we can only request for AT-IDs in general via http://at-testnet.burst-alliance.org:6876/burst?requestType=getATIds

If we will have in the near future more ATs on the chain, we should be able to give filter criteria within a new call to get a pre-filtered AT-ID list.

The maximum details for an ATS are the following:

{
"creator": "5219831338759933722",
"creatorRS": "BURST-TMSU-YBH5-RVC7-6J6WJ",
"at": "15869142951140617004",
"atRS": "BURST-4UTE-FY8C-PSUE-F7NGS",
"atVersion": 2,
"name": "OddsGame1557668323155",
"description": "OddsGame1557668323155",
"machineCode": "300000035000000020b00000005000000100b000000110600000033160107000000330204060000001a7c0200",
"machineData": "",
"balanceNQT": "589548670000",
"prevBalanceNQT": "589548670000",
"nextBlock": 76258,
"frozen": true,
"running": false,
"stopped": false,
"finished": true,
"dead": false,
"minActivation": "1000000000",
"creationBlock": 57588,
"requestProcessingTime": 2
}

For a start it would be nice to be able to filter on the following attributes :

• creatorRS,
• atVersion
• Name
• machineCode,
• creationBlock

Request : Please introduce a new call in BRS which allows to request for a filtered list of ATs.

OpenPoint
Do we need new indexe on the DB for that ?

org.h2.jdbc.JdbcSQLException: A file path that is implicitly relative to the current working directory is not allowed in the database URL "jdbc:h2:file:/db/burst;DB_CLOSE_ON_EXIT=FALSE". Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-196]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
	at org.h2.message.DbException.get(DbException.java:179)
	at org.h2.message.DbException.get(DbException.java:155)
	at org.h2.engine.ConnectionInfo.getName(ConnectionInfo.java:400)
	at org.h2.engine.Engine.openSession(Engine.java:49)
	at org.h2.engine.Engine.openSession(Engine.java:176)
	at org.h2.engine.Engine.createSessionAndValidate(Engine.java:154)
	at org.h2.engine.Engine.createSession(Engine.java:137)
	at org.h2.engine.Engine.createSession(Engine.java:27)
	at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:354)
	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:116)
	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:100)
	at org.h2.Driver.connect(Driver.java:69)
	at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:117)
	at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:123)
	at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:365)
	at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:194)
	at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:460)
	at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:534)
	... 6 more

Fix: Change database URL from jdbc:h2:file:/db/burst;DB_CLOSE_ON_EXIT=FALSE to jdbc:h2:file:./db/burst;DB_CLOSE_ON_EXIT=FALSE

We should be careful if we implement this - the node must only update itself to versions we are sure are stable

If create possibility add message on generating request Burst QR, it will be easier integrate in shops and etc.

How I see it:

1. User has items in Cart.
2. He'd like pay by BurstCoin.
3. Shop generate for him QR(all data immutable) with message contained number of his order.
4. User scan or copy it in wallet and pay. Transaction contain number of order. I think better if message will encrypted. Also can create option when you create request message will be encrypted or not.
5. Shop periodically checks new transactions in shop wallet.
6. When shop see new transaction, he see message which order paid. It easier implement with not encrypted message, because doesn't needed know passphrase for decrypting message and do it.
7. Also can add expiration of request Burst. Wallet(e.g. phoenix) will see this data on scan and decline request.

We should make sure that older transactions are favored and that slots are used as efficiently as possible. There should be a new priority system: priority = fee * age where age is time since transaction creation in seconds. This will allow older transactions within the same slot but with a lower fee to take precedence to ensure that someone can not add 1 planck extra to their fee to be bumped to top priority for that slot.

If BRS gets stuck, it should reset cache & pop off a certain number of blocks.

This should be configurable.

Turns out quite a lot of people use a redundant endpoint ¯\_(ツ)_/¯

Perform a database lookup WHERE name IS + query parameter

Returns a list of accounts

Possibly should have corresponding API call where only Account IDs are returned to save bandwidth

The only way I can the see the latest details of a crowd funding project, after a pledge is received or status change is made, is to log out and back in again. I guess this empties some form of cache and the latest details are retrieved from the back end.

I guess i found 2 problems / proposals in the burst wallet, concerning the subscription fee's.

If you create a subscription, in my opinion there should be the same "suggested fee" button/line like if you do a normal transaction with "send burst"

If you create a subscription (with low fee, in my case 0.01 burst) it's working, but all subscription after creating it will have a fee of 1 burst. Is it possible to do this also with low fees, or will it open an attack surface?
If it should be no problem to let the subscriptions work with low fee, i suggest two fee options, one for the "creating subscription transaction" and one for the "subscriptions itself".

Bit sadly i did my test on the mainnet, since we got a brand new testnet now! ;) ty for this

I did my test with the burst id's:
BURST-N3AP-DXZN-YMFP-AFACQ and BURST-HZ3D-4S5X-2ALC-95TR2

The two main culprits are TransactionType.java and Attachment.java - These two are also heavily interlinked, maybe they could be combined?

When running under Turkish locale, the character I gets converted to a dotless i by toLowerCase() during string validation.

[SEVERE] 2019-01-28 20:27:30 brs.peer.PeerImpl - Reason for following blacklist: Invalid alias name: ıhsahn transaction: {"senderPublicKey":"3080bfa0394333f2d1da9763fde787fabfe1d0dccd6f5f97590f4f6705e34e58","attachment":{"alias":"Ihsahn","version.AliasAssignment":1,"uri":"acct:burst-gzq9-uc9p-xdbc-fjhml@burst"},"subtype":1,"amountNQT":0,"signature":"c890db731e05dada4a37f3c3b04bdb38f92868aa6fb480254938a6f46ee3f30f309f3125b6922bf1bcdd5d3a005db7bf75e4d357a087b91b619cf3b76502a23c","feeNQT":2940000,"ecBlockHeight":556686,"type":1,"deadline":1440,"version":1,"timestamp":134653846,"ecBlockId":"12065661956024813127"}
brs.BlockchainProcessor$TransactionNotAcceptedException: Invalid alias name: ıhsahn transaction: {"senderPublicKey":"3080bfa0394333f2d1da9763fde787fabfe1d0dccd6f5f97590f4f6705e34e58","attachment":{"alias":"Ihsahn","version.AliasAssignment":1,"uri":"acct:burst-gzq9-uc9p-xdbc-fjhml@burst"},"subtype":1,"amountNQT":0,"signature":"c890db731e05dada4a37f3c3b04bdb38f92868aa6fb480254938a6f46ee3f30f309f3125b6922bf1bcdd5d3a005db7bf75e4d357a087b91b619cf3b76502a23c","feeNQT":2940000,"ecBlockHeight":556686,"type":1,"deadline":1440,"version":1,"timestamp":134653846,"ecBlockId":"12065661956024813127"}
    at brs.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:973)
    at brs.BlockchainProcessorImpl.lambda$new$8(BlockchainProcessorImpl.java:293)
    at brs.util.ThreadPool.lambda$start$0(ThreadPool.java:99)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
[INFO] 2019-01-28 20:27:30 brs.peer.PeerImpl - Blacklisting 107.150.6.121 (2.2.7) because of: found invalid pull/push data during importing the block

PoC-Consortium#431

One of the two solutions suggested by @CurbShifter should be implemented, or another solution proposed.

BRS currently uses Google's json-simple library, which was build for Java 2, which is why it is the cause of most of the compiler warnings (Java 1.2 did not have generics so lots of unchecked warnings)

This is pretty obsolete and should be replaced with Gson, but this will take a while.

From @zodi via Discord: Has something changed with the "getGuaranteedBalance" API call since 2.2.7?

Cause this works on a 2.2.7 wallet:
https://wallet.burst.cryptoguru.org:8125/burst?requestType=getGuaranteedBalance&account=BURST-GBFG-HVQ4-8AMM-GPCWR

and fails on 2.3.0:
https://swissburstcoin.internet-box.ch:8125/burst?requestType=getGuaranteedBalance&account=BURST-GBFG-HVQ4-8AMM-GPCWR

Maybe make part of CI?

When solo mining you don't see your forget blocks at Dashboard, Recent Transactions. You only can see it at the Blocks section. I think it was better user experience to put info about forget block at Dashboard to Recent Transaction. Sure it is not important issue, because solo mining not popular.

Using v2.4.0-beta2 web wallet http://testnet.getburst.net:6876 chrome browser
When sending to more then two recipients got error "Could not verify signature (server side)", works if only two recipients.

Readme needs a makeover

A lot of very commonly used functions in Convert and Crypto could be optimised, this will improve sync speed.

This will make testing easier for non-developers

I can amend the quantity once. But the SECOND time nothing happens.
No update is applied when submitted by the Wallet UI or API directly
No error is returned when the request is sent.

However, the quantity available to be sold is updated correctly when purchases are made.

As a user, I want to view my Multi-Out payments (incoming/outgoing) using the Desktop Wallet.