Bitcoin Forum
December 11, 2016, 12:24:25 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: dsg  (Read 3432 times)
Anonymous
Guest

dsg
May 04, 2010, 07:32:47 PM
 #1

adg
1481459065
Hero Member
*
Offline Offline

Posts: 1481459065

View Profile Personal Message (Offline)

Ignore
1481459065
Reply with quote  #2

1481459065
Report to moderator
1481459065
Hero Member
*
Offline Offline

Posts: 1481459065

View Profile Personal Message (Offline)

Ignore
1481459065
Reply with quote  #2

1481459065
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481459065
Hero Member
*
Offline Offline

Posts: 1481459065

View Profile Personal Message (Offline)

Ignore
1481459065
Reply with quote  #2

1481459065
Report to moderator
dwdollar
Full Member
***
Offline Offline

Activity: 166


View Profile WWW
May 04, 2010, 08:04:59 PM
 #2

Have you seen this?
D҉ataWraith
Member
**
Offline Offline

Activity: 60



View Profile
May 04, 2010, 08:15:26 PM
 #3

Hi! Welcome aboard!

Have you read the FAQ yet? Among other things it has a link to the Bitcoin whitepaper. The minutiae of the protocol and inner workings are, unfortunately, only "documented" in the form of the application's source code.

The basic idea is that coins are signed cryptographically, so you can only spend coins you actually own. To spend a coin you sign it over to someone else using their public key -- the address is a signature of that key and serves to identify it.

To prevent you from making a copy of a coin and spend it twice, the clients form a P2P network that records which coins have already been spent in a long chain that is linked by hashes (see the paper). The IRC channel merely is a relatively simple way to get the IP addresses of a few other participants, so you can join the network.

Apart from recording all transactions, the hash-chain also serves as a sort of distributed clock that makes sure you can't alter past transactions or create many new, bogus ones to DoS the system. To make a new block valid, the clients have to twiddle a nonce inside a block until the block's SHA-256 hash is below a target number. The target number is adjusted about once every two weeks to adapt the difficulty of generating a valid block to the computing power of the network -- basically this ensures that a valid block of transactions is generated about six times per hour, no matter how many or few people are participating.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile
May 06, 2010, 09:51:47 AM
 #4

I suspect the transactions would be delayed as the network grows. But really, will it be any slower than a traditional bank wire? Tongue I think not.

If you need a speedy payment and don't really care about privacy just send an IP to IP payment. They are "instant". You'd still want to wait a few seconds to a minute for enough nodes to see the new IP to IP payment to be sure those coins weren't previously promised to someone else.

The client is supposed to only create 15 connections outbound and allow 15 connections inbound. However, I have seen more connected clients on my nodes. The connection code seems to be very lenient.

Essentially (in my mind at least) I imagine stacks and stacks of 30 connection "rings" that are interconnected to other rings. A payment that happens on a node in the same "ring" you are in is fairly instant but to propagate the data to other rings may take some time. A million nodes (let's just say) would be 33,333 rings that are all interconnected in a random pattern. Is my vision correct or did I just inhale too many paint fumes today? ha!

That's my 2c.. err 2 Bitcoins. Cheesy
Pages: [1]
  Print  
 
Jump to:  

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!