Bitcoin Forum
May 23, 2019, 12:26:49 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
  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 »
201  Bitcoin / Bitcoin Technical Support / Re: Lost large number of bitcoins on: August 11, 2010, 09:46:51 PM
I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.
You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup.  (like 5 seconds)

Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction.
No, it doesn't usually empty your wallet with each transaction.  It uses the smallest set of coins it can find to add up to near the amount.  In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change.
202  Bitcoin / Bitcoin Discussion / Re: Not a suggestion on: August 11, 2010, 09:07:59 PM
Still thinking this idea through...

The only job the network needs to do is to tell whether a spend of an outpoint is the first or not.

If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:
- the value
- the association of inpoints and outpoints in one transaction

The network would track a bunch of independent outpoints.  It doesn't know what transactions or amounts they belong to.  A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent.  The network keeps the outpoint and the first valid inpoint that proves it spent.  The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.

I believe the clients would have to keep the entire history back to the original generated coins.  Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend.  Maybe the data transfer could be done as an e-mail attachment.

The fact that clients have to keep the entire history reduces the privacy benefit.  Someone handling a lot of money still gets to see a lot of transaction history.  The way it retrospectively fans out, they might end up seeing a majority of the history.  Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.
203  Bitcoin / Development & Technical Discussion / Re: Compile error in SVN r127 on: August 11, 2010, 01:42:30 AM
Updated SVN.  Thanks.

There's little hope of not repeatedly stumbling over that in the future.  It doesn't break the compile for me.
204  Bitcoin / Development & Technical Discussion / Re: Escrow on: August 11, 2010, 01:30:02 AM
Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.

When you pay for something up front, you can't get it back either.  Consumers seem comfortable with that.  It's no worse than that.

Either party always has the option to release it to the other.

But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
Then you must also be against the common system of payment up front, where the customer loses.

Payment up front: customer loses, and the thief gets the money.
Simple escrow: customer loses, but the thief doesn't get the money either.

Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?

Imagine someone stole something from you.  You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it?  Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too?  If they give it back, you can re-activate it.

Imagine if gold turned to lead when stolen.  If the thief gives it back, it turns to gold again.

It still seems to me the problem may be one of presenting it the right way.  For one thing, not being so blunt about "money burning" for the purposes of game theory discussion.  The money is never truly burned.  You have the option to release it at any time forever.
205  Bitcoin / Bitcoin Discussion / Re: Not a suggestion on: August 11, 2010, 12:14:22 AM
This is a very interesting topic.  If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.

Originally, a coin can be just a chain of signatures.  With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations.  It's the need to check for the absence of double-spends that requires global knowledge of all transactions.

The challenge is, how do you prove that no other spends exist?  It seems a node must know about all transactions to be able to verify that.  If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before.  Do you have any ideas on this?

It's hard to think of how to apply zero-knowledge-proofs in this case.

We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
206  Bitcoin / Bitcoin Discussion / Re: Version update for Linux 64-bit on: August 10, 2010, 11:46:00 PM
SVN rev 128: disable SSE2 on 32-bit.  This may only disable it for MSVC and GCC.  Other compilers might have different 64-bit defines.
207  Bitcoin / Bitcoin Discussion / Re: Bitcoin minting is thermodynamically perverse on: August 09, 2010, 09:28:39 PM
The heat from your computer is not wasted if you need to heat your home.  If you're using electric heat where you live, then your computer's heat isn't a waste.  It's equal cost if you generate the heat with your computer.

If you have other cheaper heating than electric, then the waste is only the difference in cost.

If it's summer and you're using A/C, then it's twice.

Bitcoin generation should end up where it's cheapest.  Maybe that will be in cold climates where there's electric heat, where it would be essentially free.
208  Bitcoin / Development & Technical Discussion / Connection limits on: August 09, 2010, 08:58:45 PM
SVN rev 125:
- Always make 8 outbound connections even if have 8 inbound
- Limit outbound connections to one per a.b.?.? range
- Switch -maxconnections=#

I added the (currently undocumented) switch -maxconnections=#.  You shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.

I haven't really tested -maxconnections much, could someone test it?
209  Bitcoin / Bitcoin Discussion / Re: Version update for Linux 64-bit on: August 09, 2010, 08:55:06 PM
That's a good point, I believe you could run with generation off if you don't have SSE2.

How about add to the top of cryptopp/config.h:

#if !defined(_M_X64) && !defined(__x86_64__)

that would disable SSE2 for 32-bit builds.  (at least with GCC or MSVC)
210  Bitcoin / Development & Technical Discussion / Re: bitcoin generation broken in 0.3.8? (64-bit) on: August 09, 2010, 08:34:06 PM
I uploaded for Linux with re-built 64-bit.  I ran a difficulty 1 test with it and it has generated blocks.

211  Bitcoin / Development & Technical Discussion / Re: What could be the transition plan to Y2038 compliant Bitcoin? on: August 09, 2010, 08:13:26 PM
unsigned int is good until 2106.  Surely the network will have to be totally revamped at least once by then.

There should not be any signed int.  If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int.
212  Bitcoin / Bitcoin Discussion / Version update for Linux 64-bit on: August 09, 2010, 07:46:58 PM
When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build.  Version is on SourceForge with the 64-bit binary updated.


Future versions after 0.3.8 will probably require SSE2.  Anyone have Pentium 3 or older where this would be a problem?
213  Bitcoin / Development & Technical Discussion / Re: bitcoin generation broken in 0.3.8? on: August 09, 2010, 06:50:41 PM
I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility.  I was trying to take the safer option.

It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime.  There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime.  Maybe I'm not looking in the right place.

Should we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.

I will recompile the 64-bit part of the Linux 0.3.8 release.
214  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 07, 2010, 09:16:01 PM
CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
Sorry about that.  CRITICAL_BLOCK isn't perfect.  You have to be careful not to break or continue out of it.  There's an assert that catches and warns about break.  I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.

Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around?  For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow?  I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level.  I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope.  But it would be really nice if this was working on most CPUs.
215  Bitcoin / Development & Technical Discussion / Escrow on: August 07, 2010, 08:13:52 PM
Here's an outline of the kind of escrow transaction that's possible in software.  This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.

The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.

While this system does not guarantee the parties against loss, it takes the profit out of cheating.

If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.

The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.

Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.
216  Bitcoin / Bitcoin Discussion / Re: A proposal for a semi-automated Escrow mechanism on: August 07, 2010, 08:04:59 PM
Due to that recourse, it is unlikely to be used as an escrow mechanism Smiley
Really?  Do you think people won't be able to understand the benefit?  (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)
217  Bitcoin / Bitcoin Discussion / Re: Bitcoin minting is thermodynamically perverse on: August 07, 2010, 05:46:09 PM
It's the same situation as gold and gold mining.  The marginal cost of gold mining tends to stay near the price of gold.  Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.

I think the case will be the same for Bitcoin.  The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used.  Therefore, not having Bitcoin would be the net waste.

As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to "roll as many dice as posible" within that given time period? The "chain of proof" for coin ownership and transactions doesn't depend on the method for spawning coins.
Each node's influence on the network is proportional to its CPU power.  The only way to show the network how much CPU power you have is to actually use it.

If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it.  IP addresses... much easier to get lots of them than CPUs.

I suppose it might be possible to measure CPU power at certain times.  For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes.  You could still prove your total power at given times without running it all the time.  I'm not sure how that could be implemented though.  There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.

Proof-of-work has the nice property that it can be relayed through untrusted middlemen.  We don't have to worry about a chain of custody of communication.  It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.
218  Bitcoin / Bitcoin Discussion / Re: latency and locality on: August 07, 2010, 04:28:17 PM
Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?
219  Bitcoin / Bitcoin Discussion / Re: A proposal for a semi-automated Escrow mechanism on: August 05, 2010, 06:08:30 PM
A transaction can be written that requires two signatures to spend it next.  You write a payment that requires the signature of both the recipient and the sender to spend it.  To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half.  There's no mediator in this simple case.  The recourse is to refuse to ever release it, essentially burning the money.
220  Bitcoin / Bitcoin Discussion / Re: Flood attack 0.00000001 BC on: August 05, 2010, 05:49:43 PM
Right now the transaction fee address is left "blank" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.  
If you're only going to have one person work on building the block, that could take days.  Oh, do you mean send a different variation to each node with the tx fee written to them?

The way it is now, it's whoever builds this gets it.

If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast.  Relay paying transactions to me, or I won't relay them to you.  It probably won't be an actual problem though.  It only takes one node relaying like it should to cancel out 7 others greedily not relaying.
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!