phoreproject / phore Goto Github PK

Describe the issue

Qt issue on Windows phore-qt
This issue doesn't happen on MacOS/Linux

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

0. Start Windows
1. Open Masternode tab or Proposal tab
2. See the line of top of column

Expected behavior

should like this pic.

Actual behavior

bit smaller than strings.

What version of Phore Core are you using?

v1.4.2

Machine specs:

• OS: Only Windows

bitcoin#11991

Describe the issue

Port detection of masternode.conf denies port 11771 for mainnet.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Use default line of masternode.conf for masternode configuration.

mn1 127.0.0.2:11771 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 2bcd3c84c84f87eaa86e4e56834c92927a07f9e18718810b92e0d0324456a67c 0

2. Start phore-qt-1.3.0.exe
3. Popup
   

Expected behavior

Port detection should pass this line of masternode configuration

Actual behavior

Port detection of masternode.conf denied port 11771 for mainnet

Screenshots.

What version of Phore Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package.
Official pre-released binary, v1.3.0 for Windows x64
https://github.com/phoreproject/Phore/releases/download/v1.3.0/phore-1.3.0-win64.zip

Machine specs:

• OS: Windows8.1 x64
• CPU: i5-4570
• RAM: 12GB
• Disk size: 256GB
• Disk Type (HD/SDD): SSD

Mac installer shows old outdated Phore logo in the installer package.

Reproduced on regtest network, steps,

1. Call RPC "getnewaddress" to get a new address.
2. Send some coins to that new address.
3. Be sure no new block is mined.
4. Call RPC "getblocktemplate", the field "transactions" is an empty array. It should contain the latest transaction.

Note: getblocktemplate requires there are peers to work, that causes test more difficult.I've changed it doesn't check peers on regtest network on my forked repo,
wqking-misc@8c89cdf

This bug causes difficulties on SegWit integration test.

This bug is reproducible in both the command line and the integration test (test/segwit.py on my repo).

Just so you guys are aware. This is a error am getting

2018-07-29 07:50:36 socket recv error An existing connection was forcibly closed by the remote host. (10054) 2018-07-29 07:50:43 socket recv error An existing connection was forcibly closed by the remote host. (10054)

It seems to only occur between 1.2.2 and the newest wallet. But this could cause issue.

No response when I put in make airdrop file
Is it normal?
How do I solve that

Machine specs:

• OS: windows 10 pro
• CPU: 1.8
• RAM:4
• Disk size:320
• Disk Type (HD/SDD):

I have 1 million tPHR on Testnet in one legacy address. I sent 0.001 tPHR to a bech32 address and it succeeded.
Then I tried to send 50K tPHR to the same bech32 address, the wallet reports error of "The amount exceeds your balance".
After some time and after I restarted the wallet, when I tried to send 500K tPHR, no any error.

The version in the about dialog currently says v3.0.6 from PIVX, but it should say v1.2.2 from Phore.

Network is regtest. The binary is I compiled from SegWit branch.
I send some coins to witness address, after mining a new block, the new block doesn't contain that transaction.

Reproduce:

SegWit: coins sent to witness address doesn't appear any more and not mined

Network is regtest.
I send some coins to witness address, after mining a new block, the new block doesn't contain that transaction.

Reproduce:

1. Run the daemon
   phored -regtest

2. Run the RPCs, comment is in //

// set the mock time to enable SegWit
phore-cli -regtest setmocktime 4071908800

// get a new normal address
phore-cli -regtest getnewaddress
yHrW14YkawSTPBGY5hKuTS11VMMrkabCAF

// generate a new witness address
phore-cli -regtest addwitnessaddress yHrW14YkawSTPBGY5hKuTS11VMMrkabCAF
8uBqkmxYhhLWjf1KvLd5dDKBMQDkFTUXds

// mine 150 blocks.
phore-cli -regtest setgenerate true 150

// send some amount to witness address
phore-cli -regtest sendtoaddress 8uBqkmxYhhLWjf1KvLd5dDKBMQDkFTUXds 17870000
b36267fae4a46f353336cd68db4a9e568ea77f6ecfbedc59967d4ea0d8d75757

// mine a new block
phore-cli -regtest setgenerate true 1
2b7ed3b4efdd6b06fb3eb545c3f5b786953a153c8de2967d21028c94e1e69bd2

// check the new mined block. It only contains one transaction which is the coinbase. It should contain two transactions and one transaction is the one sent above.
phore-cli -regtest getblock 2b7ed3b4efdd6b06fb3eb545c3f5b786953a153c8de2967d21028c94e1e69bd2

Note, seems this issue is not specified to SegWit. Sending to a normal address still have this issues.
Note, I tested on Bitcoin regtest, it shows two transactions in the last "getblock" step, which is correct.

Merge this commit from the Bitcoin upstream.

petertodd@ab0f54f

Describe the issue

Signing the final budget proposal fails if multiple inputs are used. Multiple inputs should be able to be used as collateral for the finalized budget proposal.

Expected behavior

The finalized budget proposal should be able to sign multiple inputs.

Actual behavior

The finalized budget proposal is not able to sign multiple inputs.

Screenshots.

https://cdn.discordapp.com/attachments/434484437322039308/434695482187448321/Screen_Shot_2018-04-14_at_5.41.36_AM.png

What version of Phore Core are you using?

v1.2.1

Machine specs:

• OS: Linux/Mac

Describe the issue

After running ./autogen.sh and ./configure I encounter a source build issue when executing the make command.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Run ./autogen.sh
2. Run LDFLAGS='-L/usr/local/opt/openssl/lib' CPPFLAGS='-I/usr/local/opt/openssl/include' PKG_CONFIG_PATH='/usr/local/opt/openssl/lib/pkgconfig' ./configure --with-gui=qt5
3. Run make

Expected behavior

It should build phored source.

Actual behavior

It fails with an error Undefined symbols for architecture x86_64.

What version of Phore Core are you using?

v1.3.2

Machine specs:

• OS: macOS High Sierra
• CPU: 2.2 GHz i7
• RAM: 8 GB
• Disk size: 300+ GB
• Disk Type (HD/SDD): SDD

Any extra information that might be useful in the debugging process.

Making all in src
  CXXLD    phored
Undefined symbols for architecture x86_64:
  "boost::gregorian::greg_month::as_short_string() const", referenced from:
      boost::date_time::month_formatter<boost::gregorian::greg_month, boost::date_time::iso_extended_format<char>, char>::format_month(boost::gregorian::greg_month const&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in libbitcoin_wallet.a(libbitcoin_wallet_a-wallet.o)
  "boost::gregorian::greg_month::as_long_string() const", referenced from:
      boost::date_time::month_formatter<boost::gregorian::greg_month, boost::date_time::iso_extended_format<char>, char>::format_month(boost::gregorian::greg_month const&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in libbitcoin_wallet.a(libbitcoin_wallet_a-wallet.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [phored] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Mac 1.3.0 wallet crashes on High Sierra shortly after starting. The log entries show it happens shortly after starting to load the block index. Last lines in a couple of runs:

Run 1

2018-06-26 16:51:01 Bound to [::]:11771
2018-06-26 16:51:01 Bound to 0.0.0.0:11771
2018-06-26 16:51:01 init message: Loading block index...
2018-06-26 16:51:01 Opening LevelDB in /Users/tohsnoom/Library/Application Support/Phore/zerocoin
2018-06-26 16:51:01 Opened LevelDB successfully
2018-06-26 16:51:01 Opening LevelDB in /Users/tohsnoom/Library/Application Support/Phore/sporks
2018-06-26 16:51:25

Run 2

2018-06-26 16:51:25 init message: Loading sporks...
2018-06-26 16:51:25 LoadSporksFromDB : no previous value for SPORK_2_SWIFTTX found in database
2018-06-26 16:51:25 LoadSporksFromDB : no previous value for SPORK_3_SWIFTTX_BLOCK_FILTERING found in database
2018-06-26 16:51:25 LoadSporksFromDB : no previous value for SPORK_5_MAX_VALUE found in database
2018-06-26 16:51:25 LoadSporksFromDB : no previous value for SPORK_7_MASTERNODE_SCANNING found in database
2018-06-26 16:51:25 LoadSporksFromDB : loaded spork SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT with value 1511395200 : Wed Nov 22 18:00:00 2017
2018-06-26 16:51:25 LoadSporksFromDB : loaded spork SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT with value 1511481600 : Thu Nov 23 18:00:00 2017
2018-06-26 16:51:25 LoadSporksFromDB : no previous value for SPORK_10_MASTERNODE_PAY_UPDATED_NODES found in database
2018-06-26 16:51:25 LoadSporksFromDB : loaded spork SPORK_13_ENABLE_SUPERBLOCKS with value 1511499600 : Thu Nov 23 23:00:00 2017
2018-06-26 16:51:25 LoadSporksFromDB : loaded spork SPORK_16_ZEROCOIN_MAINTENANCE_MODE with value 1522414300 : Fri Mar 30 07:51:40 2018
2018-06-26 16:51:25 LoadSporksFromDB : no previous value for SPORK_17_SEGWIT_ACTIVATION found in database
2018-06-26 16:51:25 init message: Loading block index...

==========

As a first step and potential workaround I am going to build a High Sierra native build to see if it is still related to Gitian building not being compatible with High Sierra.

Describe the issue

QR codes do appear in the Linux build and presumably the Windows build as well on the Receive tab when you request a new address or double click on an existing one. When you open the same dialog on Mac High Sierra, the QR code does not appear.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

This seems to consistently happen when you open the receive address dialog by either requesting a new address or by double clicking on an existing receive address in the Mac Qt wallet.

What version of Phore Core are you using?

v1.3.1, official binary

Describe the issue

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. generate bech32 address using getnewaddress "" bech32
2. try to paste into wallet send GUI

Expected behavior

Should paste

Actual behavior

Doesn't paste

Titles under wallet tab icons are slightly cut off. See screenshot.

This issue tracker is only for technical issues related to Phore Core.
General Phore questions and/or support requests and are best directed to the Phore Discord.

Describe the issue

Using REINDEX function, wallet will be closed but it won't reopen unless I will manually delete blockchain folders. I had the same issue on previous wallet release, both on W64 and OSX

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Wallet Repair
2. Rebuild Index

Expected behavior

Tell us what should happen
Wallet closes to rebuild index and reopens

Actual behavior

Tell us what happens instead
Wallet does not reopen

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of Phore Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package.
1.4.4.3

Machine specs:

• OS: Windows10
• CPU: Intel Core2 Duo E8400 3.00GHZ
• RAM: 2GB
• Disk size: 200gb
• Disk Type (HD/SDD): HD

Any extra information that might be useful in the debugging process.

This is normally the contents of a debug.log, db.log or config.log file. Raw text or a link to a pastebin type site are preferred.

Update Phore wallet with new Phore logos.

bitcoin#8499

This issue tracker is only for technical issues related to Phore Core.
General Phore questions and/or support requests and are best directed to the Phore Discord.

Describe the issue

Impossible to start the daemon through phored -daemon or ./phored -daemon

Bash report that the file doesn't exist, even if it does.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

Expected behavior

Tell us what should happen

The daemon should start.

Actual behavior

Tell us what happens instead

The system can't start (see) it.

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of Phore Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package.

1.2.2

Machine specs:

• OS: Ubuntu 16.04 on a Vultre server. All updated and fresh.
• CPU:
• RAM:
• Disk size:
• Disk Type (HD/SDD):

Any extra information that might be useful in the debugging process.

This is normally the contents of a debug.log, db.log or config.log file. Raw text or a link to a pastebin type site are preferred.

1. On Open - Phore Wallet seems to be set to Full Screen and the MacOS Application Dock blocks the bottom of the Wallet (see screenshot)

Double-clicking the window bar shrinks the window by "maximizing"

2. Browsing the Masternodes tab - Phore Wallet sets itself back to Full Screen and bottom of the wallet is again blocked by the dock.

Double-clicking the window bar shrinks the window briefly by "maximizing", but it then immediately reverts to Full Screen within seconds.

This issue tracker is only for technical issues related to Phore Core.
General Phore questions and/or support requests and are best directed to the Phore Discord.

Describe the issue

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

All is running fine, only the build from the leveldb I receive this error.

Actual behavior

make[1]: Entering directory '/home/s/src/src'
make[2]: Entering directory '/home/s/src/src'
Building LevelDB ...
make[3]: Entering directory '/home/s/src/src/leveldb'
make[3]: *** No rule to make target 'libmemenv.a'. Stop.
make[3]: Leaving directory '/home/s/src/src/leveldb'
Makefile:8630: recipe for target 'leveldb/libmemenv.a' failed
make[2]: *** [leveldb/libmemenv.a] Error 2
make[2]: Leaving directory '/home/s/src/src'
Makefile:8140: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/s/src/src'
Makefile:681: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of Phore Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package.
1.60

Machine specs:

• OS: Ubuntu 18.04
• CPU: 4 core
• RAM: 8gb
• Disk size: 80gb
• Disk Type (HD/SDD): ssd

Any extra information that might be useful in the debugging process.

chmod 755 src/leveldb/build_detect_plattform I did

https://github.com/phoreproject/Phore/pull/140/files

So this PR well it breaks compiling, It compiled the first time, but once I pulled new code in It gives the same error you can see in the travis compile.

Merge in PIVX-Project#576

nZerocoinStartTime is a bad way of activating Zerocoin, especially since it's already been activated. This should be replaced with nZerocoinStartHeight.

Running the following command in the console of the TEST release of v.1.7.1 (v1.7.1-rc4) results in an error and no file is created as expected:

makeairdropfile "my_bsc_address_here" 1 "airdrop.txt"

The error returned is:

regex_error (code -1)

A screenshot is attached.

This is happening with the GUI and the CLI wallets (CLI error: error: {"code":-1,"message":"regex_error"})

I am using a newly downloaded copy of the TEST release of v1.7.1 of the Phore Core wallet (v1.7.1-rc4, expanded from phore-1.7.1-win64.zip).

bitcoin#11403

Waiting on #27

Describe the issue

Command "dumpprivkey" doesn't work for legacy address.

Can you reliably reproduce the issue?

Yes.

If so, please list the steps to reproduce below:

1. getnewaddress
2. dumpprivkey GENERATED_ADDRESS
3. Get an error "Address does not refer to a key (code -3)

Expected behavior

"dumpprivkey" should return private key of input address

Actual behavior

"Address does not refer to a key (code -3)" error was returned

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of Phore Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package.
v1.3.0-rc2(phore-1.3.0-osx-unsigned.dmg)
v1.3.0-rc2(phore-1.3.0-win64.zip)

Machine specs:

• OS: Windows8.1/OSX(10.13.4)
• CPU: i5/i5
• RAM:12GB/8GB
• Disk size: 256GB/256GB
• Disk Type (HD/SDD): SSD

Any extra information that might be useful in the debugging process.

This is normally the contents of a debug.log, db.log or config.log file. Raw text or a link to a pastebin type site are preferred.

When getinfo is run in the debug console of the Mac High Sierra build for v1.3.1 and v1.3.2, it displays:

"zPHRsupply": {
"1": 0.00000000,
"5": 0.00000000,
"10": 0.00000000,
"50": 0.00000000,
"100": 0.00000000,
"500": 0.00000000,
"1000": 0.00000000,
"5000": 0.00000000,
"total": 0.00000000
},

I expect this is a display bug and has to do with the changes we are making to how accumulators work.

This does NOT seem to be happening on the linux command line--a masternode using v1.3.2 shows this:

"zPHRsupply": {
"1": 386.00000000,
"5": 240.00000000,
"10": 680.00000000,
"50": 550.00000000,
"100": 1100.00000000,
"500": 2500.00000000,
"1000": 5000.00000000,
"5000": 10000.00000000,
"total": 20456.00000000
},

That looks likely to be the correct global zPHR supply display.

Stripping out the previous repo to Phore-old and leaves the current issues and contribution history in the Phore-old repo and not in the new Phore repo.

Phore-old should have been rebased (with removing the initial commit) from the original fork point (some time in September or so) if we wanted to properly show the original fork from PIVX. Then we could have merged the more recent changes we wanted after completing the rebase. IMO, it would be worthwhile to go ahead and do this even though it might be a pain. It would also give us a chance to squash commit history and apply a better style to commit messages.

Actual behavior

Staking active but I am not getting rewards anymore after sending more phr to my main staking address.
I did not get phr during: 2 * the normal reward time
I restarted my server and phore wallet, I am waiting for the next rewards to see if it fixed the issue.

What version of Phore Wallet are you using?

Lasted version of Phore Wallet

Machine specs:

• OS: Ubuntu Xenial
• Disk size: 50 G
• Disk Type (HD/SDD): SSD

On testnet, the protocol enforcements sporks do not show up in the list of sporks.

spork show
{
"SPORK_2_SWIFTTX": 978307200,
"SPORK_3_SWIFTTX_BLOCK_FILTERING": 1424217600,
"SPORK_5_MAX_VALUE": 1000,
"SPORK_7_MASTERNODE_SCANNING": 978307200,
"SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT": 1511395200,
"SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT": 1511481600,
"SPORK_10_MASTERNODE_PAY_UPDATED_NODES": 4070908800,
"SPORK_13_ENABLE_SUPERBLOCKS": 1511481600,
"SPORK_16_ZEROCOIN_MAINTENANCE_MODE": 4070908800,
"SPORK_17_SEGWIT_ACTIVATION": 1540158562
}

spork active
{
"SPORK_2_SWIFTTX": true,
"SPORK_3_SWIFTTX_BLOCK_FILTERING": true,
"SPORK_5_MAX_VALUE": true,
"SPORK_7_MASTERNODE_SCANNING": true,
"SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT": true,
"SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT": true,
"SPORK_10_MASTERNODE_PAY_UPDATED_NODES": false,
"SPORK_13_ENABLE_SUPERBLOCKS": true,
"SPORK_16_ZEROCOIN_MAINTENANCE_MODE": false,
"SPORK_17_SEGWIT_ACTIVATION": true
}

The testnet code includes changes to that spork going from the primary one, SPORK_14_NEW_PROTOCOL_ENFORCEMENT, to the alternate one, SPORK_15_NEW_PROTOCOL_ENFORCEMENT_2. I've tried switching it back to use SPORK_14 and still neither one displays.

After adding some logging code, it appears when sporks are loaded from the database, the IDs for sporks 14 and 15 (10013 and 10014) are not able to look up the corresponding name:

2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_2_SWIFTTX with value 978307200 : Sun Dec 31 18:00:00 2000
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_3_SWIFTTX_BLOCK_FILTERING with value 1424217600 : Tue Feb 17 18:00:00 2015
2018-10-21 22:31:14 LoadSporksFromDB : unknown spork ID 10003
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_5_MAX_VALUE with value 1000
2018-10-21 22:31:14 LoadSporksFromDB : unknown spork ID 10005
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_7_MASTERNODE_SCANNING with value 978307200 : Sun Dec 31 18:00:00 2000
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT with value 1511395200 : Wed Nov 22 18:00:00 2017
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_9_MASTERNODE_BUDGET_ENFORCEMENT with value 1511481600 : Thu Nov 23 18:00:00 2017
2018-10-21 22:31:14 LoadSporksFromDB : no previous value for SPORK_10_MASTERNODE_PAY_UPDATED_NODES found in database
2018-10-21 22:31:14 LoadSporksFromDB : unknown spork ID 10010
2018-10-21 22:31:14 LoadSporksFromDB : unknown spork ID 10011
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_13_ENABLE_SUPERBLOCKS with value 1511481600 : Thu Nov 23 18:00:00 2017
2018-10-21 22:31:14 LoadSporksFromDB : unknown spork ID 10013
2018-10-21 22:31:14 LoadSporksFromDB : unknown spork ID 10014
2018-10-21 22:31:14 LoadSporksFromDB : no previous value for SPORK_16_ZEROCOIN_MAINTENANCE_MODE found in database
2018-10-21 22:31:14 LoadSporksFromDB : loaded spork SPORK_17_SEGWIT_ACTIVATION with value 1540158562 : Sun Oct 21 16:49:22 2018

I add a temp.py to the test folder in my repo. To use it, you don't need to merge from my repo, just copy the file to your local repo. It's used temporarily to reproduce problems, not formal test.

temp.py

Note this test doesn't assert anything, it prints some information.

Problem: node0 sends some coins to node1, after the transaction is confirmed, node1 getbalance doesn't change.
With this problem we can't know if sending to segwit address will success or not. We need to ensure sending to non-segwit address working.

We need to either fix this bug if it's a problem in the core code or make the test work if the test code is wrong.

As per Michael:

1.) More detailed instructions are required beyond "connecting to metamask" so it can be accessible to most.

2.) The browse for files button overlaps the bottom of the file upload box, at least on Brave-MacOS High Sierra
https://imgur.com/a/kx7Jsho

3.) Spinner too big for the box it is in
https://imgur.com/a/cysppm1

4.) Amounts decimals to clarify token number

5.) Change from success to "valid for redemption"
https://imgur.com/a/shjVvgt

The test cast test_send_raw_transaction in temp.py doesn't work because sendrawtransaction returns -25 verify error.

The same can be reproduced on command line.
We need to check if it's a problem in the core code or there is wrong in the test steps.

Command line steps:

// Start two nodes
phored -regtest -datadir=Folder0
phored -regtest -datadir=Folder1

// Node0 mine 101 blocks
phore-cli -regtest -datadir=Folder0 setgenerate true 101

// Get a node0 unspent txid
phore-cli -regtest -datadir=Folder0 listunspent
// Now we get a txid f8170a80a479d2d91dd08d93886018c21feef3143d00b5bcb5b2f8d26408722e

// Get a new address on node1
phore-cli -regtest -datadir=Folder1 getnewaddress

// Create raw transaction on node0
phore-cli -regtest -datadir=Folder0 createrawtransaction '[{ "txid": "f8170a80a479d2d91dd08d93886018c21feef3143d00b5bcb5b2f8d26408722e","vout" : 0 }]' '{"8idfiRJ9FTyV6esqT4AQfDFUv5L3wRPLnA": 100 }'
// Now we get transaction 01000000012e720864d2f8b2b5bcb5003d14f3ee1fc2186088938dd01dd9d279a4800a17f80000000000ffffffff0100e40b540200000017a9142e2f845306f129b4772355439020f5aa0afaaff08700000000

// Sign the transaction on node0
phore-cli -regtest -datadir=Folder0 signrawtransaction 01000000012e720864d2f8b2b5bcb5003d14f3ee1fc2186088938dd01dd9d279a4800a17f80000000000ffffffff0100e40b540200000017a9142e2f845306f129b4772355439020f5aa0afaaff08700000000
// We got
{
  "hex": "01000000012e720864d2f8b2b5bcb5003d14f3ee1fc2186088938dd01dd9d279a4800a17f8000000004847304402200897657e4c8ad860291e20f65dfe95b52b21be0667d69ec546d89ca2968cc2b802204bdb203a4734757ba6ea15bd0236fd9d7635d1da7b5d49efa0711e89915d97f701ffffffff0100e40b540200000017a9142e2f845306f129b4772355439020f5aa0afaaff08700000000",
  "complete": true
}

// Send the transaction
phore-cli -regtest -datadir=Folder0 sendrawtransaction 01000000012e720864d2f8b2b5bcb5003d14f3ee1fc2186088938dd01dd9d279a4800a17f8000000004847304402200897657e4c8ad860291e20f65dfe95b52b21be0667d69ec546d89ca2968cc2b802204bdb203a4734757ba6ea15bd0236fd9d7635d1da7b5d49efa0711e89915d97f701ffffffff0100e40b540200000017a9142e2f845306f129b4772355439020f5aa0afaaff08700000000

// Got error: error: {"code":-25,"message":""}

bitcoin#7524

Merge from upstream

On testnet with SegWit activated, sending to a bech32 address from phored caused an assertion error.

bash command: phore-cli sendtoaddress tp1qwsmxln4glureju35drulnjrrfduyvu6t6z4nx6 1000000

phored: ./primitives/transaction.h:348: void SerializeTransaction(TxType&, Stream&, Operation, int, int) [with Stream = CHashWriter; Operation = CSerActionSerialize; TxType = CTransaction]: Assertion `tx.wit.vtxinwit.size() <= tx.vin.size()' failed.

Previous to this, I successfully sent to a bech32 address within that same wallet, so it does not appear to be universal to bech32 address transactions.

The one that failed has this in the log until it crashed:
2018-10-21 21:53:38 CWallet::SelectCoinsMinConf best subset: 46881.88 46881.75 46880.83 46879.52 46879.13 46878.08 46877.6899408 46877.5599408 46875.4698816 46874.9398816 46874.5498224 46874.2898224 46874.0297632 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 12505.24 2503.49 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 0.0162573 - total 1000000.0148109
2018-10-21 21:53:38 keypool added key 2286, size=1001
2018-10-21 21:53:38 init message: Loading wallet... (228.37 %)
2018-10-21 21:53:38 keypool reserve 1286
2018-10-21 21:53:38 CWallet::SelectCoinsMinConf best subset: 46881.35 46880.44 46879.52 46879.13 46878.74 46875.7299408 46874.9398816 46874.2898224 46874.0297632 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 24999.3099408 2503.49 501.0499408 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 7.00 7.00 0.0162573 - total 1000000.0147469
2018-10-21 22:09:53

The log stops there until the node is restarted, following the assertion error above.

The earlier, successful transaction to a bech32 address shows this:

2018-10-21 21:52:47 CWallet::SelectCoinsMinConf best subset: 46880.18 46879.78 46879.13 46878.74 46878.61 46878.08 46877.4299408 46876.6399408 46876.1199408 46874.5498224 46874.4198224 46874.2898224 46874.1598224 46873.769704 46873.6396448 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 25003.49 12505.24 6256.11 2503.49 501.0499408 9.7999584 9.7999584 9.7999584 9.7999584 7.00 - total 1000000.0182352
2018-10-21 21:52:47 keypool added key 2284, size=1001
2018-10-21 21:52:47 init message: Loading wallet... (228.17 %)
2018-10-21 21:52:47 keypool reserve 1284
2018-10-21 21:52:47 CWallet::SelectCoinsMinConf best subset: 46880.57 46880.18 46879.91 46879.13 46878.61 46878.08 46877.5599408 46877.4299408 46877.0399408 46876.6399408 46876.3799408 46875.9899408 46875.7299408 46875.4698816 46875.3398816 46874.5498224 46874.4198224 46874.2898224 46874.1598224 46873.769704 46873.6396448 12505.24 2503.49 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 - total 1000000.01728
2018-10-21 21:52:47 CWallet::SelectCoinsMinConf best subset: 50000.00 46881.88 46881.75 46880.83 46880.57 46879.91 46878.61 46878.48 46877.82 46877.6899408 46877.5599408 46877.1699408 46876.7799408 46876.6399408 46876.3799408 46875.7299408 46875.4698816 46874.0297632 46873.8997632 46873.6396448 25003.49 25003.49 6256.11 2503.49 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 7.00 5.5999584 5.5999584 5.5999584 5.5999584 5.5999584 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 2.80 - total 1000000.018056
2018-10-21 21:52:48 CWallet::SelectCoinsMinConf best subset: 46880.57 46880.31 46879.91 46879.78 46878.61 46877.82 46877.4299408 46877.1699408 46876.7799408 46876.6399408 46876.5099408 46876.3799408 46876.1199408 46875.3398816 46874.4198224 46874.1598224 46873.8997632 46873.769704 46873.6396448 25003.49 25003.49 25003.49 25003.49 6255.07 2503.49 505.24 9.7999584 9.7999584 9.7999584 9.7999584 9.7999584 7.00 7.00 - total 1000000.018016
2018-10-21 21:52:48 CommitTransaction:
CTransaction(hash=e9e28d125f, ver=1, vin.size=33, vout.size=2, nLockTime=0)
CTxIn(COutPoint(d96b9b2c7cb0e5f99016a50c996747203af44ac123c74786d6a4495bd9ac32f0, 1), scriptSig=30440220724dc071b867c78a)
CTxIn(COutPoint(0a13e603159d90bea52811492aa651df7a003d7e744ef1e270ed36eed92af9b0, 1), scriptSig=304402207faa33c7d757821b)
CTxIn(COutPoint(326323edb831a448664c1a6e19ccbfd8edc100ce3f0b9c2a1ea5a7d68d994292, 1), scriptSig=304402200100e1be747da9ab)
CTxIn(COutPoint(d3158b5c70420f372abe0c9d241014e3af1dacd2166d669db6ce1f3a234aa113, 1), scriptSig=3045022100dbe51acc3ca289)
CTxIn(COutPoint(8a2950fe22ba39f9f3da243c2e4744ac670b0d6a28ae898554f62f1ce756fc49, 1), scriptSig=30450221008ebefd06a83727)
CTxIn(COutPoint(c3a8ca9d3c7d8ffef173d346c4da2236e11894e3008be0d1906630e113800f1c, 1), scriptSig=304402206005992e082fcaeb)
CTxIn(COutPoint(2d919be4f2e8cfcd46aad8b269c45d58bc7570299b3246f87953974971854059, 1), scriptSig=30440220750ea40cc1d352ff)
CTxIn(COutPoint(51733c7e25b3fcc689858df8fa937158dd487c0ef4c208cad67294bbada03df6, 1), scriptSig=3045022100cd29e8a0d6956d)
CTxIn(COutPoint(20f6049ec091fd07961f2f91c54ffb371f90e14feca55034efc6b92b4834d761, 1), scriptSig=3044022063fff07721d44ff6)
CTxIn(COutPoint(2190ad04514d7ec96fc181b929afe7b9907c9354b394bbd66383f49d785d3c3c, 2), scriptSig=3045022100f3fb52f90f5f7d)
CTxIn(COutPoint(312e5f55087c11ca2efbcf8fb00661abae20af694ee6fb60228f062f0caf0464, 2), scriptSig=3045022100b0523fd351adf1)
CTxIn(COutPoint(6b81ff1b00ca2bbfd61f66666d4e2e5e20a12e278669874a7000ae67e15c4331, 1), scriptSig=3045022100cef76412ad5fe5)
CTxIn(COutPoint(4466c6dd2601a856c03d49e9d15ce4759c83fe8caabbbd0f5f6ac6d126d17b2d, 1), scriptSig=3045022100a71c415513b41c)
CTxIn(COutPoint(8317b7f4e17b533d4ad1863a524fec38117f8b6ed3c3147e9c16b8c1a25aa06b, 2), scriptSig=3045022100c3b0b517c26428)
CTxIn(COutPoint(6d55b8630c22ed3d4d989ff1f9f40d7737fdb1d486297d1282b89e8fa0c9d706, 1), scriptSig=304402202ae28904f582fbfd)
CTxIn(COutPoint(593685734a542b1768247eca6758d3c5ec5a1aef2f93f20861609187704af944, 1), scriptSig=304402205aff580606e34a94)
CTxIn(COutPoint(593685734a542b1768247eca6758d3c5ec5a1aef2f93f20861609187704af944, 2), scriptSig=30450221009e107b43e2ca65)
CTxIn(COutPoint(bfb7d986cece74d774e1bbb645ba593e32c973f2e4f2c824598c2e9f9b829f44, 1), scriptSig=3044022076282acc8ca3c33c)
CTxIn(COutPoint(bfb7d986cece74d774e1bbb645ba593e32c973f2e4f2c824598c2e9f9b829f44, 2), scriptSig=304402202ab0e400bde3c442)
CTxIn(COutPoint(32bfeec497e15246e709c031342a9dd0a679fb1f8fa1a4317d33689d692cba77, 2), scriptSig=304402200198d8936bf15366)
CTxIn(COutPoint(a0d6f067fc1d5c0dace25775338215963b38d2f20586ff552a576fbcb1219a1e, 2), scriptSig=3044022035540acdf40927e0)
CTxIn(COutPoint(891d3ac719a9741fffaf2febfd2b5c1d0062cfb4252a6a8a90e5199dfa602f59, 1), scriptSig=30440220358c629061974b50)
CTxIn(COutPoint(891d3ac719a9741fffaf2febfd2b5c1d0062cfb4252a6a8a90e5199dfa602f59, 2), scriptSig=304402202d215b25eb591f6c)
CTxIn(COutPoint(f052ab71266242bd32d60804435c5e9913ca8693481387a3fcbb6a063169e061, 1), scriptSig=304402206c81df22cee7564a)
CTxIn(COutPoint(023c9491768d96176aab8bbb2bbf02f935be84f215085e913c2ef9e750a6401b, 2), scriptSig=304502210096c10c31d2abc9)
CTxIn(COutPoint(57e61cc574f9394e30040692564a43fd98aba28029c4baec40ef9de2c1eb4041, 1), scriptSig=304402203f1be29e782f5ad5)
CTxIn(COutPoint(57e61cc574f9394e30040692564a43fd98aba28029c4baec40ef9de2c1eb4041, 2), scriptSig=3045022100d3b92647731d3b)
CTxIn(COutPoint(f8bdb9f704ea848827a92d230dfdbad0d9f8f6d80cec08f5f08fa5492fa9cd85, 2), scriptSig=304402206247b45373304023)
CTxIn(COutPoint(88cfd7ff256755dea4f82be75a2a4e7e769c9722eaabbd5eb55b4ccd85e06dd4, 2), scriptSig=30450221009f93c526454001)
CTxIn(COutPoint(c9f03871e68a84172ba96ac8b84501af7eb7f24d5794186514370671b72f1d78, 2), scriptSig=3044022070f781bd8e154318)
CTxIn(COutPoint(6c288dfc8b8bf35ff30480a1155a8f87d57694f57a4b53bde01f66c8f0d02b3e, 1), scriptSig=3044022076500667773a7bde)
CTxIn(COutPoint(26c29b9fb7dffbbddfe7fc36eed3df069010824eb661af683c1faf868c2cbd54, 0), scriptSig=3045022100e049bc1d62010c)
CTxIn(COutPoint(ca113955283f5af074f4fa85632ac751210dfd2af84cdf66a2d1be0e739d50f4, 0), scriptSig=3045022100e8b86d3561f4ad)
CTxOut(nValue=0.01625730, scriptPubKey=OP_DUP OP_HASH160 e31d1c500a96)
CTxOut(nValue=1000000.00000000, scriptPubKey=0 6dcbb91433bb85bf5374038a64d9)

They were both sending 1 million tPHR to a bech32 address, but this may have to do with the transaction size given different numbers of inputs.

It may or may not be relevant, but the one that succeeded was within the same wallet, and the one that failed was sending to a different wallet.

Several users, I believe primarily Windows but that could be a coincidence, have reported the following issue appearing in their log file:

GUI: setGeometry: Unable to set geometry 14x39+1600+840 on QWidgetWindow/'QLabelClassWindow'. Resulting geometry: 348x39+1600+840 (frame: 18, 85, 18, 18, custom margin: 0, 0, 0, 0, minimum size: 0x0, maximum size: 16777215x16777215).
GUI: setGeometry: Unable to set geometry 200x47+1600+840 on QWidgetWindow/'QProgressBarClassWindow'. Resulting geometry: 348x47+1600+840 (frame: 18, 85, 18, 18, custom margin: 0, 0, 0, 0, minimum size: 0x0, maximum size: 16777215x16777215).
2018-08-02 18:58:05 GUI: "registerShutdownBlockReason: Successfully registered: Phore Core didn't yet exit safely..."
2018-08-02 18:58:06

This may be crashing the wallet when it happens, although some of the references describe this as a warning rather than an error, and it may be that other issues are causing an error and this just happens to be in the log as well as a warning.

Preliminary research on the issue seems to show that it is due to a window attempting to be drawn or resized smaller than it is able to be drawn, and the suggested resolution is setting a reasonable minimum size for the window which then avoids it from trying to use a smaller size.

However the log doesn't clearly indicate which window or dialog is causing this, and QWidgetWindow and QLabelClassWindow do not show up in Phore's code so it must be in the underlying Qt library that is called from somewhere else.

This issue is happening all the way through at least v1.3.3.1.

References:
mumble-voip/mumble#2843
https://stackoverflow.com/questions/31230975/qt-setgeometry-unable-to-set-geometry
https://forum.qt.io/topic/43535/solved-qwindowswindow-setgeometry-unable-to-set-geometry
https://forum.qt.io/topic/87737/qt-qinputdialog-setgeometry-unable-to-set-geometry/8
https://stackoverflow.com/questions/25537089/unable-to-set-geometry-in-qt

With SegWit activated on testnet, it appears that inputs on bech32 addresses will not stake blocks. I do not have any specific error messages or reasons why pinpointed yet, but there is a large percentage of the total supply of tPHR stored on bech32 addresses, to the point where one out of every 3 or 4 blocks should be staked by a bech32 address if it were able to do so.

My suspicion is that it is one of two causes, or some combination:

1. When the wallet selects staking eligible inputs, it is not finding bech32 addresses.
2. When bech32 addresses try to stake, they are failing one of the staking validation checks and therefore never able to submit a valid block.

I'd suggest we add some additional logging in the staking code to isolate the cause and determine how to get staking for bech32 addresses working.

bitcoin#8723

Merge this when ready: PIVX-Project#549

zPHR UI on the Privacy Tab has slight overlaying. See screenshot below.

Note: This is possibly due to the Full Screen / Maximizing issue from Issue #118. When the wallet goes full screen from clicking on the Masternodes tab, the Privacy tab looks fine. When you shrink the window, the zPHR section gets a bit cramped.

We have received at least one report that a user with a small screen resolution had trouble displaying the entire wallet interface for v1.2.2. This is likely due to the addition of fields on the Privacy tab intended to show the global zPHR supply directly in the GUI.

These fields are not functional yet, and are accessible in the debug console. This task is to either remove those fields (simplest short term fix), or move them to another dialog that can be accessed in the menu which would lead the user to a new tab in the Tools window for zPHR Total Supply

phore.seed.rho.industries not reachable.

See below

This issue tracker is only for technical issues related to PIVX Core.
General PIVX questions and/or support requests and are best directed to the PIVX Slack.

Describe the issue

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

Expected behavior

Tell us what should happen

Actual behavior

Tell us what happens instead

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of PIVX Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package.

Machine specs:

• OS:
• CPU:
• RAM:
• Disk size:
• Disk Type (HD/SDD):

Any extra information that might be useful in the debugging process.

This is normally the contents of a debug.log, db.log or config.log file. Raw text or a link to a pastebin type site are preferred.

hi,

i think the raspberry /arm wallet
actually is not compatibile with armv6l architecture (an old raspberry pi 1) ..
cause i'im getting an 'illegal istruction' at execution.

could you confirm?

thanks.

I believe when nothing in the masternode list information changes, masternodes can be upgraded without downtime when you swap the executable and only briefly bring it down to restart. However, when the protocol number changes, this may be causing each masternode's place in the list to be reset as the change is detected.

This request would be to investigate if this is indeed the case, and if so, if it would be safe and secure to allow masternodes to be upgraded to a new protocol version and allow a change to just that one attribute without resetting the masternode's place in the list.