Pages:
Author

Topic: [TESTNET]Bismuth - New Language, Interpretation Engines, DAPPs - page 16. (Read 49741 times)

legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
Hi,

I'm getting some errors: What does it mean?

Thanks


Hi, "An existing connection was forcibly closed by the remote host" from 127.0.0.1 is an error produced when miner disconnects after submitting a block to the node. Nothing to worry about, it's just that the miner doesn't say goodbye so node isn't sure what happened.

Also, exciting news, version 1.12 will be much faster than current 1.11, because I removed some redundant code that was necessary for "proof of transaction". After successfully separating mempool mechanics from the ledger,w e can go much faster now. I'll release today.

Also, there will be a rollback to block 9 due to a double signature bugfix, shutting down my node until then.

Also, I started working on hyperblock technology for pruning and blockchain-less currency:

https://github.com/hclivess/Bismuth/issues/8
Code:
import sqlite3




conn = sqlite3.connect('ledger.db')
conn.text_factory = str
c = conn.cursor()

hype = sqlite3.connect('hyperblocks.db')
hype.text_factory = str
h = hype.cursor()
try:
    h.execute(
        "CREATE TABLE transactions (block_height INTEGER, timestamp, address, recipient, amount, signature, public_key, block_hash, fee, reward, confirmations, openfield)")
except:
    pass

end_balance = 0
addresses = []
for row in c.execute('SELECT * FROM transactions ORDER BY block_height'):
    db_address = row[2]
    db_recipient = row[3]
    addresses.append (db_address)
    addresses.append (db_recipient)

unique_addressess = set(addresses)


for x in set(unique_addressess):
    if x != "genesis":
        c.execute("SELECT sum(amount) FROM transactions WHERE recipient = '" + x + "'")
        credit = c.fetchone()[0]
        if credit == None:
            credit = 0

        c.execute("SELECT sum(amount) FROM transactions WHERE address = '" + x + "'")
        debit = c.fetchone()[0]
        if debit == None:
            debit = 0

        c.execute("SELECT sum(fee) FROM transactions WHERE address = '" + x + "'")
        fees = c.fetchone()[0]
        if fees == None:
            fees = 0

        c.execute("SELECT sum(reward) FROM transactions WHERE address = '" + x + "'")
        rewards = c.fetchone()[0]
        if rewards == None:
            rewards = 0

        end_balance = credit - debit - fees + rewards
        print x
        print end_balance

        if end_balance > 0:
            h.execute("INSERT INTO transactions VALUES (?,?,?,?,?,?,?,?,?,?,?,?)", ("0","past chain",x,str(float(end_balance)),"0","0","0","0","0","0","0","0"))

hype.commit()
hype.close()
hero member
Activity: 980
Merit: 502
Hi,

I'm getting some errors: What does it mean?

Thanks

---------------------------------------
Exception happened during processing of request from ('127.0.0.1', 56844)
Traceback (most recent call last):
  File "SocketServer.py", line 599, in process_request_thread
  File "SocketServer.py", line 334, in finish_request
  File "SocketServer.py", line 655, in __init__
  File "node.py", line 725, in handle
error: [Errno 10054] An existing connection was forcibly closed by the remote host
----------------------------------------
2016-11-30 21:23:06,943 handle(728) Node: Received:  from 127.0.0.1
2016-11-30 21:23:06,944 handle(1089) Node: Communication error
2016-11-30 21:23:06,944 handle(1094) Node: Lost connection
2016-11-30 21:23:06,944 handle(1095) exceptions must be old-style classes or derived from BaseException, not NoneType
2016-11-30 21:23:06,946 consensus_remove(380) Client 127.0.0.1 not present in the consensus pool
----------------------------------------
Exception happened during processing of request from2016-11-30 21:23:06,948 worker(1116) Client: Connected to 94.113.207.67 2829
 ('127.0.0.2016-11-30 21:23:06,951 worker(1120) Current active pool: ['94.113.207.67:2829']
1', 56846)
Traceback (most recent call last):
  File "SocketServer.py", line 599, in process_request_thread
  File "SocketServer.py", line 334, in finish_request
  File "SocketServer.py", line 655, in __init__
  File "node.py", line 1090, in handle
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
----------------------------------------
2016-11-30 21:23:07,418 worker(1134) Client: Node protocol version matches our client
2016-11-30 21:23:07,634 worker(1144) Client: Received peers______ from 94.113.207.67:2829
2016-11-30 21:23:07,878 worker(1153) [('127.0.0.1', '2829'), ('94.113.207.67', '2829'), ('90.216.208.18', '2829')]
2016-11-30 21:23:07,878 worker(1154) 3
2016-11-30 21:23:07,884 worker(1164) [('127.0.0.1', '2829'), ('94.113.207.67', '2829')]
2016-11-30 21:23:07,884 worker(1182) Client: ('127.0.0.1', '2829') is not a new peer
2016-11-30 21:23:07,884 worker(1182) Client: ('94.113.207.67', '2829') is not a new peer
2016-11-30 21:23:07,884 worker(1169) Client: ('90.216.208.18', '2829') is a new peer, saving if connectible
2016-11-30 21:23:07,888 worker(1179) Not connectible
2016-11-30 21:23:16,759 manager(399) 127.0.0.1:2829
2016-11-30 21:23:17,437 manager(404) ---Starting a client thread <_MainThread(MainThread, started 7016)>---
2016-11-30 21:23:17,437 manager(399) 94.113.207.67:2829
2016-11-30 21:23:17,443 worker(1116) Client: Connected to 127.0.0.1 2829
2016-11-30 21:23:17,443 manager(409) Only 1 connections active, resetting the try list
2016-11-30 21:23:17,443 worker(1120) Current active pool: ['94.113.207.67:2829', '127.0.0.1:2829']
2016-11-30 21:23:17,443 manager(412) Connection manager: Threads at 3/25
2016-11-30 21:23:17,447 handle(728) Node: Received: version____ from 127.0.0.1
2016-11-30 21:23:17,453 manager(413) Tried: []
2016-11-30 21:23:17,453 manager(414) Current active pool: ['94.113.207.67:2829', '127.0.0.1:2829']
2016-11-30 21:23:17,457 manager(415) Current connections: 2
2016-11-30 21:23:17,552 handle(738) Node: Protocol version matched: testnet4___
2016-11-30 21:23:17,654 worker(1134) Client: Node protocol version matches our client
2016-11-30 21:23:17,753 handle(728) Node: Received: helloserver from 127.0.0.1
2016-11-30 21:23:17,755 handle(829) Node: ('127.0.0.1', '2829')
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
New version is out
Incompatible with old versions, testnet ver. 4
https://github.com/hclivess/Bismuth/releases/tag/1.11

The algorithm SHA224 is efficient on GPU?
How about this project: Is it better mining with CPU or GPU ?

Hi, there is no GPU miner and I don't know how to make one so it's only CPU
Did you guys sync blocks? Currently at block 18. Some switches are needed to optimize sync, but it should do so without any errors now.
hero member
Activity: 980
Merit: 502
New version is out
Incompatible with old versions, testnet ver. 4
https://github.com/hclivess/Bismuth/releases/tag/1.11

The algorithm SHA224 is efficient on GPU?
How about this project: Is it better mining with CPU or GPU ?
hero member
Activity: 980
Merit: 502
New version is out
Incompatible with old versions, testnet ver. 4
https://github.com/hclivess/Bismuth/releases/tag/1.11

Running the latest version now
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
New version is out
Incompatible with old versions, testnet ver. 4
https://github.com/hclivess/Bismuth/releases/tag/1.11
hero member
Activity: 980
Merit: 502
Hello, we have identified a bug related to long strings during synchronization of blocks and mempool. The bug has been finally confirmed today not to be related to switches/semafors. The fix is under development now, patience is advised.

Ledger synchronization may malfunction on long blocks

Here is the prototype code:

Code:
import time

mempool_txs = "1a2sdadsasd, asdlkajwldkjaslkdjalksdjalksd, asdlkhjahakjsd, akshdkajshdkjahdjkahdkjahdskjsahkjash222dkjahds"

def split2len(s, n):
    def _f(s, n):
        while s:
            yield s[:n]
            s = s[n:]
    return list(_f(s, n))

mempool_split = split2len(mempool_txs, 50)
mempool_count = len(mempool_split)  # how many segments of 500 will be sent
while len(str(mempool_count)) != 10:
    mempool_count = "0" + str(mempool_count)  # number must be 10 long
#s.sendall(str(mempool_count))  # send how many segments will be transferred
print (str(mempool_count))

mempool_index = -1
while int(mempool_count) > 0:
    mempool_count = int(mempool_count) - 1
    mempool_index = mempool_index + 1

    segment_length = len(mempool_split[mempool_index])
    while len(str(segment_length)) != 10:
        segment_length = "0" + str(segment_length)
    #s.sendall(segment_length)  # send how much they should receive, usually 500, except the last segment
    print(segment_length)
    time.sleep(0.1)
    #s.sendall(mempool_split[mempool_count])  # send segment
    print (mempool_split[mempool_index])
    time.sleep(0.1)

Preliminary tests are succesful:

Code:
2016-11-30 13:07:40,461 worker(1316) Client: Segment to dispatch: ...
2016-11-30 13:07:40,562 worker(1314) Client: Segment length: 0000000004
2016-11-30 13:07:40,562 handle(756) Node: Segment length: 0000000004
2016-11-30 13:07:40,663 worker(1316) Client: Segment to dispatch: =')]
2016-11-30 13:07:40,663 handle(758) Node: Received segment: =')]
2016-11-30 13:07:40,663 handle(761) Node: Combined segments: .....
....
2016-11-30 13:07:40,671 merge_mempool(116) That transaction is already in our mempool
2016-11-30 13:07:40,671 merge_mempool(116) That transaction is already in our mempool

The whole mempool sync is now segmented, tested and works. Proceeding to ledger segmentation.

The whole ledger sync is now segmented, tested and works. Preparing to release.

Great, will give it a trial. I was unable to mine previously
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
Hello, we have identified a bug related to long strings during synchronization of blocks and mempool. The bug has been finally confirmed today not to be related to switches/semafors. The fix is under development now, patience is advised.

Ledger synchronization may malfunction on long blocks

Here is the prototype code:

Code:
import time

mempool_txs = "1a2sdadsasd, asdlkajwldkjaslkdjalksdjalksd, asdlkhjahakjsd, akshdkajshdkjahdjkahdkjahdskjsahkjash222dkjahds"

def split2len(s, n):
    def _f(s, n):
        while s:
            yield s[:n]
            s = s[n:]
    return list(_f(s, n))

mempool_split = split2len(mempool_txs, 50)
mempool_count = len(mempool_split)  # how many segments of 500 will be sent
while len(str(mempool_count)) != 10:
    mempool_count = "0" + str(mempool_count)  # number must be 10 long
#s.sendall(str(mempool_count))  # send how many segments will be transferred
print (str(mempool_count))

mempool_index = -1
while int(mempool_count) > 0:
    mempool_count = int(mempool_count) - 1
    mempool_index = mempool_index + 1

    segment_length = len(mempool_split[mempool_index])
    while len(str(segment_length)) != 10:
        segment_length = "0" + str(segment_length)
    #s.sendall(segment_length)  # send how much they should receive, usually 500, except the last segment
    print(segment_length)
    time.sleep(0.1)
    #s.sendall(mempool_split[mempool_count])  # send segment
    print (mempool_split[mempool_index])
    time.sleep(0.1)

Preliminary tests are succesful:

Code:
2016-11-30 13:07:40,461 worker(1316) Client: Segment to dispatch: ...
2016-11-30 13:07:40,562 worker(1314) Client: Segment length: 0000000004
2016-11-30 13:07:40,562 handle(756) Node: Segment length: 0000000004
2016-11-30 13:07:40,663 worker(1316) Client: Segment to dispatch: =')]
2016-11-30 13:07:40,663 handle(758) Node: Received segment: =')]
2016-11-30 13:07:40,663 handle(761) Node: Combined segments: .....
....
2016-11-30 13:07:40,671 merge_mempool(116) That transaction is already in our mempool
2016-11-30 13:07:40,671 merge_mempool(116) That transaction is already in our mempool

The whole mempool sync is now segmented, tested and works. Proceeding to ledger segmentation.

The whole ledger sync is now segmented, tested and works. Preparing to release.
sr. member
Activity: 742
Merit: 251
https://i.imgur.com/jb0AJil.jpg

I do not know why  can not mining.
full member
Activity: 188
Merit: 105
mining

module (53)mining will start once there are transaction in the mempool

What should I do?

I've sent some tx,  it should of started your miner
sr. member
Activity: 742
Merit: 251
mining

module (53)mining will start once there are transaction in the mempool

What should I do?
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
In order to fix the EOL error, I released version 1.04, which is incompatible with the older versions due to changes in core algorithms
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
One of my nodes got a weird sync problem at block 88, restart solved it. still not sure about the issue:

Code:
rejected

[('1480029059.75', '86cbc69e9f8522c58f5c97fd13e7a5634ea6012207984c54bf83fc7d', '86cbc69e9f8522c58f5c97fd13e7a5634ea6012207984c54bf83fc7d', '9.528544', 'X8T/cu3rNOrpfVOYHwGIsTVGC6CTHPoTurTYY+LehdYjL9deEmkgkn+3ojT+AwOwxfqby9QhenjiHALbXrGHW+IGvo+yo9N3LQCcGcV61xp11e5OL6LILzIPQlbhgZ7FRHpG93SpDccI0DE5gnwRGGTCQII+5wAH8ZDyEnGWVGQ=', '-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4mDjZa5PagYHyumkU+QJRUHu7\nO9yTBR1PddXYmYKd2BCA7RgPuaQY8XegUOUDcj5PQlQuvXBrVmf1Wy2YZ7GNSso3\n/r+Wicd0AZf/nw5gMOJrk22cwQFzJUqIcHhx5oBFXe6NwuC8j8lWFTOylNwD+jiv\niC9nbaXe8BCXQyqxpwIDAQAB\n-----END PUBLIC KEY-----', '')]

accepted

[('1480040472.54', '86cbc69e9f8522c58f5c97fd13e7a5634ea6012207984c54bf83fc7d', '86cbc69e9f8522c58f5c97fd13e7a5634ea6012207984c54bf83fc7d', '1254.0', 't/xFe8WdULyt2TT4Edr55x0ZFW4gcRdMU8xjSwSn4X3oueEzazULhrjGcYqMaqYCt2Lx8rrWIGXoLblmwN6jLTZsQl1+10pxjnl5N5BjItQybURODd97kAHrEyb3k+NCbPGpyTSrGQaCOEUmkWLBADdy6tSCmVbz+LR01epWUWs=', '-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4mDjZa5PagYHyumkU+QJRUHu7\nO9yTBR1PddXYmYKd2BCA7RgPuaQY8XegUOUDcj5PQlQuvXBrVmf1Wy2YZ7GNSso3\n/r+Wicd0AZf/nw5gMOJrk22cwQFzJUqIcHhx5oBFXe6NwuC8j8lWFTOylNwD+jiv\niC9nbaXe8BCXQyqxpwIDAQAB\n-----END PUBLIC KEY-----', ''), ('1480040478.56', '86cbc69e9f8522c58f5c97fd13e7a5634ea6012207984c54bf83fc7d', '86cbc69e9f8522c58f5c97fd13e7a5634ea6012207984c54bf83fc7d', '0.0', 'LYUpjDPrBmMf3IkuugooCLDwNfF8AbDU58aZQwCU5mvUIxjNwMZ8hY7EdXI7nkweyPlRzEw28Qo1kERFUScP1z3ZtgPyLYnoowIB0hK7sEscJWWhZ0XWrWCHK7b6Y19eGNdixbtDbIvkwG+fYijqa4KbLlQ5WT+MuNXIEFLMP88=', '-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4mDjZa5PagYHyumkU+QJRUHu7\nO9yTBR1PddXYmYKd2BCA7RgPuaQY8XegUOUDcj5PQlQuvXBrVmf1Wy2YZ7GNSso3\n/r+Wicd0AZf/nw5gMOJrk22cwQFzJUqIcHhx5oBFXe6NwuC8j8lWFTOylNwD+jiv\niC9nbaXe8BCXQyqxpwIDAQAB\n-----END PUBLIC KEY-----', 'reward')]

I fixed the miner=sender transitional bug and rolled back the main node to block 31, old block 32 is now being rejected, because it had negative balance

Quote
2016-11-25 09:47:53,566 INFO digest_block(421) Digest: Verifying balance
2016-11-25 09:47:53,569 INFO digest_block(422) Digest: Received address: 56628ff43c67d894ea66fa38caf5193a15a86a5a9c05252b77e4cef7
2016-11-25 09:47:53,572 INFO digest_block(435) Digest: Incoming block credit: 0
2016-11-25 09:47:53,582 INFO digest_block(436) Digest: Incoming block debit: 5.0
2016-11-25 09:47:53,604 INFO digest_block(462) Digest: Total credit: 0.0
2016-11-25 09:47:53,605 INFO digest_block(463) Digest: Total debit: 5.0
2016-11-25 09:47:53,608 INFO digest_block(465) Digest: Transction address balance: -5.0
2016-11-25 09:47:53,611 INFO digest_block(476) Fee error: 'NoneType' object has no attribute '__getitem__'
2016-11-25 09:47:53,614 INFO digest_block(498) Digest: Difficulty requirement satisfied
2016-11-25 09:47:53,615 INFO digest_block(501) Digest: Cannot afford to pay fees
2016-11-25 09:47:53,617 INFO digest_block(513) Digest: Removing processed transaction from the mempool
full member
Activity: 188
Merit: 105
Synchronization stopped on the 2nd block

yeah, the same here - 2nd block
download the new one :-) i've got mines running, its @ block 57 just now :-)
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
The new version seems quite reliable, I am aware of the EOL error, which is caused by insegmented mempool sync. This will be fixed tomorrow.
member
Activity: 94
Merit: 10
Synchronization stopped on the 2nd block

yeah, the same here - 2nd block
sr. member
Activity: 939
Merit: 261
Data HDD Repair - Recovery of lost information
Synchronization stopped on the 2nd block
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
Fixed known critical transitional bugs

todo: mempool needs to check at least signature not to go down like ethereum
I was in a hurry however, so I recommend you change the value of timeout from 1 to at least 10 in your config.txt

also, mining diff is now 1 instead of 3, ill change that later
legendary
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
been waiting for this for too long HCLivess
Don't be disappointed, there are transitional bugs still
Pages:
Jump to: