Bitcoin Forum
May 25, 2024, 06:03:15 PM *
News: Latest Bitcoin Core release: 27.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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 »
841  Bitcoin / Bitcoin Discussion / Re: Anonymity and Traceability Review on: July 29, 2010, 05:01:46 PM
Just to say, I currently believe based on reading the spec that everyone will know

1) Sender sent 100 BTC to _random_ip
2) Receiver's address sent 100 BTC to 'new_address'

But that these would not otherwise be correlated. Is this correct?

As far as I know, this is incorrect.

Every bitcoin transaction is mapped to a previous transaction. All transactions are signed by the owner of a particular bitcoin address. They are all traceable though the graph. If you think about it, you will realize that otherwise the system would be easy to spoof.

The send to IP address, simply makes a connection there first and asks it for an appropriate bitcoin address to send to. After that everything is the same as any other transaction. That is why there was a warning of a possible man-in-the-middle attack using Tor or other proxies.

(anyone, please correct me if I'm wrong)
842  Bitcoin / Bitcoin Discussion / BitCoin Parameters on: July 29, 2010, 03:57:03 PM
There are certain constants in BitCoin that could have initially been set to any arbitrary value without conceptual changes to the network. I'm NOT contesting any of these parameter choices as ill conceived. However, there are a lot of curious numbers used in BitCoin and I have no idea why.

I think it would be interesting to document why these choices were made as they seem to be at the heart of many questions that get posted to this forum.

I'll start the list with the parameters I can think of off the top of my head. Please feel free to add to the list.

----------------------------

21,000,000 BTC - Why 21 million and not 10, 16, 20, 25, 32. Just seems like a very particular number that is not divisible by 10 or an obvious power of 2.

2016 - Why does the difficulty adjust every 2016 blocks? Why not 2000, or 2048?

2 weeks - Why does the block adjustment map to a two week period? Why not every week or everyday?

10 minutes - Why do we want to generate a block every 10 minutes? Did this drive the above choices or is it a result of them?



50 BTC - Why a 50 BTC reward for generating a block? Why not 100?  Or Why not a relative value like 0.X BTC for each BTC transaction in a block or even X% of the existing coin base?

4 years - Why does the block reward reset every 4 years? Why not every year or every 5 years? Why does it decrease at all?

1/2 - Why does the block reward diminish by half each time? Why not decrease by 1 or 5 coins?

"Golden years" - Why choose to give out half of all bitcoins to whomever happens to show up in the first 4 years? Why not give out 10% or 100%? Did this drive the above or is it the result of the above?


BitCoin Addresses - Why use the hash of a hash (good idea!) for an address, rather than simply using the full public key.

Certificates - Why not store public keys as part of standard 509 certificates, or in PGP format, The same for private keys.

Time stamps - How do we calculate when in UTC a transaction actually took place? When it was issued from the client, or when confirmed in a block list? Is there a shared consensus on BitCoin standard time?

(Everyone, add what you can think of. Answer what you know.)

843  Bitcoin / Bitcoin Discussion / Re: Network-wide self-corecting mechanisms on: July 29, 2010, 03:23:43 PM
Consider including in the BitCoin protocol some network-wide self-correcting mechanisms. By this I mean that the BitCoin P2P network participants would have to be able to change some of the BitCoin protocol parameters, in their client application.

The only clear idea that I have right now is the maximum amount of BitCoin in circulation.

In most cases, a single person can't change bitcoin parameters unilaterally. That's sort of like saying I use gold for coins, but you choose to use silver. But you want to pretend that both of our coins are the same.

However, everyone could change to a different set of parameters at once if necessary. However, there are reasons each of the parameters was set at its current value. I just don't know what those are.

So I'm going to post that question in a new thread.
844  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 28, 2010, 07:48:33 PM
That is pretty awe inspiring!  You didn't assemble all those machines for this project did you?

Were some of them cloud machines (like amazon ecc?)

I'm hoping you'll give some details on your project soon. I've got some anonymous banking ideas if you want to share.
845  Bitcoin / Bitcoin Discussion / Re: Is Bitcoin that really decentralized, as you believe? on: July 28, 2010, 05:31:16 PM
So who develops the tests?  Wouldn't they become some central authority?

FTW!
846  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 28, 2010, 05:30:24 PM
I can't explain this to you any better.
I can only explain it to you LOUDER.

If you are still unclear on the concepts, you'll have to look to someone else.
847  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 28, 2010, 05:24:33 PM
Oh, really. And you see no difference in the long run between hoarding of very large quantities of $$ and putting them all of fire?
I don't have to see it. Mathematically there is no difference.

This is different with BitCoin, since the system need some coins to operate and their number is limited.
Coins are not limited. You can trade 1/10 of a coin as easily as you can trade 10 coins.

I just was curious about whether someone is able to collect significant amounts of coins.
It seems, that you believe that is not possible, anyway, thanks for your answer and patience dealing with people like me.
It is well known that one person has 10% of all existing coins. Most are being "hoarded" because he is developing a new venture that requires the coins as collateral. If his venture were to fail before it started and he were to "burn" his wallet with 10% of all existing bitcoins. NOBODY WOULD NOTICE! Nobody knew he had the coins until he told us. If he had never told us, the math is no different.

If he decided to sell them all at once the market would notice. But nothing happens if someone takes NO action.

Consider the obvious. By definition the bitcoin system has 21,000,000 BTC of value. Currently 3,500,000'ish is available to circulate if it wants to.

That means that 17,500,000 is being hoarded by the BitCoin reserve to be trickled out over time. It makes no difference if it is being hoarded in a bitcoin address or outside a bitcoin address. (In fact I'd have to examine the code to know for sure.)

If all the users decided that trickling the coins out was stupid and we should put a stop to it. It still wouldn't matter. The system would continue to trade with 3,500,000 total coins rather than 21,000,000.

Absolutely no one would notice, EXCEPT those people who wanted to get bitcoins for free. That is a "social" dynamic, not a monetary dynamic.

848  Bitcoin / Bitcoin Discussion / Re: Is Bitcoin that really decentralized, as you believe? on: July 28, 2010, 04:50:34 PM
I want to point out that I have heard of several existing "alternative implementations" all created by people other than Satoshi.

People have replace the SHA-256 algorithm with a faster one. Made it work on many different operating systems and hardware configurations. Each of these is a separate and equal alternative implementation.

When you create an alternative implementation that doesn't mean you have to start from scratch or understand the details. You could let a C++ to Java or C# translator do most of the work, while you remain oblivious. Others could pick up your work, learn specific parts, make modifications and remain oblivious to the rest of the system.

Now, I'm not against protocol specifications written in an abstract language. Nor am I against regression testing. However, neither is required for BitCoin to become successful.
849  Bitcoin / Development & Technical Discussion / Re: Quantum computer? on: July 28, 2010, 04:40:39 PM
Let's say i have a practicable quantum computer or other device capable of rapid factorization of large enough integers.
What are the consequences to a developed bitcoin network?
Any way it could let me cheat in generation?
Any way it would let me cheat in transactions?

If you had any system, quantum or not, that could solve the discrete logarithm problem, yes, you could generate the private key from any known public key. With that you could steal any coins you want.

However, you could also probably steal most of the Dollars, Euros, Roubles, etc.
850  Bitcoin / Development & Technical Discussion / Re: Scalability and transaction rate on: July 28, 2010, 04:32:06 PM
expecting individuals to "donate time" or make a profit in "bit coin mining" is to arbitrary and leaves little room for innovation. 
...

Effectively, if you want to post a transaction there must be a fee awarded to the individual who gets it posted in a block...

I used to have similar thoughts, but I decided I was wrong. It turns out that BitCoin is peer to peer in the sense that tier-1 internet providers are peer to peer. It is not P2P in the same sense that bittorrent is P2P.

Satoshi points out that he sees the NEED for at most 100,000 nodes verifying transactions and logging blocks. Others would use those nodes in a more client/service fashion. If I was guessing that number I would put it much lower (3<X<100) independent interested parties. Anyone can choose to be one of those X parties, or can choose to validate some or all of the work of those X parties, but only a small number are really REQUIRED.

Because in effect, the entire block list is mostly a distributed notary service. And though that requires rigor, it is not a particularly hard job.

So who would choose to do that job for free?

Knightmb for one. I'm have no doubt that many others like NewLibertyStandard will as well. Why Knightmb specifically? Well he has lots of coins and his business model and personal wealth relies on a well functioning honest system. Without that, his wealth and business simply evaporate. It is altruism and cooperation though self interest.

If you want a real world example consider the internet itself. At its amorphous core are about 7 tier-1 service providers. They are called tier-1 only because each has a mutually self interested "peering agreement" with the other six providers. That means these huge services providers move phenomenal amounts of date back and forth with zero accounting and zero payments among each other. They make all their money by selling their service to NON-tier-1 providers who make their money from selling it to you.

There is nothing to stop anyone from becoming a tier-1 provider. All you have to do is convince the others that it is in their self interest to peer with you. So for a example, Google is thought to pay zero in bandwidth to transmit youtube videos. There is enough traffic both ways, that it is in everyones self-interest to peer with them.

I expect that the same will happen with BitCoin. All the internal accounting and transfers will be free. (with the exclusion of transaction fees meant to avoid spam and mischief). Value will be created at the edges where people exchange bitcoins for something else of value.




851  Bitcoin / Bitcoin Discussion / Re: Using bit coins as negotiable, verifiable, warehouse receipts on: July 28, 2010, 03:35:27 PM
So essentially to achieve what I want may require a breaking change.

Actually I don't think it *requires* making a breaking change. It simply requires making everyone who trades in your "gold coins" a little more rigorous about their behavior. Either that or making the client a little more explicit about when it creates merging transactions.

An example of rigorous would be, the person who bought "gold coins" would have them transfered into a virgin bitcoin address. In your wallet, you could have you client tag that address as "non-merging". Everyone who received them would also do the same thing. In that case, when they are redeemed they would be "untainted".

Should someone inadvertently taint the gold with other coins, they would have to continue trading/redeeming all the tainted coins in one block. In effect, you have to lose the traditional value of the tainting coins to preserve the "gold value" of the tainted ones.


Essentially I want to abstract the unit of transaction because I think that distributed transaction verification is *the killer feature* of bit coin.

I initially thought the same thing. I also noticed that you'd probably want to take into consideration non-fungible vs non-fungible and divisible vs indivisible commodities.



852  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 28, 2010, 03:11:20 PM
So, I can't send coins to a random BitCoin address, so they become blocked forever?
And disintegrated for me.
And that will reduce the volume, that is circulating.
And the total volume is limited, curculating or not.
How much value may he collect over time?

Assigning coins to no one, is exactly equivalent to hoarding them. Which is exactly equivalent to losing your wallet keys.
The result is the same. No one will notice or care. If you are having trouble grasping this

No one knows what coins he has. No one is begging him for them because no one needs them. So if he hoards them or loses them it makes no difference.

Now if he were to spend them, he might have some effect on supply and demand. But NOT SPENDING them can have no effect, the lack of his coins is already priced into the market as they say.
853  Bitcoin / Bitcoin Discussion / Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. on: July 28, 2010, 08:50:29 AM
He may aswell, just disintegrate that bitcoins. Just for fun.
How many bitcoins does he own now?

No one can disintegrate bitcoins even if it were fun. The only thing you can do is decide NOT to spend them. Whoopee! What a blast!

It really doesn't matter how many coins he is NOT circulating. What's important are the ones which are.
854  Bitcoin / Bitcoin Discussion / Re: Is Bitcoin that really decentralized, as you believe? on: July 28, 2010, 08:40:18 AM
You proved a tendency to discuss my person, instead of my words, well...

Your person makes no difference to me. Only your words live here.

And your words either point out what is obvious to even the most casual observer.
1) Everyone is not a developer.
2) The code makes the rules.
3) Therefore, developers of the code make the rules.

No shit Sherlock! That really does go *without* saying.

The rules can change! That is not a revelation. What will be considered a valid transaction in the future is unknown. However, what was a valid transaction in the past cannot change. That is the important thing. And the future rules cannot change if the consensus of users doesn't want them too. If it tries, people just convert their value out of bitcoins using the existing system, and move on to another currency. There is no way to steal the existing bitcoin value by anyone, developer or not.

If there is, you certainly haven't pointed anything out.

In the case where you do say something that is not obvious to everyone, it is generally either misguided or nonsensical.


PS: I haven't found where is the public key and the signatures for binary packages you are distributing via sourceforge.net. I hope they are really buried somewhere deep in the site, but still exists.

I mean really, WTF!
855  Bitcoin / Bitcoin Discussion / Re: Using bit coins as negotiable, verifiable, warehouse receipts on: July 28, 2010, 07:53:07 AM
Is there something about the bitcoin implementation that would prevent this kind of usage?

Yes, but it isn't immediately obvious why.

Technically it could be done without changing any of the shared data structures (the blocks list of transactions). But you would have to assure that the client that generates the transactions doesn't inadvertently "taint" your coins.

So for background, the "transaction history" called the block list, is really a shared directed graph of all valid transactions.
The transactions themselves (nodes), group one or more in-points, and two out-points (edges).
The out-points are *quantities* of bitcoins, assigned to particular bitcoin address. The first out-point is the amount transfered, and the second out-point is any leftover from the sum of the in-points.
A transaction's one or more in-points are simply links back to previous out-points in the transaction list.

Individual bitcoins are not represented as objects, neither are bitcoin addresses. The amount of bitcoins assigned to a given bitcoin address, is simply the summation of the unused out-point values assigned to that address.

(Someone correct me if I've screwed this up!)

So for example, say three people send bitcoins to one of your "bytemaster" bitcoin addresses, in the amounts of 4, 5 & 6 BTC.

Code:
                           [             ]
(4 BTC, "alice")<-- in-1  [Transaction 1] out-1a --> (4 BTC, "bytemaster")
                          [             ] out-1b --> (0 BTC, "alice")

                          [             ]
(9 BTC, "bob"  )<-- in-2  [Transaction 2] out-2a --> (5 BTC, "bytemaster")
                          [             ] out-2b --> (4 BTC, "bob")

(2 BTC, "chuck")<-- in-3a [             ]
(3 BTC, "chuck")<-- in-3b [Transaction 3] out-3a --> (6 BTC, "bytemaster")
(5 BTC, "chuck")<-- in-3c [             ] out-3b --> (4 BTC, "chuck")

The first transaction comes from alice in the about of 4 BTC.  Notice it has 1 in-point and no left over change. This is the simplest type of transaction. I'll call it a "pass-through". One input value and one output value.

The second transaction comes from bob in the amount of 5 BTC. However, bob had previously received 9 BTC from someone else and he only wants to give you 5 BTC of that. So he sends the remaining 4 BTC back to himself. Notice the input quantity must equal the output quantity. I'll call this type of transaction a "fork". Because it has one input value and two output values.

The third transaction comes from chuck in the amount of 6 BTC. However, he has previously only received small amounts of bitcoins, so he doesn't have enough value in any previous out-point to transfer to you. So his transaction gathers value from several previous out-points. I'll call this type of transaction a "merge", because of its multiple inputs.

-----

What you want to do is to create some "gold bitcoins" that you can identify as different from regular old bitcoins but others wouldn't. This is logically possible to do with bitcoin as is. The simplest case would be a series of pass-through transactions.

Code:
(5 BTC, "gold" )<-- in-4  [Transaction 4] out-4a --> (5 BTC, "bytemaster")<-- in-5  [Transaction 5] out-5a --> (5 BTC, "vendor")<-- in-6  [Transaction 6] out-6a --> (5 BTC, "gold-redeemer")

In this case, the "gold-redeemer" could easily see that the value originated as "gold"

However, if someone was to send some regular bitcoins to the same address at you or a future owner uses for the gold, it is possible that the "gold bitcoins" can become "tained" by the regular coins in a merge transaction.

As far as I know, in the current bitcoin client, you do not have fine grained control over this. For example your client might merge the coins from alice in with the gold coins. This makes it impossible to decide where the gold is down the line.

Code:
(4 BTC, "alice")<-- in-1  [Transaction 1] out-1a --> (4 BTC, "bytemaster")<-- in-5a [Transaction 5] out-5a --> (5 BTC, "vendor") <-- in-6  [Transaction 6] out-6a --> (5 BTC, "gold-redeemer")
(5 BTC, "gold" )<-- in-4  [Transaction 4] out-4a --> (5 BTC, "bytemaster")<-- in-5b [             ] out-5b --> (4 BTC, "bytemaster") <-- in-7  [Transaction 7] out-7a --> (4 BTC, "gold-redeemer")

In this case "gold-redeemer" has received 9 coins but can tell that only 5 "gold coins" were issued. It is ambiguous who to return the gold value to.

So for your needs, pass-through and fork transactions would be OK. You could merge coins if they were all "gold coins" but if you or someone else inadvertently merges in regular coins, all that gold becomes tainted.
856  Bitcoin / Bitcoin Discussion / Re: Using bit coins as negotiable, verifiable, warehouse receipts on: July 28, 2010, 05:28:27 AM
Check out Loom.

That's interesting! Thanks for the reference.
857  Bitcoin / Development & Technical Discussion / Re: Possible Feature Request - Always have a way to find BitCoin Address when receiv on: July 28, 2010, 04:55:06 AM
If you send payment direct from IP to IP, the BitCoin address is recorded somewhere right?

If not, then a feature request would be way to find out (maybe when you double-click the transaction, it brings up a summary screen, maybe include that in the summary screen)

Feedback welcome or if someone knows where this info is and I'm not finding it.  Grin

It has to be in the transaction recorded in the block list by definition. Maybe those fancy python tools for examining transactions would help?

http://github.com/gavinandresen/bitcointools

And just for my own benefit, is this the best way to examine the block list's transaction history at the moment? Or is there something I'm missing?
858  Economy / Trading Discussion / Re: Money Transfer Regulations on: July 27, 2010, 06:05:53 PM
Bytemaster: I had a similar ideal. It turns out the major limiting factor is that coins are not actually serialized or represented in any way. Only exchanges of fungible value are represented.

It quickly becomes impossible to identify your particular backed coins unless special care is taken. I was going to write a post on this, but instead I wrote the one on coin collecting in the marketplace forum.

If you want create a new topic and we can all discuss "non-fungible" bitcoins.
859  Economy / Economics / Re: Bitcoin does NOT violate Mises' Regression Theorem on: July 27, 2010, 04:26:34 AM
Yes, quite an impressive analysis! Alas I have no coins to send.

Why is there no PPC build for the Mac? I really need new hardware.
860  Economy / Marketplace / Re: Coin Collecting on: July 27, 2010, 03:54:43 AM
Better yet, have them give you the private key to the address that generated them/has them.  Then they will be even fresher because they won't have that last transaction fo them being sent to you!

Actually, that is a really cool concept to ponder.

I hadn't thought of the fact that Satoshi has the private key to the genesis block! He has incontrovertible proof that he kicked this whole thing off! I doubt he'll part with that key. He'll probably pass it down to his kids.

It would be cool to own that address with some of the original coins in it!

(Shit, now I'll never get any! :-))
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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!