Bitcoin Forum
May 08, 2024, 10:23:52 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin Tech Talk  (Read 1992 times)
Theo (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0



View Profile
June 20, 2011, 11:13:24 PM
 #1

Hi,

I'm holding a talk about Bitcoin in a couple of days. Target audience are computer scientists and it's focused on technology.

http://dl.dropbox.com/u/212148/bitcoin-talk.pdf

Any corrections appreciated.
I'm also preparing some backup slides about recent hacks, Namecoin and why non-scalability isn't the end of the world.

Regards,
Theo
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715207032
Hero Member
*
Offline Offline

Posts: 1715207032

View Profile Personal Message (Offline)

Ignore
1715207032
Reply with quote  #2

1715207032
Report to moderator
1715207032
Hero Member
*
Offline Offline

Posts: 1715207032

View Profile Personal Message (Offline)

Ignore
1715207032
Reply with quote  #2

1715207032
Report to moderator
1715207032
Hero Member
*
Offline Offline

Posts: 1715207032

View Profile Personal Message (Offline)

Ignore
1715207032
Reply with quote  #2

1715207032
Report to moderator
just_someguy
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
June 20, 2011, 11:43:27 PM
 #2

Very nice!

Its hard to judge slides because its just the bullets without context.
Two things I noticed which you may already be addressing in the talk:

"Apart from securing Bitcoin, the energy is wasted"
Is there another way to phrase that?

Also, in the part about scalability you don't mentioned the simple mode clients using just 4.5 MB a year.
Then it says bitcoin doesn't scale with the number of transactions.
Not exactly sure what that means but if it makes sense in context its all good.

Looks like its going to be a great presentation!
tubro
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
June 21, 2011, 03:11:45 PM
 #3

Good work, I like it. Make sure you have a lot of time for all those slides, though. Calculate 4min/slide.
Sukrim
Legendary
*
Offline Offline

Activity: 2618
Merit: 1006


View Profile
June 21, 2011, 06:16:26 PM
 #4

You DID read + understand https://en.bitcoin.it/wiki/Scalability - right?

https://www.coinlend.org <-- automated lending at various exchanges.
https://www.bitfinex.com <-- Trade BTC for other currencies and vice versa.
Theo (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0



View Profile
June 22, 2011, 08:55:37 AM
 #5

Thanks for your feedback!

Regarding scalability I say basically the same as the Wiki page does: scalability is limited and there are ideas to improve it in future.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4172
Merit: 8418



View Profile WWW
June 22, 2011, 06:28:38 PM
Last edit: June 22, 2011, 09:59:09 PM by gmaxwell
 #6

"Apart from securing Bitcoin, the energy is wasted"
Is there another way to phrase that?

Yea, thats unfairly negative.

"Mining gold takes energy, apart from increasing the supply of gold, most of which will simply be locked away in vaults, the energy is wasted"

"Validating and transporting cash takes energy, apart from discouraging counterfeiting and moving the cash from place to place, the energy is wasted"

People complaining about bitcoin's energy usage are ignoring the externalized (and thus hidden) energy costs in the alternatives.  Perhaps bitcoin is worse right now given the low amount of economic activity, but its nowhere near as bad as a simplistic analysis would make it sound.

Ob pedantry:  The 21M limit comes not from the quantization limit at 1e-8, it arises as the limit of the geometric series.  If the bitcoin precision is increased the total number of bitcoins will not go past that limit.

You're also overstating the current blockchain size.  The client keeps orphan forks that it heard about plus a number of excessively bloated indexes. The blocks themselves are in blk0001.dat.  On client I bootstrapped a few weeks ago (so it has some amount of dead forks in it already) is 285MBytes.

The blockchain can also be significantly compressed because almost all txn use the same script and because public keys in signed transactions can be reliably derived from the signature. (It's not clear that Satoshi knew this, but even so— it takes a bit more computation to validate without the public key.) Just running a simple compression on it that doesn't take advantage of the ability to recover public keys shrinks the file to 190MBytes.
Theo (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0



View Profile
June 22, 2011, 08:21:51 PM
 #7

Yeah, the word "wasted" is too judging, I will change that to something neutral.

Ob pedantry:  The 21M limit comes not from the quantization limit at 1e-8, it arises as the limit of the geometric series.  If the bitcoin precision is increased the total number of bitcoins will not go past that limit.

Ok right.

You're also overstating the current blockchain size.  The client keeps orphan forks that it heard about plus a number of excessively bloated indexes. The blocks themselves are in blk0001.dat.  On client I bootstrapped a few weeks ago (so it has some amount of dead forks in it already) is 285MBytes.

Interesting, I assumed orphan forks are removed when main chain matures.

The blockchain can also be significantly compressed because almost all txn use the same script and because public keys in signed transactions can be reliably derived from the signature. (It's not clear that Satoshi knew this, but even so— it takes a bit more computation to validate without the public key.) Just running a simple compression on it that doesn't take advantage of the ability to recover public keys shrinks the file to 190MBytes.

You really mean derive the public key solely from the signature? Do you have additional information on that?
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4172
Merit: 8418



View Profile WWW
June 22, 2011, 10:11:33 PM
Last edit: June 23, 2011, 01:13:45 AM by gmaxwell
 #8

Interesting, I assumed orphan forks are removed when main chain matures.

Could be, should be, but isn't right now. The actual blockchain file is a dumb blob of bytes. The BDB file store offsets into that file. Pruning it would require atomic operations which cover both, or building a separate file and switching.... or putting it all in the database, which I assume is not done for performance/space reasons.

Quote
You really mean derive the public key solely from the signature? Do you have additional information on that?

Not quite solely: You need to know something to tell if its the right key— otherwise you'd just accept any signature!  Fortunately, the transaction already provides the address, and we're already using the address to determine if the public key is the right one.

Page 48 of http://www.secg.org/download/aid-780/sec1-v2.pdf describes how to do key recovery, see step 1.6.1.  Note that there can be two possible public keys, but I don't think this creates a security issue because if someone can find a case where both candidates hash to the same address then they can already cause trouble with our current system.
Edit: I was corrected that it's up to four possible matching public keys
Theo (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0



View Profile
June 22, 2011, 10:48:11 PM
 #9

Thanks, I'll take a look at it.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4172
Merit: 8418



View Profile WWW
June 23, 2011, 07:55:31 AM
 #10

Thanks, I'll take a look at it.

Looking at your slides again I see you say no backup in .23— but the bitcoin has had the backupwallet RPC for some time now.  Is this not exposed in the gui?

I have a cron job that uses backupwallet + gpgs to do offsite backups daily. Works great.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!