Bitcoin Forum
July 09, 2020, 12:26:37 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
221  Bitcoin / Development & Technical Discussion / Re: Transaction Overload Solution on: August 05, 2010, 05:38:21 PM
I can't think of a way to implement that.  All the transaction fees would be additional transactions.  What about the transaction fees for the transaction fee's transaction?
222  Bitcoin / Development & Technical Discussion / Re: bitcoind transaction to ip address on: August 05, 2010, 05:28:40 PM
It's not implemented.

It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.
223  Bitcoin / Bitcoin Discussion / Re: Who's the Spanish jerk draining the Faucet? on: August 05, 2010, 05:06:03 PM
Silently failing would look bad.

1. Rate limit based on the first byte of the IP address (79. or 81. in this case).
Definitely needed.  What rate are you thinking of?  Ultimately, it's better to rate limit it than to let it all drain out.

3. Rate limit based on last two domains of reverse DNS lookup of the IP address ( in this case).
That might work surprisingly well.  If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.

4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).
Definitely time to lower it.
224  Bitcoin / Bitcoin Discussion / Re: Flood attack 0.00000001 BC on: August 05, 2010, 04:39:58 PM
The only solution to this problem is to make broadcasting of a transaction "non free".  Namely, if you want me to include it you have to pay me.  The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block.   In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.  
I don't know a way to implement that.  The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size.  If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
225  Bitcoin / Bitcoin Discussion / Re: Flood attack 0.00000001 BC on: August 05, 2010, 04:30:20 PM
Quote from: bytemaster
Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned.  This rule makes it impossible to pay for a simple "search query" with no further transactions.
One alternative is to use a round-up system.  You pay for, say, 1000 pages or images or downloads or searches or whatever at a time.  When you've used up your 1000 pages, you pay for another 1000 pages.  If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.

Or you could pay per day.  The first time you access the site on a given day, you pay for 24 hours of access.

Per 1000 or per day may be easier for consumers to get their heads around too.  They worry about per item because it's harder to figure if it might add up too fast.  Unlimited for 24 hours they know what the cost will be.  Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.
226  Bitcoin / Bitcoin Discussion / Re: Flood attack 0.00000001 BC on: August 05, 2010, 04:03:21 PM
Forgot to add the good part about micropayments.  While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall.  If Bitcoin catches on on a big scale, it may already be the case by that time.  Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms.  Whatever size micropayments you need will eventually be practical.  I think in 5 or 10 years, the bandwidth and storage will seem trivial.

I am not claiming that the network is impervious to DoS attack.  I think most P2P networks can be DoS attacked in numerous ways.  (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee.  0.1.5 actually had an option to set that, but I took it out to reduce confusion.  Free transactions are nice and we can keep it that way if people don't abuse them.

That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01?  It would be awfully annoying to ask each time.  If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left.  I think it should just add it automatically.  It's trivial compared to the fees many other types of services add automatically.

Does including more slow down your hashing rate?  
No, not at all.
227  Bitcoin / Bitcoin Discussion / Re: Flood attack 0.00000001 BC on: August 04, 2010, 04:25:36 PM
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments.
228  Bitcoin / Bitcoin Discussion / Re: Building initial transaction trust through "coin ripping" on: August 04, 2010, 12:40:40 AM
The software is designed to support things like this.  I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time.
229  Bitcoin / Bitcoin Discussion / Re: Please upgrade to 0.3.8! on: August 04, 2010, 12:29:37 AM
I guess SourceForge hasn't updated its mirrors yet.  The files are there on the admin side, but not on the user side.  I have no idea how long that will take.  It's always been immediate in the past.

Edit: SourceForge is updated now.
230  Bitcoin / Development & Technical Discussion / Re: Bitcoind x86 binary for CentOS on: August 04, 2010, 12:09:32 AM
There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
I'd rather you didn't make a build of the 1000 node connecting version available.  It won't take very many people running that before we have to make another release just to limit the incoming connections.
231  Bitcoin / Bitcoin Discussion / Please upgrade to 0.3.8! on: August 03, 2010, 11:40:18 PM
Version 0.3.8 adds an important security improvement.  Everyone should upgrade to get this change.

The new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.

If it sees a longer chain, but it can't process it, then it knows something is wrong.  It displays "WARNING: Displayed transactions may not be correct!  You may need to upgrade." and makes most RPC commands return an error.  It still keeps generating as normal, which is necessary for the stability of the network.

There were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!

Also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.

232  Bitcoin / Bitcoin Discussion / Re: What happens when network is split for prolonged time and reconnected? on: August 03, 2010, 10:45:07 PM
creighto: I agree with that idea.  After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance.  It could tell if it's not hearing the hum of the world anymore.

Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),
In practice, splits are likely to be very asymmetrical.  It would be hard to split the world down the middle.  More likely it would be a single country vs the rest of the world, lets say a 1:10 split.  In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days.  Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.

If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?
There's no time limit.  Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.

233  Bitcoin / Development & Technical Discussion / Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python) on: August 03, 2010, 09:26:26 PM
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it.  When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ?  It'd be nice to document that.
I guess we should try to support the case where there's no Content-Length parameter.  I don't want to rip and replace streams though, even if it has to read one character at a time.

Edit: That is, assuming there actually are any libraries that don't support Content-Length.
234  Bitcoin / Development & Technical Discussion / Re: Bitcoind x86 binary for CentOS on: August 03, 2010, 09:05:08 PM
I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk. Undecided
I urge you not to use BDB 4.8.  The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.

235  Bitcoin / Development & Technical Discussion / Re: Builds for Ubuntu? on: August 03, 2010, 08:56:11 PM
Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk
Yes, 0.3.7 has it.  It was in rev 112.
236  Bitcoin / Development & Technical Discussion / Re: Protocol Buffers for Bitcoin on: August 02, 2010, 08:22:08 PM
The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure.  Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.

I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly.  The serialization format we have is as dead simple and flat as possible.  There is no extra freedom in the way the input stream is formed.  At each point, the next field in the data structure is expected.  The only choices given are those that the receiver is expecting.  There is versioning so upgrades are possible.

CAddress is about the only object with significant reserved space in it.  (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)

The larger things we have like blocks and transactions can't be optimized much more for size.  The bulk of their data is hashes and keys and signatures, which are uncompressible.  The serialization overhead is very small, usually 1 byte for size fields.

On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists.  There are few P2P systems that only need broadcast.  There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want.  Those libraries are also much harder to install than ourselves.
237  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 02, 2010, 07:02:46 PM
Is it 2x fast on AMD and 1/2 fast on Intel?

Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?
Tried that, but it doesn't work for things on the stack.  I ran some tests.

It doesn't even cause an error, it just doesn't align it.
238  Bitcoin / Bitcoin Technical Support / Re: Mac Client Problems Outlined... on: August 02, 2010, 06:02:20 PM
"Minimize to the tray instead of the taskbar" & "Minimize to the tray on close" must not be implemented yet on the Mac.  We should grey them out in the next version.
239  Bitcoin / Bitcoin Technical Support / Re: Linux version => No GUI after upgrade. WTF? on: August 02, 2010, 05:39:27 PM
Did it print anything to the console?  Are you sure you didn't run "bitcoind"?

Try version 0.3.7.
240  Bitcoin / Bitcoin Technical Support / Re: Linux distribution download on: July 31, 2010, 02:38:52 PM
It can be built with Boost 1.37 or later.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!