Page 3 of 4
Re: The Great Aggregating
Posted: Sun Aug 24, 2014 9:04 pm
by indolering
phelix wrote:From what I see it looks like the "band-aid" patch (raising MIN_RELAY_TX_FEE from 10000 to 100000 just like Bitcoin) will not cause any issues of normal TXs not going through because TX fees when creating TXs are based on MIN_TX_FEE. Anybody see this differently?
So I suggest we add the band-aid patch to the master branch ("namecoinq").
Yes, I think there is a general consensus on this point. However, I believe Bitcoin actually lowered their relay TX fee. I'll ask Midnight to comment.
Re: The Great Aggregating
Posted: Sun Aug 24, 2014 9:18 pm
by midnightmagic
Bitcoin recently did reduce their tx relay fee.
Some people argued against it for the reason that it would make Bitcoin ultimately more susceptible to this issue.
Bitcoin's economic disincentives offer significant protections against mempool exhaustion attacks (whether memory, or CPU-based.)
Re: The Great Aggregating
Posted: Wed Aug 27, 2014 1:09 pm
by phelix
Re: The Great Aggregating [v0.3.76beta]
Posted: Thu Aug 28, 2014 11:16 pm
by whitebeard
It seems to me there might be a simpler approach to this than changing fees and slapping on band-aids. Pretty soon it won't be a block-chain; it'll be a bandage-chain. What we need to do is remove the need for people to consolidate all their tiny transactions, by doing it for them automatically.
Couldn't we add a feature to the wallet that automatically consolidates all extant inputs to a particular address if there are any inputs of at least X days of age into one transaction, by adding a marker to a new block that effectively authenticates the presence of all these inputs from previous blocks, so there is no need to search further back down the block-chain for authentication of the inputs. Thus decreasing the data size of any future outputs from that address. I would make it so that it would, also, automatically re-consolidate the returned change inputs by adding them back to the address from which they originally came without having them travel the block-chain again.
To take this further, it effectively would be an auto-pruning measure, because at some point you would never need to go back to the genesis block for authentication.
This, ultimately, may or may not have an effect on difficulty, so care needs to be taken that we do not introduce inflation into the economy.
Just an idea. What do you all think?
whitebeard
Re: The Great Aggregating [v0.3.76beta]
Posted: Sat Aug 30, 2014 6:56 am
by phelix
whitebeard wrote:It seems to me there might be a simpler approach to this than changing fees and slapping on band-aids. Pretty soon it won't be a block-chain; it'll be a bandage-chain. What we need to do is remove the need for people to consolidate all their tiny transactions, by doing it for them automatically.
Couldn't we add a feature to the wallet that automatically consolidates all extant inputs to a particular address if there are any inputs of at least X days of age into one transaction, by adding a marker to a new block that effectively authenticates the presence of all these inputs from previous blocks, so there is no need to search further back down the block-chain for authentication of the inputs. Thus decreasing the data size of any future outputs from that address. I would make it so that it would, also, automatically re-consolidate the returned change inputs by adding them back to the address from which they originally came without having them travel the block-chain again.
To take this further, it effectively would be an auto-pruning measure, because at some point you would never need to go back to the genesis block for authentication.
This, ultimately, may or may not have an effect on difficulty, so care needs to be taken that we do not introduce inflation into the economy.
Just an idea. What do you all think?
whitebeard
Automatically consolidating is bad. Pruning is good and we (Domob) are working on it but it is difficult. Help with coding is appreciated.
With the latest patch (v0.3.76beta2) included the system runs stable now even when the aggregator waves come in:
getmemorypool...
n TX: 18
rpc time: 0.17 max: 2.50
Size TXs [kb]: 317
getauxblock...
rpc time: 0.00 max: 2.50
getrawmempool...
n TX: 2051
Size all TXs [kb]: 36696 maxTxSize: 17
--> maximum getauxblocktime of 2.5 seconds is OK
I will provide a windows binary later today.
Re: The Great Aggregating [v0.3.76beta]
Posted: Sat Aug 30, 2014 5:38 pm
by whitebeard
Automatically consolidating is bad.
Why? Please expand on this. What is your rationale?
Re: The Great Aggregating [v0.3.76beta]
Posted: Sat Aug 30, 2014 7:26 pm
by phelix
whitebeard wrote:Automatically consolidating is bad.
Why? Please expand on this. What is your rationale?
Privacy issues was the first thing to jump to mind. Probably others. I would be happy to further discuss this suggestion but please create a separate thread for it.
Re: The Great Aggregating [v0.3.76beta]
Posted: Sat Aug 30, 2014 7:40 pm
by phelix
Re: The Great Aggregating [v0.3.76rc1]
Posted: Sat Aug 30, 2014 10:27 pm
by whitebeard
To continue the conversation about
Auto-pruning and transaction consolidation I created this new thread. Come join the conversation!
Re: The Great Aggregating [v0.3.76rc1]
Posted: Mon Sep 08, 2014 7:27 pm
by tosh0
For me, i downloaded, installed, since the last version was taking way too much to sync.
only issue , i had to open and close it again,
since it was stuck on some block ." 193229" <---if someone had similar problem please report.
Also the usual "this file have never been seen before by Avast".
Windows 7 x64 with sp1.