• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.17.x Testing

Status
Not open for further replies.
to Evan :

those fixed 4 DOS-style attacks, are they serious enough that we need to update mainnet as soon as possible once its confirmed it indeed solves them ?
and if serious enough will we implement these fixes in the form of a spork again or do we need more drastic action?
Also i'm curious, were these vulnerabilities in yr crosshairs already or did you got triggered by the post on reddit ?

last question on a totally seperate topic : if you run multiple wallets at the same time (lets say 6-8) can it effect the collateral fees ? Perhaps hit you with more collateral fees ?
 
Last edited by a moderator:
We stopped testing InstantX a few days ago and are actually working on these items:

Sounds good, thanks for updating me. *hides again*
 
those fixed 4 DOS-style attacks, are they serious enough that we need to update mainnet as soon as possible once we confirm it indeed solves them ?
and if serious enough will we implement these fixes in the form of a spork again or do we need more drastic action?

Also i'm curious, were these vulnerabilities in yr crosshairs already or did you got triggered by the post on reddit ?

last question on a totally seperate topic : if you run multiple wallets at the same time (lets say 6-8) can it effect the collateral fees ? Perhaps hit you with more collateral fees ?

1. Any one of them could have stopped mixing partially on mainnet for a period of time. It's not very serious.

2. I started looking an the way CScripts are handled after I was told about the nLockTime collateral DOS attack. That lead me to doing some extra checks on user provided data. These are definitely not low hanging fruit anymore, Darksend is becoming much more resistant.

3. It shouldn't have any effect on collateral fees. If you have a wallet with lots of collateral fees please send me the debug.log and collateral transaction IDs so I can check it out.
 
I see 5

"162.243.63.93:19999" : 70049,
"85.214.22.190:19999" : 70049,
"81.169.177.196:19999" : 70049,
"198.50.148.87:19999" : 70049,
"92.222.10.179:19999" : 70049

Just waiting for the chain to sync and soon to be 6 :cool:

EDIT: Damn, never seen the daemon crash on me. Giving VULTR a go, Ubuntu 64 14.10, updated. Any clue? Tried a few time, seems to happen when I issue MN commands

yidakee@install:~$ ./darkcoind masternode debug
No problems were found
yidakee@install:~$ *** buffer overflow detected ***: ./darkcoind terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x789ef)[0x7f9bf2c949ef]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f9bf2d285cc]
/lib/x86_64-linux-gnu/libc.so.6(+0x10a620)[0x7f9bf2d26620]
/lib/x86_64-linux-gnu/libc.so.6(+0x10c517)[0x7f9bf2d28517]
./darkcoind[0x4fba9f]
./darkcoind[0x4fcb2a]
./darkcoind[0x650aaa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a5)[0x7f9bf35060a5]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9bf2d1684d]
======= Memory map: ========
00400000-00b21000 r-xp 00000000 fd:01 80010 /home/yidakee/darkcoind
00d21000-00d45000 r--p 00721000 fd:01 80010 /home/yidakee/darkcoind
00d45000-00d55000 rw-p 00745000 fd:01 80010 /home/yidakee/darkcoind
00d55000-00d71000 rw-p 00000000 00:00 0
024d0000-02512000 rw-p 00000000 00:00 0 [heap]
02512000-0421e000 rw-p 00000000 00:00 0 [heap]
0421e000-0421f000 rw-p 00000000 00:00 0 [heap]
0421f000-04229000 rw-p 00000000 00:00 0 [heap]
04229000-0422a000 rw-p 00000000 00:00 0 [heap]
0422a000-04233000 rw-p 00000000 00:00 0 [heap]
04233000-04234000 rw-p 00000000 00:00 0 [heap]
04234000-04235000 rw-p 00000000 00:00 0
 
Last edited by a moderator:
This Iranian seems to have overstated the impact of what he thinks he knows (See, I can be subtle when I want).

I do wonder if this relates to the unexplained but persistent masternode daemon crashes tho...
 
Again, this time I just started the daemon and let it be...

darkcoind: /home/ubuntu/install/include/boost/thread/pthread/thread_data.hpp:207: boost::detail::interruption_checker::~interruption_checker(): Assertion `!pthread_mutex_unlock(m)' failed.

Will try with the QT and then local daemon... anyone else get this?
 
Last edited by a moderator:
This Iranian seems to have overstated the impact of what he thinks he knows (See, I can be subtle when I want).

I do wonder if this relates to the unexplained but persistent masternode daemon crashes tho...

That Iranian should go and fix their stuxnet first ;)
 
Fixed darksend queue miscalculations (causing the "Darksend too recent" errors)
Good deal, this one's been around for a while.

Added functionality to disable .1+1 denominations after the client has 20 of each. After that it'll just anonymize 10DRK inputs till it reaches your desired amount.
Is that manual, or automatic based on smarts/magic?

Won't that make denominating 35,000DRK kinda bloaty? Will it really be any faster? Lots and lots of little TXes all day long, instead of occasional big TXes averaging to the same timeframe? It'll keep the queues filled, so I guess that's an added benefit even if the former is a wash.
 
You're on fire today Mr. Duffield


Edit:
Bah I do this once every week it seems.

make clean
make
launch...... same version
forgot to pull
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top