jan at uos.de [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-14 to 2011-07-04
💬 Posted a total of 4 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1q4mxmcaamghs49c995y7xj5a9ndnrnnqm4z8rjaj0t9amc9uw4dsmx8aml

Profile Code

nprofile1qqsq2anduw7a5tc2juzj6z0rf2wjeke3eesd63r3ewe84j7auz782kc5sjke4

Author Public Key

npub1q4mxmcaamghs49c995y7xj5a9ndnrnnqm4z8rjaj0t9amc9uw4dsmx8aml

Show more details

Last Notes

2023-06-07 02:02:21

- reply

📅 Original date posted:2011-07-04
🗒️ Summary of this message: Jan Vornberger updated that he fixed the issue with "sendfrom" by changing the cache rebuild approach, and pushed the changes to the Github branch.
📝 Original message:Another quick update:
On Sun, Jul 03, 2011 at 06:29:05PM +0200, Jan Vornberger wrote:
> as now "sendfrom" starts acting up and I have to look into that
> next.
I realized why this happens: Sendfrom triggers a rebuild of the cache
and couldn't return before the rebuild was complete.
So I changed the approach slightly: A complete rebuild of the cache will
only happen on new blocks (in case reorgs happen) whereas on new wallet
transactions the cache will just be adjusted incrementally. Seems to
work fine so far (every 4000 calls or so I double check the cache by
running a full calculation and compare the results. No mismatch happened
so far). The changes are pushed to the github branch I linked to.
One caveat I realized: The cache will not work correctly with the RPC
command "move" as I haven't implemented the necessary adjustments.
Shouldn't be too difficult, but since I don't use that command, I
haven't done this (yet).
Regards!
Jan

2023-06-07 01:59:44

- reply

📅 Original date posted:2011-07-01
🗒️ Summary of this message: Jan suggests enabling UPnP by default in the GUI but leaving it off in bitcoind. He acknowledges the security risks but believes it's necessary for P2P communication.
📝 Original message:On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote:
> > Not sure about OS differentiation, seems...wrong? Maybe disabled by
> > default on bitcoind but on by default on bitcoin?
>
> OK. I mis-remembered the poll:
> http://forum.bitcoin.org/index.php?topic=4392.0
>
> On by default 8 (20%)
> Off by default 22 (55%)
> On by default in the GUI, off by default in bitcoind 10 (25%)
I just voted as well and now - with some extra votes in the meantime -
it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
(9 + 13).
I'm in favor of turning it on by default in the GUI and leaving it off
in bitcoind.
I don't like UPnP much, I find it exemplifies exactly what is wrong with
computer security today: Convenience trumps security almost every time.
BUT: I don't think this is the moment to fight UPnP. It's the standard
mechanism in use today to let a computer behind a NAT accept incoming
connections. The user has already made the decision in regards to
convenience over security. By enabling UPnP (or by buying a product that
does this automatically) they are saying: I want it to "just work"
instead of having fine-grained but more complicated control.
Bitcoin is a P2P application and as such should use this
mechanism. I think it's pretty clear that participating in a P2P network
requires one to receive messages from other peers. At least no one seems
to be concerned that Bitcoin (by default!) listens on port 8333. So I
think it's only logical to extend that to work behind NATs as well.
Cheers!
Jan

2023-06-07 01:57:53

- reply

📅 Original date posted:2011-06-23
🗒️ Summary of this message: Instawallet is experiencing slow performance due to bitcoind taking too long to compute balances. The solution is to implement a cache system.
📝 Original message:Hi there!
Instawallet has enjoyed steady growth and I'm running into a bottleneck
now with "getbalance <someaccounthere>" taking quite some time to
complete. My understanding is, that this is because bitcoind runs
through all relevant transactions each time anew to compute the balance.
I was hoping the list could give me some pointers/ideas on how I can
improve this.
I might start to do account handling completely in my application at
some point, but for now I would like to continue letting bitcoind handle
this, so I don't have to worry about thinks like block chain reorgs.
Basically I don't have enough familiarity with the source code to feel
confident about doing fairly invasive changes. So right now I'm planning
to implement a very simple cache (directly in bitcoind), which just
caches calls to getbalance and simply invalidates the whole cache as
soon as a new block or a transaction that affects the wallet comes in.
I'm hoping this will help a little bit, although with blocks arriving
every 10 minutes on average it's not really the perfect solution.
Maybe one step better would be to only invalidate cache entries that are
affected by a new transaction or by transactions arriving in a block.
This would need to take block chain reorgs into account though, which
seems fairly complicated. Maybe I could simply invalidate the whole
cache on reorgs, which should be seldom enough that it's not a big
problem. Where would be a good place in the source code to hook into to
notice block chain reorgs?
The perfect solution would be, of course, if bitcoind could keep running
balances of all accounts and update them as new information becomes
available. But as I said, I don't feel that I have a good overview of
all the corner cases to make such an improvement. I guess an extensive
test suite testing all sorts of esoteric block chain reorgs would really
be a nice thing to have. :-)
Regards!
Jan

2023-06-07 01:55:30

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: The author questions the rule requiring a fee for any output less than CENT and suggests loosening it to "all outputs" or "50% of outputs."
📝 Original message:Hi there!
As can been seen from this code block
// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
BOOST_FOREACH(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = nBaseFee;
a fee is required as soon as any output is less than CENT.
I was wondering: would it be possible to loosen this rule to something
like "if _all_ outputs are less than CENT" or maybe "if more than 50% of
all outputs are less than CENT"?
The reason is, that I'm currently working on a project, where I would
like to take a small cut on transactions passing through (probably not
an usual requirement) and a lot of those small cuts would probably bump
into this rule.
Isn't this rule mainly meant to prevent lots of transactions with small
coins? So "all small coins" should work as well as "any small coins" or
am I missing something? (things like creating large transactions should
already be caught by other rules, right?)
Regards!
Jan

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2011-06-23
🗒️ Summary of this message: Instawallet is experiencing slow performance due to bitcoind taking too long to compute balances. The solution is to implement a cache system.
📝 Original message: Hi there!
Instawallet has enjoyed steady growth and I'm running into a bottleneck
now with "getbalance <someaccounthere>" taking quite some time to
complete. My understanding is, that this is because bitcoind runs
through all relevant transactions each time anew to compute the balance.
I was hoping the list could give me some pointers/ideas on how I can
improve this.
I might start to do account handling completely in my application at
some point, but for now I would like to continue letting bitcoind handle
this, so I don't have to worry about thinks like block chain reorgs.
Basically I don't have enough familiarity with the source code to feel
confident about doing fairly invasive changes. So right now I'm planning
to implement a very simple cache (directly in bitcoind), which just
caches calls to getbalance and simply invalidates the whole cache as
soon as a new block or a transaction that affects the wallet comes in.
I'm hoping this will help a little bit, although with blocks arriving
every 10 minutes on average it's not really the perfect solution.
Maybe one step better would be to only invalidate cache entries that are
affected by a new transaction or by transactions arriving in a block.
This would need to take block chain reorgs into account though, which
seems fairly complicated. Maybe I could simply invalidate the whole
cache on reorgs, which should be seldom enough that it's not a big
problem. Where would be a good place in the source code to hook into to
notice block chain reorgs?
The perfect solution would be, of course, if bitcoind could keep running
balances of all accounts and update them as new information becomes
available. But as I said, I don't feel that I have a good overview of
all the corner cases to make such an improvement. I guess an extensive
test suite testing all sorts of esoteric block chain reorgs would really
be a nice thing to have. :-)
Regards!
Jan

2023-06-06 10:35:56

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: The author questions the rule requiring a fee for any output less than CENT and suggests loosening it to "all outputs" or "50% of outputs."
📝 Original message: Hi there!
As can been seen from this code block
// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
BOOST_FOREACH(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = nBaseFee;
a fee is required as soon as any output is less than CENT.
I was wondering: would it be possible to loosen this rule to something
like "if _all_ outputs are less than CENT" or maybe "if more than 50% of
all outputs are less than CENT"?
The reason is, that I'm currently working on a project, where I would
like to take a small cut on transactions passing through (probably not
an usual requirement) and a lot of those small cuts would probably bump
into this rule.
Isn't this rule mainly meant to prevent lots of transactions with small
coins? So "all small coins" should work as well as "any small coins" or
am I missing something? (things like creating large transactions should
already be caught by other rules, right?)
Regards!
Jan

2023-06-06 10:33:32

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: The author questions the rule requiring a fee for any output less than CENT and suggests loosening it to "all outputs" or "50% of outputs."
📝 Original message: Hi there!
As can been seen from this code block
// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
BOOST_FOREACH(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = nBaseFee;
a fee is required as soon as any output is less than CENT.
I was wondering: would it be possible to loosen this rule to something
like "if _all_ outputs are less than CENT" or maybe "if more than 50% of
all outputs are less than CENT"?
The reason is, that I'm currently working on a project, where I would
like to take a small cut on transactions passing through (probably not
an usual requirement) and a lot of those small cuts would probably bump
into this rule.
Isn't this rule mainly meant to prevent lots of transactions with small
coins? So "all small coins" should work as well as "any small coins" or
am I missing something? (things like creating large transactions should
already be caught by other rules, right?)
Regards!
Jan

2023-06-06 10:29:39

- reply

Original date posted:2011-06-23
📝 Summary of this message: Instawallet is experiencing slow performance due to bitcoind taking too long to compute balances. The solution is to implement a cache system.
Hi there!
Instawallet has enjoyed steady growth and I'm running into a bottleneck
now with "getbalance <someaccounthere>" taking quite some time to
complete. My understanding is, that this is because bitcoind runs
through all relevant transactions each time anew to compute the balance.
I was hoping the list could give me some pointers/ideas on how I can
improve this.
I might start to do account handling completely in my application at
some point, but for now I would like to continue letting bitcoind handle
this, so I don't have to worry about thinks like block chain reorgs.
Basically I don't have enough familiarity with the source code to feel
confident about doing fairly invasive changes. So right now I'm planning
to implement a very simple cache (directly in bitcoind), which just
caches calls to getbalance and simply invalidates the whole cache as
soon as a new block or a transaction that affects the wallet comes in.
I'm hoping this will help a little bit, although with blocks arriving
every 10 minutes on average it's not really the perfect solution.
Maybe one step better would be to only invalidate cache entries that are
affected by a new transaction or by transactions arriving in a block.
This would need to take block chain reorgs into account though, which
seems fairly complicated. Maybe I could simply invalidate the whole
cache on reorgs, which should be seldom enough that it's not a big
problem. Where would be a good place in the source code to hook into to
notice block chain reorgs?
The perfect solution would be, of course, if bitcoind could keep running
balances of all accounts and update them as new information becomes
available. But as I said, I don't feel that I have a good overview of
all the corner cases to make such an improvement. I guess an extensive
test suite testing all sorts of esoteric block chain reorgs would really
be a nice thing to have. :-)
Regards!
Jan

2023-06-06 10:29:03

- reply

Original date posted:2011-06-14
📝 Summary of this message: The author questions the rule requiring a fee for any output less than CENT and suggests loosening it to "all outputs" or "50% of outputs."
Hi there!
As can been seen from this code block
// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
BOOST_FOREACH(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = nBaseFee;
a fee is required as soon as any output is less than CENT.
I was wondering: would it be possible to loosen this rule to something
like "if _all_ outputs are less than CENT" or maybe "if more than 50% of
all outputs are less than CENT"?
The reason is, that I'm currently working on a project, where I would
like to take a small cut on transactions passing through (probably not
an usual requirement) and a lot of those small cuts would probably bump
into this rule.
Isn't this rule mainly meant to prevent lots of transactions with small
coins? So "all small coins" should work as well as "any small coins" or
am I missing something? (things like creating large transactions should
already be caught by other rules, right?)
Regards!
Jan

2023-06-06 09:14:14

- reply

{"author":"jan at uos.de","date":"2011-06-14T19:45:30","text":"Hi there!\n\nAs can been seen from this code block\n\n // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01\n if (nMinFee < nBaseFee)\n BOOST_FOREACH(const CTxOut& txout, vout)\n if (txout.nValue < CENT)\n nMinFee = nBaseFee;\n\na fee is required as soon as any output is less than CENT.\n\nI was wondering: would it be possible to loosen this rule to something\nlike \"if _all_ outputs are less than CENT\" or maybe \"if more than 50% of\nall outputs are less than CENT\"?\n\nThe reason is, that I'm currently working on a project, where I would\nlike to take a small cut on transactions passing through (probably not\nan usual requirement) and a lot of those small cuts would probably bump\ninto this rule.\n\nIsn't this rule mainly meant to prevent lots of transactions with small\ncoins? So \"all small coins\" should work as well as \"any small coins\" or\nam I missing something? (things like creating large transactions should\nalready be caught by other rules, right?)\n\nRegards!\nJan","summary":"📝 Summary of this message: \nThe author questions the rule requiring a fee for any output less than CENT and suggests loosening it to \"all outputs\" or \"50% of outputs.\""}