Skip to content

IPv6 support #427

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

IPv6 support #427

wants to merge 2 commits into from

Conversation

sipa
Copy link
Member

@sipa sipa commented Jul 24, 2011

This commit introduces IPv6 support (selectable at compile time),

General changes (even when IPv6 support is not compiled in):

  • Valid, routable IPv6 addresses are stored and forwarded
  • Name lookups are done using the general getaddrinfo() call
  • The detection system for the local address is improved. (addresses are classified according to their 'reachability', and the most reachable local address encountered is used).
  • The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
    • IPv4 addresses are grouped in /16 blocks
    • IPv6 addresses are grouped in /32 blocks
    • Tunneled IPv6 addresses use the encapsulated IPv4 address (teredo, 6to4, SIIT, well-known prefix)
  • Hostnames can be given using the "[host]:port" format.
  • Support for the "checkorder" message was removed (obsolete, and not worth porting)

Behaviour changes when IPv6 support is enabled:

  • DNS lookups also return IPv6 matches
  • The listening socket is bound to the IPv6 ANY address (::/128) instead of the IPv4 ANY address (0.0.0.0)
  • Connections to non-IPv4 addresses are attempted, using IPv6 sockets (connections to IPv4 addresses still use IPv4 sockets)
  • A local IPv6 address is used instead of an IPv4 one if no routable IPv4 address is available. In this case, it is not advertized through IRC (obsolete).

For internal changes, see the commit message.

Possible future improvements:

  • Some pruning/ageing of addr.dat
  • Cmdline/config options to modify IPv6 behaviour (eg. IPv6-only connection slots, preference for IPv6 connections, ...)
  • Intelligent choice of nodes to download initial chain from (avoid Teredo tunnels eg.)

@sipa
Copy link
Member Author

sipa commented Jul 24, 2011

A simple "-connect=[ipv6address]" test was succesful on Ubuntu, OSX and Win7 (mingw build). Incoming connections are only tested on Ubuntu now.

A test IPv6 node is running on 2a02:348:5e:5a29::1, with 16 connection slots reserved for IPv6 connections.

@TheBlueMatt
Copy link
Contributor

Been discussing some alternate connection logic and anti-DDoS stuff wrt filling addr.dat on IRC, just something that needs done first.

sipa added 2 commits July 26, 2011 19:56
@sipa
IPv6 support
027134d 
This commit introduces IPv6 support (selectable at compile time),

General changes (even when IPv6 support is not compiled in):
* Valid, routable IPv6 addresses are stored and forwarded
* Name lookups are done using the general getaddrinfo() call
* The detection system for the local address is improved.
  (addresses are classified according to their 'reachability',
  and the most reachable local address encountered is used).
* The rule that no two connections to addresses within the same
  /16 should be attempted, was generalized by defining address
  groups:
  * IPv4 addresses are grouped in /16 blocks
  * IPv6 addresses are grouped in /32 blocks
  * Tunneled IPv6 addresses use the encapsulated IPv4 address
    (teredo, 6to4, SIIT, well-known prefix)
* Hostnames can be given using the "[host]:port" format.
* Support for the "checkorder" message was removed (obsolete,
  and not worth porting)

Behaviour changes when IPv6 support is enabled:
* DNS lookups also return IPv6 matches
* The listening socket is bound to the IPv6 ANY address (::/128)
  instead of the IPv4 ANY address (0.0.0.0)
* Connections to non-IPv4 addresses are attempted, using IPv6
  sockets (connections to IPv4 addresses still use IPv4 sockets)
* A local IPv6 address is used instead of an IPv4 one if no
  routable IPv4 address is available. In this case, it is not
  advertized through IRC (obsolete).

Internal changes:
* CAddress's "ip" and "port" fields are made private. To inspect them,
  use GetSockAddrIPv4(), GetSockAddrIPv6() and GetPort().
* CAddress's "vchReserved" field was removed, in favor of a full
  16-byte "ip" field. The serialized format is unchanged.
* The IsLocal() and IsRoutable() calls have been extended to
  support IPv6 address classes (including documentation IP's, private
  networks, auto configuration, and unique local addresses)
* IP addresses are never passed as ints anymore, but as CAddresses.
* No IRC nickname format is defined for IPv6 - IPv6 addresses are
  expected to be propagated using DNS seeding and the P2P network.

Inspired by Luke Dashjr's earlier IPv6 patch.
@sipa
multilocal
aac5b52
@T-X
Copy link

T-X commented Nov 10, 2011

@TheBlueMatt: Would you mind summarizing the results of your discussion back then here? I'm afraid that they might get lost otherwise, as no one seems to be working on them at the moment.

@TheBlueMatt
Copy link
Contributor

Here are the IRC logs I have for that night (sorry, I dont feel like going through and actually parsing this):

**** BEGIN LOGGING AT Sat Jul 23 22:53:17 2011
Jul 23 22:53:17 * Now talking on #bitcoin-dev
Jul 23 22:53:17 * Topic for #bitcoin-dev is: Main: http://bitcoin.org/ | Wiki: https://en.bitcoin.it/wiki/ | Latest version: 0.3.24 | Bitcoin Development - We're here to help develop the Bitcoin system. All related discussions are welcome. | If you have a question, simply ask and wait for a reply. | Main support/discussion chan #bitcoin | Public channel logs: http://bit.ly/iPFi3X
Jul 23 22:53:17 * Topic for #bitcoin-dev set by BlueMatt!~matt@unaffiliated/bluematt at Fri Jul 8 23:41:38 2011
Jul 23 22:53:17 * gribble gives channel operator status to BlueMatt
Jul 23 22:55:35 * asuk (~asuk@178.140.168.101) has left #bitcoin-dev
Jul 23 22:55:53 * asuk (~asuk@178.140.168.101) has joined #bitcoin-dev
Jul 23 22:56:24 * gary2113 (~xcht@abgf165.neoplus.adsl.tpnet.pl) has joined #bitcoin-dev
Jul 23 23:01:09 * asuk_ (~asuk@178.140.168.101) has joined #bitcoin-dev
Jul 23 23:01:58 * asuk_ has quit (Client Quit)
Jul 23 23:02:41 * wardearia has quit (Ping timeout: 240 seconds)
Jul 23 23:09:05 * asuk_ (~asuk@178.140.168.101) has joined #bitcoin-dev
Jul 23 23:09:14 * datagutt has quit (Quit: Computer has gone to sleep.)
Jul 23 23:10:07 sipa: this is on win7
Jul 23 23:10:22 had a vm lying around
Jul 23 23:10:32 define "works" ? :)
Jul 23 23:11:22 it connects and starts downloading blocks over ipv6?
Jul 23 23:11:29 yes
Jul 23 23:11:46 and checked that netstat shows the ipv6 connection
Jul 23 23:11:57 * sipa does happy dance and pull request
Jul 23 23:12:04 :)
Jul 23 23:12:07 <b4epoche_> great!
Jul 23 23:12:39 sipa: do you want to try to connect to me?
Jul 23 23:13:07 maybe some logic that finds local ipv6 addresses if no ipv4 ones are available
Jul 23 23:13:19 devrandom: not now
Jul 23 23:13:42 sipa: before you pull req one of the dnsseeds needs ipv6 addresses
Jul 23 23:15:58 sipa: ok
Jul 23 23:17:47 * asuk_ has quit (Quit: leaving)
Jul 23 23:18:48 * wardearia (~necro@unaffiliated/necrodearia) has joined #bitcoin-dev
Jul 23 23:19:27 * groffer has quit (Quit: leaving)
Jul 23 23:20:13 libbitcoin: genjix * r82c48a8ec63e /LICENSE: removed address.
Jul 23 23:20:21 * nhodges has quit (Ping timeout: 250 seconds)
Jul 23 23:21:17 * lolwat(~lolwat@c-24-61-9-77.hsd1.ma.comcast.net) has joined #bitcoin-dev Jul 23 23:21:55 <sipa> devrandom: ok, i'm compiling bitcoin-ipv6 on my laptop now Jul 23 23:22:27 * senseles has quit (Ping timeout: 240 seconds) Jul 23 23:22:45 * danbri has quit (Read error: Connection timed out) Jul 23 23:23:17 * jargon has quit (Ping timeout: 246 seconds) Jul 23 23:23:32 * danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) has joined #bitcoin-dev Jul 23 23:24:09 * genjix (~genjix@bitcoinconsultancy.com) has left #bitcoin-dev Jul 23 23:25:53 <lolwat> gmaxwell do you have a particular image you are fond of that can be my first upload experiment
Jul 23 23:27:53 image?
Jul 23 23:27:58 how about sony's keys?
Jul 23 23:28:09 that's not pd
Jul 23 23:29:13 That is a serious issue though and you will have problems, I don't care what the lawyers say, when someone announces "When you download bitcoin you're downloading pedophiles" that is going to throw a wet blanket on it for a lot of people.
Jul 23 23:30:11 libbitcoin: genjix * r98bd3266da00 / (10 files in 6 dirs): proactor based API for storage module.
Jul 23 23:30:28 anyone happen to know what the unit "sm" is when refering to airplane range?
Jul 23 23:31:48 sipa: sorry, the words PROTECTION_LEVEL are not in any of the mingw32 / mingw32-runtime headers
Jul 23 23:32:24 devrandom: i feared so...
Jul 23 23:33:09 * nhodges (~r1x1us@gateway/tor-sasl/r1x1us) has joined #bitcoin-dev
Jul 23 23:34:31 sipa: isn't he.net's tunnels all on one /32?
Jul 23 23:34:39 so you can only connect to one person on he?
Jul 23 23:34:45 seems bad
Jul 23 23:34:45 ;p
Jul 23 23:34:57 * pusle has quit ()
Jul 23 23:36:47 sipa: you can try hardcoding based on the numbers in the MS kb article
Jul 23 23:36:53 * TheZimm has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
Jul 23 23:37:03 jrmithdobbs: what is he.net ?
Jul 23 23:38:31 jrmithdobbs: ok, a tunnel broker
Jul 23 23:38:36 not a
Jul 23 23:38:38 the
Jul 23 23:38:53 something like 60%+ of non-isp ipv6 goes through them
Jul 23 23:38:55 yeah seriously other tunnel providers are terrible
Jul 23 23:39:11 think it's more like 80%+
Jul 23 23:39:29 ok, that warrants an exception case, i guess
Jul 23 23:39:41 ya that's why i brought it up
Jul 23 23:40:18 2001:470:
Jul 23 23:40:21 that's their prefix
Jul 23 23:40:37 iirc everything after that is user specific
Jul 23 23:44:15 don't think so
Jul 23 23:44:30 * viggi has quit (Read error: Connection reset by peer)
Jul 23 23:44:31 that is the whole of HE.net netblock :D
Jul 23 23:44:40 not only the tunnel part
Jul 23 23:44:42 hmm
Jul 23 23:44:49 2001:470:1f05:848::2
Jul 23 23:45:08 i've seen tunnel addresses with out 1f05
Jul 23 23:45:39 * TheZimm (~TheZimm@c-98-226-5-69.hsd1.il.comcast.net) has joined #bitcoin-dev
Jul 23 23:45:54 2001:470:1f05: 2001:470:1f04:
Jul 23 23:46:03 the 2 sides of the tunnel
Jul 23 23:46:13 yeah they give /64's and /48's out of different prefixes
Jul 23 23:46:14 so yeah i think they randomly assign you something in 2001:470:
Jul 23 23:46:28 but 2001:470:: is their whole block
Jul 23 23:46:34 in 2011:740::/32 ?
Jul 23 23:46:38 what i'm saying is, they do a lot more than only tunnels
Jul 23 23:46:44 yeah i think they give you random parts of their netblock
Jul 23 23:46:55 * asuk (~asuk@178.140.168.101) has left #bitcoin-dev
Jul 23 23:47:00 so, when the address matches 2011:470::/32, i'll group per /48
Jul 23 23:47:07 * asuk (~asuk@178.140.168.101) has joined #bitcoin-dev
Jul 23 23:47:12 or maybe per /40
Jul 23 23:47:33 i can never remember my ip
Jul 23 23:48:12 er
Jul 23 23:48:13 password
Jul 23 23:48:15 cjdelisle: is illegal data in the blockchain really a problem? I mean, every one who doesn't want that on their system can just drop the transaction from the block, only keep the hash.
Jul 23 23:48:41 * MrTiggr has quit (Ping timeout: 240 seconds)
Jul 23 23:48:56 * thefinn93 (~finn@c-98-246-75-245.hsd1.or.comcast.net) has joined #bitcoin-dev
Jul 23 23:49:18 * MrTiggr (~MrTiggr@220-253-188-225.NSW.netspace.net.au) has joined #bitcoin-dev
Jul 23 23:49:32 * viggi (~viggi@unaffiliated/viggi) has joined #bitcoin-dev
Jul 23 23:49:33 sipa: i've got two /48s in the same /32 and 2 /64s in the same /32 (different /32 from the /48s)
Jul 23 23:49:39 sipa: without registering more than one account
Jul 23 23:50:15 but there is only one /32 ?
Jul 23 23:50:28 no, looks like i was wrong on that
Jul 23 23:51:05 there's multiple /32s but they assign multiple accounts out of each
Jul 23 23:51:10 not sure how randomized it is
Jul 23 23:51:18 i'm not following
Jul 23 23:51:33 2001:470:1f0f:9a2::/64 2001:470:b827::/48
Jul 23 23:51:41 those are in the same /32
Jul 23 23:51:41 2001:470:1f0f:a2a::/64 2001:470:bad0::/48
Jul 23 23:51:45 * thefinn93 (~finn@c-98-246-75-245.hsd1.or.comcast.net) has left #bitcoin-dev
Jul 23 23:51:49 all in the same /32
Jul 23 23:52:24 yes ffs
Jul 23 23:52:25 Hurricane Electric, Inc. HURRICANE-IPV6 (NET6-2001-470-1) 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Jul 23 23:52:42 upb: thanks, that concludes it :)
Jul 23 23:55:10 lol this is a shit calculator
Jul 23 23:55:11 2001:470:b827:: is not a valid IPv6 or IPv4 network address.
Jul 23 23:55:17 is too
Jul 23 23:55:54 what said that?
Jul 23 23:56:00 * Prof_BiG_BanG has quit (Ping timeout: 252 seconds)
Jul 23 23:56:05 http://www.ipv6calculator.net/
Jul 23 23:56:06 lol
Jul 23 23:56:07 it's "not usable" though; ::0 is the all-router anycast address
Jul 23 23:56:19 Dagger2: stil valid
Jul 23 23:57:29 Dagger2: and it says the same thing adding 1 to the end which is most def valid and usable ;p
Jul 23 23:58:20 clearly what it actually wants is a subnet
Jul 23 23:58:53 i'm using ::0
Jul 23 23:58:56 Dagger2: without the /* /128 is implied
Jul 23 23:59:55 sipa: those are all in diff /40s btw

Jul 24 00:00:36 and under my control (and 1 more /64 and /48 could be which would also be in diff /40s ... without multiple accounts)
Jul 24 00:00:51 so maybe /39?
Jul 24 00:00:58 JFK911: hence the quotes... so am I, but it's supposed to be used by all routers on the link, or something along those lines
Jul 24 00:01:05 Eliel: If you drop a transaction and you don't at least keep it's inputs then you don't know that it wasn't part of a doublespending scheme.
Jul 24 00:01:09 heh
Jul 24 00:02:00 cjdelisle: oh yeah, you also need to mark that transaction's input as spent somewhere.
Jul 24 00:03:20 sipcalc is pretty good
Jul 24 00:03:46 sipa: preventing sybil with v6 is hard
Jul 24 00:04:11 yes
Jul 24 00:04:21 sipa: also, did you add addr.dat pruning and make all the addr's not stored in memory?
Jul 24 00:04:28 because imho it shouldn't be merged to master until that's done
Jul 24 00:05:06 also fix the "store every timestamp we ever receive forever in memory until we restart" thing
Jul 24 00:05:27 fuck just dump addr.dat
Jul 24 00:05:28 or you can memory exhaust any node with a /48
Jul 24 00:05:38 * p0s has quit (Remote host closed the connection)
Jul 24 00:05:45 actually ill add timestamps to it
Jul 24 00:05:47 jrmithdobbs: good point
Jul 24 00:08:17 * Spleenie_ is now known as kish Jul 24 00:08:28 <prof7bit> in my client i'm currently storing the latest 2000 IP addresses (newest timestamps) on disk (not in RAM) and on restart I seed and on client restart I try random entries from this DB with very short connection timeout until it succeeds. Jul 24 00:08:35 * asuk has quit (Quit: leaving) Jul 24 00:08:38 * gary2113 has quit (Quit: Leaving) Jul 24 00:09:04 <sipa> that's probably a better scheme already Jul 24 00:09:11 <prof7bit> on estart i seed with additional ips from DNS and then use random numbers (from the seed and the db) Jul 24 00:09:16 <jrmithdobbs> you almost have to dump addr.dat completely to do ipv6 safely Jul 24 00:09:19 <jrmithdobbs> in a non-dosable way Jul 24 00:09:21 * genjix (~genjix@bitcoinconsultancy.com) has joined #bitcoin-dev Jul 24 00:09:24 <genjix> https://en.bitcoin.it/wiki/OP_CHECKSIG Jul 24 00:09:29 <genjix> step 2 under how it works Jul 24 00:09:33 <genjix> i think that's wrong Jul 24 00:09:53 <genjix> it goes from the *last* OP_CODESEPERATOR, not the first Jul 24 00:09:57 * sanity has quit (Ping timeout: 252 seconds) Jul 24 00:10:01 <genjix> unless i'm misunderstanding most recent Jul 24 00:10:20 <prof7bit> for storage I use a simple dBase 3 file with timestamp and address indexes, address is IPV6 and port Jul 24 00:10:22 <jrmithdobbs> most recent parsed Jul 24 00:10:28 <jrmithdobbs> so ya last Jul 24 00:10:28 <lolwat> most recent when you execute OP_CHECKSIG
Jul 24 00:10:34 <lolwat> which would be the last Jul 24 00:10:35 <genjix> k, well im going to reword that. Jul 24 00:10:44 <jrmithdobbs> just add the word parsed Jul 24 00:10:45 <jrmithdobbs> ;p Jul 24 00:11:34 <genjix> ok Jul 24 00:12:38 <lolwat> does vinced or anyone who did merged mining ever come in her
Jul 24 00:12:42 <lolwat> here Jul 24 00:13:33 <cjdelisle> AFAIK vinced did not implement merged mining Jul 24 00:13:36 \* asuk (~asuk@178.140.168.101) has joined #bitcoin-dev Jul 24 00:14:08 <prof7bit> when a new address comes in then the oldest one is deleted from the db (i move the cursor to it and overwrite with new address) Jul 24 00:14:38 <prof7bit> is extremely fast. Jul 24 00:14:51 <prof7bit> although 2 indexes must update Jul 24 00:15:35 <genjix> is this wrong too? https://en.bitcoin.it/wiki/Protocol_specification#Addresses Jul 24 00:15:50 <genjix> checksum = first 4 bytes of sha256 hash Jul 24 00:15:58 <genjix> well ssl gives the sha's backwards Jul 24 00:16:13 <prof7bit> maybe 2000 is even too much. in my experimemts i could connect alone from the DNS seed to 10 client in less than 10 seconds Jul 24 00:16:15 <genjix> so technically it's the last 4 bytes, no? Jul 24 00:16:52 <sipa> genjix: depends on how you look at it, i guess Jul 24 00:16:55 <genjix> especially since when we talk about hashes in bitcoin we use the reversed format Jul 24 00:17:07 <genjix> i.e the 0's in blocks come at the start not the end Jul 24 00:17:12 <sipa> "first" and "last" are almost everywhere ambiguous anyway Jul 24 00:17:22 <prof7bit> first 4 as they come from openssl Jul 24 00:17:34 \* amiller (~amiller@gateway/tor-sasl/socrates1024) has joined #bitcoin-dev Jul 24 00:17:49 <sacarlson> lolwat: I'm in the process of learning about merged mining
Jul 24 00:18:35 <lolwat> im trying to understand if there may be a way to do it obliviously to the miners Jul 24 00:18:57 <lolwat> http://forum.bitcoin.org/index.php?topic=31111.0
Jul 24 00:19:11 <lolwat> merged mining as now is pretty simple Jul 24 00:19:24 <lolwat> stick a hash of w/e you want to verify (e.g. namecoin block header) in the coinbase
Jul 24 00:19:36 lolwat: it would seem to be simple but I have as yet been able to setup a proto type with it Jul 24 00:19:53 <lolwat> it would be nice if there were a way to do it without needing to store in coinbase, where it could be stored anywhere
Jul 24 00:20:01 jrmithdobbs: if all your tunnels are in separate /40's, isn't /39's too large still as well?
Jul 24 00:20:12 jrmithdobbs: and shouldn't you use something like /56
Jul 24 00:20:18 /36
Jul 24 00:20:34 * E-sense (~e-sense@87-126-81-126.btc-net.bg) has joined #bitcoin-dev
Jul 24 00:21:39 * Incitatus (~fluantox@38.121.228.2) has joined #bitcoin-dev
Jul 24 00:22:33 lolwat: I'm also not sure if the added lag to publish on the parant chain would add to the cost if someone was to get a solution published before you Jul 24 00:23:03 <lolwat> sacarlson, ?
Jul 24 00:23:38 lolwat: for merge mining you pass through the proxy that must add some time but maybe very little Jul 24 00:23:53 * MrTiggr has quit (Ping timeout: 252 seconds) Jul 24 00:24:00 * MrTiggr (~MrTiggr@220-253-182-92.NSW.netspace.net.au) has joined #bitcoin-dev Jul 24 00:24:00 <lolwat> i mean
Jul 24 00:24:14 <lolwat> that lag is totally negligible if your world is based on a 10 minute clock tick anyway Jul 24 00:25:20 <sacarlson> lolwat: I'm not sure it's a race many to find the first solution so when you arive at it I'm not sure how long it would be if you weren't the one to have found it
Jul 24 00:25:26 sacarlson: Congrats on the multicoin stuff, that is really neat work.
Jul 24 00:26:10 cjdelisle: It's not really much of my work its just pulled together work of others
Jul 24 00:26:10 sipa: they're actually in two different /33s
Jul 24 00:26:17 sipa: (total between the 4)
Jul 24 00:26:21 sipa: hmm
Jul 24 00:26:47 * sanity (~sanity@66-90-216-120.dyn.grandenetworks.net) has joined #bitcoin-dev
Jul 24 00:27:53 <lolwat> sacarlson, I don't understand... Jul 24 00:27:56 \* Teslah has quit (Ping timeout: 260 seconds) Jul 24 00:29:13 <sacarlson> lolwat: for one thing I don't know the time lag since I don't have a working model yet. if the time is very small then it should cost nothing
Jul 24 00:29:25 * Incitatus has quit (Quit: Leaving)
Jul 24 00:29:30 <lolwat> time lag for what precisely Jul 24 00:30:11 <sacarlson> lolwat: when you come to a solution you must be the first to publish it as being the new solution correct?
Jul 24 00:30:18 i.e the 0's in blocks come at the start not the end <--- endianness can be a never ending source of confusion. 0's at the start would be big endian.
Jul 24 00:30:44 sacarlson: no
Jul 24 00:30:51 sacarlson: lowest hash wins
Jul 24 00:31:03 yes
Jul 24 00:31:11 jrmithdobbs: oh I didn't know that
Jul 24 00:31:33 <lolwat> jrmithdobbs, where is that logic? I didn't know about any testing of the hash below if it's below target Jul 24 00:31:35 <prof7bit> and the 0's are the high bytes Jul 24 00:31:42 \* denisx has quit (Quit: denisx) Jul 24 00:31:46 <lolwat> beyond if its below target *
Jul 24 00:31:49 and high bytes at the start is BIG endian
Jul 24 00:31:59 lolwat: reorg/longest chain code Jul 24 00:32:04 <sacarlson> jrmithdobbs: ya I think your right even if someone came to a new solution it would just become the next in the chain Jul 24 00:32:12 <jrmithdobbs> no Jul 24 00:32:18 * Diablo-D3 (~diablo@68.238.55.43) has joined #bitcoin-dev Jul 24 00:32:28 <jrmithdobbs> it would replace yours if it was lower or be ignored if it wasn't Jul 24 00:32:33 <jrmithdobbs> it has the same "parent" block Jul 24 00:32:36 <prof7bit> (like written in arabic numerals) little endian is higher bytes to the right (end) Jul 24 00:32:36 <jrmithdobbs> so it can't be after your block Jul 24 00:32:57 * spiky (~spiky@p4FD9AC11.dip.t-dialin.net) has joined #bitcoin-dev Jul 24 00:33:05 <prof7bit> like i said it can be a source of confusion Jul 24 00:33:22 * spiky is now known as Guest6204 Jul 24 00:33:23 <sacarlson> jrmithdobbs: yes sorry correct assuming it was a tie other wise everyone would start working on the new solution for that added chain Jul 24 00:33:51 <jrmithdobbs> sacarlson: if it was a "tie" said tie would be broken by whichever was considered the parent for the next found and broadcast Jul 24 00:33:59 <prof7bit> the bits that count lowest come first in little endian (and last in big endian) Jul 24 00:34:33 * Titeuf_87 has quit (Ping timeout: 255 seconds) Jul 24 00:34:36 <jrmithdobbs> and the odds of two independent miners "tieing" on the hash value is so astronomical to be impossible for all intents and purposes Jul 24 00:34:54 <lolwat> jrmithdobbs, I don't see it? Reorganize in main.cpp?
Jul 24 00:35:03 jrmithdobbs: yes and even if you had a better solution than someone else if you delayed to broadcast they would win as why I say I'm not sure what the cost of added time to broadcast would be
Jul 24 00:35:13 <lolwat> I just see the height compare Jul 24 00:35:32 <gmaxwell> cjdelisle: when you use pi, you're using child porn. Jul 24 00:35:41 <gmaxwell> (pi contains all strings) Jul 24 00:36:07 <lolwat> gmaxwell! what would you like me to inject to test my script, I will let you pick the image (if it's legal ofcourse)
Jul 24 00:36:09 sacarlson: if you had a better solution and delayed broadcast, so long as you did not delay longer than it takes to find the NEXT solution, so no
Jul 24 00:36:27 sacarlson: your assumptions are wrong
Jul 24 00:36:34 lolwat: i'd have to look Jul 24 00:36:52 <cjdelisle> gmaxwell: You don't need to explain to me the law and I hope I don't need to explain to you public relations. Jul 24 00:37:02 <jrmithdobbs> lolwat: it's in there somewhere. this is why there are very commonly abandoned blocks (like 1 every 24-96 hours)
Jul 24 00:37:06 how much bandwidth are you saving if you are transmitting the number of the starting bit and the length instead of just trasmitting it directly?
Jul 24 00:37:23 The risk is that it can be used as a PR stunt because it would be technically true that you are downloading CP when you download the blockchain.
Jul 24 00:37:58 * spirals is now known as spirals_away
Jul 24 00:38:07 * larsivi has quit (Ping timeout: 240 seconds)
Jul 24 00:38:09 * Clipse has quit (Ping timeout: 255 seconds)
Jul 24 00:38:37 * Prof_BiG_BanG (big_bang@emailing9-cardata.com) has joined #bitcoin-dev
Jul 24 00:38:40 sacarlson: in fact, it is actually in your interest to delay broadcast when your solution is extremely low
Jul 24 00:38:46 jrmithdobbs: well that's good to hear since I plan to implement it in my chains
Jul 24 00:38:49 jrmithdobbs: "lowest hash wins" -> no, all hashes that are low enough win
Jul 24 00:39:08 sacarlson: because then you can work on the solution for the next block for a given amount of time while others waste effort on the old work
Jul 24 00:39:25 <lolwat> sipa, that's what I thought Jul 24 00:39:26 <jrmithdobbs> sipa: if two blocks with same parent with valid solutions exist the lowest hash wins, no? Jul 24 00:39:47 <sacarlson> jrmithdobbs: wow cool they have an algorithm for that if you find a better solution than is needed? Jul 24 00:39:48 <sipa> jrmithdobbs: no Jul 24 00:39:50 <gmaxwell> cjdelisle: it's technically true that you're using childporn when you use pi. It's also easy to find examples of strings involuntarily loaded into other information sources like newspaper classifieds. Jul 24 00:39:58 <sipa> jrmithdobbs: the one that is seen first wins Jul 24 00:40:18 <jrmithdobbs> you sure on that? Jul 24 00:40:23 <sipa> absolutely Jul 24 00:40:34 <gmaxwell> He's correct, I've been incorrect on that in the past. Jul 24 00:40:38 <prof7bit> " that you're using" <-- wrong. Not _using_. Jul 24 00:40:40 <sacarlson> jrmithdobbs: wow I was right?? go figure Jul 24 00:40:49 <gmaxwell> Though by wins it means 'locally' wins. Jul 24 00:40:51 <jrmithdobbs> first time for everything ;p Jul 24 00:40:53 <gmaxwell> Not wins forever. Jul 24 00:40:57 <jrmithdobbs> so really Jul 24 00:40:58 <sipa> there is no matric of candidate hashes being better or worse Jul 24 00:41:00 <jrmithdobbs> it's first to extended wins Jul 24 00:41:06 <sipa> it's just good enough or not good enough Jul 24 00:41:07 <jrmithdobbs> s/to/to get/ Jul 24 00:41:07 <lolwat> yeah in general that would be a bad idea
Jul 24 00:41:21 <lolwat> to count "work done" by 1/hash value Jul 24 00:41:22 <gmaxwell> well, it's a tradeoff of compromises. Jul 24 00:41:39 <lolwat> because then you'd have like, e.g. that dude who mined a block valid for difficulty of 35 billion
Jul 24 00:41:48 <lolwat> could wait and broadcast it a year later Jul 24 00:41:51 <gmaxwell> The way it currently works rewards better network connectivity more strongly. Jul 24 00:42:02 <sipa> lolwat: but it is not valid for difficulty of 35 billion, because the difficilty is encoded in the block
Jul 24 00:42:22 you need to decide your own difficulty before starting to mine
Jul 24 00:42:26 and if the difficulty gets to 35 billion the parent will need to bedifferent
Jul 24 00:42:34 <lolwat> sipa, yes I know, I mean if chain reorg was decided by the hash value and not the difficulty written there Jul 24 00:42:41 <sipa> and that difficulty, not the actual hash obtained, is the expected number of hashes done Jul 24 00:42:46 <gmaxwell> lolwat: ... no, you wouldn't have to do that, you could prefer lowest value top among all chains of the same sum-target difficulty.
Jul 24 00:43:00 <lolwat> sipa, I am saying precisely why using the difficulty is right and using the hash itself is bad Jul 24 00:43:00 <sacarlson> lolwat: so back to the fact that the added delay might be at some cost
Jul 24 00:43:23 <lolwat> so its pretty easy to know what the cost is Jul 24 00:43:27 <jrmithdobbs> lolwat: if it worked like i thought it did it actually wouldn't be bad at all because longest chain still wins, your example wouldn't cause a reorg even if it would work
Jul 24 00:43:28 lolwat: ok, then we're saying the same thing :) Jul 24 00:43:33 <gmaxwell> so once once it was was extended once, it wouldn't matter any more how much below target it was. Jul 24 00:44:17 <lolwat> jrmithdobbs, huh? it would be very bad. Imagine if the guy who solved the 35 billion difficulty block said "hey let me just hold onto this for say, a year"
Jul 24 00:44:35 lolwat: wouldn't matter Jul 24 00:44:55 <lolwat> ? if you count work by 1/hash, it does matter
Jul 24 00:45:27 jrmithdobbs: it would matter
Jul 24 00:45:43 if i accidentally find a hash that is 100 times lower than expected
Jul 24 00:45:52 i can hold onto it for 100 blocks, and then publish it
Jul 24 00:46:06 <lolwat> sacarlson, say the block finding is distributed exponentially with mean 10 minutes Jul 24 00:46:08 <sipa> instantly reverting the 100 blocks found in between Jul 24 00:46:08 <sacarlson> jrmithdobbs: we already have split nets, your method would just open up the posibiltiy of more of them Jul 24 00:46:09 <jrmithdobbs> ok yes 100 blocks Jul 24 00:46:11 <jrmithdobbs> but not a year Jul 24 00:46:21 <prof7bit> how would you work the new hash of the previous plock into it? Jul 24 00:46:22 <sipa> yes, he was exxagerating, but the issue would be very real Jul 24 00:46:32 <prof7bit> block Jul 24 00:46:43 <sipa> prof7bit: not Jul 24 00:46:50 <gmaxwell> This all goes away when you only use it to tiebreak the topmost block. Jul 24 00:46:53 <lolwat> sacarlson, and I find a block at time 0. If the "lag" is t, then the probability I get scooped is just the probability an exponential with mean 10 minutes takes value below t
Jul 24 00:47:08 gmaxwell: agree, but i'm not convinced it's useful there
Jul 24 00:47:27 * Guest6204 has quit (Remote host closed the connection)
Jul 24 00:47:28 sacarlson: i'm not proposing it, it seems i misread something
Jul 24 00:47:30 sipa: Well, it removes some incentives for network connectivity funnybusiness if people went along with the change.
Jul 24 00:47:46 isnt the hash of the previous part of the header? you cannot put your block into any other place in the chain
Jul 24 00:47:56 lolwat: ya it must be very small probability and with a fast proxy it would be almost imposible Jul 24 00:48:03 <gmaxwell> sipa: e.g. right now a large miner will make slightly greater income by agressively filling everyone's connections slots. Jul 24 00:48:09 <sipa> prof7bit: that's the point exactly Jul 24 00:48:19 <lolwat> sacarlson, and for small values of t, that is roughly just t/10 minutes. So a lag of 1 second adds a 1 in 600 chance of you getting scooped
Jul 24 00:48:38 If the lower value was the tiebreaker at the top of the chain then connectivity would be less of a factor.
Jul 24 00:48:50 prof7bit: if you have a very good block T that successes block S, you could revert every "real" block found after S
Jul 24 00:49:06 lolwat: and the real lag will be measured in micro seconds at most Jul 24 00:49:07 <sipa> that is, if 1/hash were used as metric, which it isn't Jul 24 00:49:38 <lolwat> er it wasn't an exaggeration at all
Jul 24 00:49:42 ah, now i get ot
Jul 24 00:49:43 it
Jul 24 00:49:51 <lolwat> think about the distribution of hashes Jul 24 00:50:18 <prof7bit> the total work of the chain up to this block, right? Jul 24 00:50:23 <lolwat> there will be a hash for which 1/H
Jul 24 00:50:34 <lolwat> is about as big as the sum of 1/H_i for ALL previous H_i Jul 24 00:51:26 <lolwat> in other words, every 10k blocks, you expect a hash whose value is 10k times less than it needs to be
Jul 24 00:51:33 devrandom: it seems IPV6_PROTECTION_LEVEL has existed since win xp, so i guess it should be possible to find it in headers
Jul 24 00:51:43 <lolwat> meaning that person could then hold that block for 10k more blocks in your system Jul 24 00:52:26 <lolwat> or alternatively, about once a year someone would get a block whose hash is K times lower than the difficulty needed, where K is the number of blocks per year
Jul 24 00:52:53 <lolwat> that person could reasonably hold that block for a year, in the system you describe jrmithdobbs Jul 24 00:53:52 \* genjix (~genjix@bitcoinconsultancy.com) has left #bitcoin-dev Jul 24 00:54:18 <sacarlson> lolwat: I think jrmithdobbs has already agreed his was wrong
Jul 24 00:54:22 maybe also put a lower boundary on allowed solutions. would change difficulty calculations a little bit but not the general principle.
Jul 24 00:54:48 <lolwat> er ya but he said my point was an exaggeration Jul 24 00:54:50 <lolwat> and it's not at all
Jul 24 00:55:21 x > hash > x/2 or so
Jul 24 00:56:20 In any case, while what jrmithdobbs thought it was doing has issues. Simply using sum1/target,1/topmost_hash or sum1/target,top_hash or even something crazy like sum1/target,h(top_hash_per_node_random) would not have those issues, and would reduce the race incentive.
Jul 24 00:56:45 (though the last would have poor hash power concentration, which isn't great)
Jul 24 00:57:06 <lolwat> i cannot read that at all Jul 24 00:57:21 <AndyBr> ohai btw Jul 24 00:57:32 <lolwat> sum_{i=1}^T expession(i)
Jul 24 00:57:37 so right now
Jul 24 00:58:02 * moa7 (d2305dc2@gateway/web/freenode/ip.210.48.93.194) has joined #bitcoin-dev
Jul 24 00:58:06 it is in any non-pool-miner's best interest to locate the transmitting addresses for the pools and udp flood them non-stop
Jul 24 00:58:29 jrmithdobbs: even better to connect to them with black hole nodes and fill their connection slots.
Jul 24 00:58:38 (and flood them)
Jul 24 00:58:42 ya even better
Jul 24 00:59:24 jrmithdobbs: yes and I think that has happend, that's why we need p2p mining
Jul 24 00:59:35 p2p mining doesn't solve that
Jul 24 00:59:45 p2p mining doesn't fix it either really, just changes the attack a bit.
Jul 24 00:59:57 it solves the udp flood part, somewhat, but not the connection slot filling
Jul 24 00:59:59 and to prevent that, they would make their public nodes firewalled for incoming connections, and only do outgoing connections
Jul 24 01:00:10 which should be quite effective, i think
Jul 24 01:00:33 won't help against udp flooding, though
Jul 24 01:00:50 sipa: then you just spin up thousands of fake nodes... botnets get you good /16 diversity too.
Jul 24 01:01:05 <lolwat> seems pretty easy to defend against Jul 24 01:01:17 <lolwat> you can insert your blocks from arbitrary points in the network
Jul 24 01:01:19 Miners should peer with each other to defend, but they currently don't.
Jul 24 01:01:40 <lolwat> just need to maintain streams open to several insertion points Jul 24 01:02:12 <gmaxwell> We also ought to have a special trusted addnode that reserves slots, can use another port, etc. Thats kinda been on my todo for a while. Jul 24 01:02:24 \* Silverpike has quit () Jul 24 01:02:38 <lolwat> a pool could even hand its block to its clients via some other channel
Jul 24 01:02:40 * deadmause (~deadmau@212-181-171-163-no31.tbcn.telia.com) has joined #bitcoin-dev
Jul 24 01:02:57 <lolwat> if people can get work from the pool, they can get the mined block too, and then they can inject it into the network themselves Jul 24 01:03:20 \* genjix (~genjix@bitcoinconsultancy.com) has joined #bitcoin-dev Jul 24 01:03:21 <jrmithdobbs> except none of the mining software actually knows anything about anything but getwork, pretty much Jul 24 01:03:30 <sipa> or we could move to a model where miners run their own nonce Jul 24 01:03:46 <gmaxwell> Or even their own node! Jul 24 01:03:47 <sipa> and just get the generation tx from the pool Jul 24 01:03:47 <gmaxwell> ;) Jul 24 01:03:54 <sacarlson> maybe some p2p clusters with one random chosen in each cluster to vpn to other clusters to strenghen? Jul 24 01:03:54 <sipa> *node Jul 24 01:04:11 <jrmithdobbs> sacarlson: udp the vpn link Jul 24 01:04:16 <jrmithdobbs> s/udp/udp flood/ Jul 24 01:04:19 <jrmithdobbs> the endpoints for it Jul 24 01:04:31 <gmaxwell> sipa: thats best, also closes of >50% attacks by pools. Jul 24 01:04:35 \* Clipse (~CLIPSE@196-210-147-73.dynamic.isadsl.co.za) has joined #bitcoin-dev Jul 24 01:04:38 <gmaxwell> s/of/off/ Jul 24 01:04:41 <sipa> indeed Jul 24 01:04:42 <sacarlson> jrmithdobbs: how would they know witch link that was and there would be thousands of vpn's to break Jul 24 01:05:09 <jrmithdobbs> thousands? what? Jul 24 01:05:23 <gmaxwell> sipa: they just need to send the pool the header+coin+treefragment which, if encoded efficiently isn't really much more network traffic than the current model. Jul 24 01:05:45 <sipa> gmaxwell: m0mchil is working on a protocol for that Jul 24 01:06:21 <sacarlson> say a cluster only has a group of 10 to 20 in it then pick at random someone in that group to vpn to some random point of another... Jul 24 01:06:57 \* genjix (~genjix@bitcoinconsultancy.com) has left #bitcoin-dev Jul 24 01:07:15 <jrmithdobbs> sacarlson: so instead of having latency introduced by attacks introduce it on yourself for no gain? brilliant Jul 24 01:07:45 <sipa> devrandom: try again? i've hardcoded the constants Jul 24 01:07:46 <sacarlson> jrmithdobbs: I never said I was the smartest in the chain Jul 24 01:08:37 <jrmithdobbs> sacarlson: not to mention that such a system would require a global set of nodes with redudant paths and distinct upstream providers Jul 24 01:08:40 <gmaxwell> The problem with races is that it's very non-linear. If you can delay someone's blocks by 100ms you'll increase their orphan rate for blocks in that gap to 100%. Fortunately blocks are not often found 100ms apart. :) Jul 24 01:09:04 \* genjix (~genjix@bitcoinconsultancy.com) has joined #bitcoin-dev Jul 24 01:09:18 <jrmithdobbs> sacarlson: which is not something easy to do for use cases it make sense for, even ;p Jul 24 01:09:21 \* MrTiggr has quit (Ping timeout: 252 seconds) Jul 24 01:09:24 <genjix> hey, where can i see some use cases for the other transaction types? Jul 24 01:09:50 \* MrTiggr (~MrTiggr@220-253-181-125.NSW.netspace.net.au) has joined #bitcoin-dev Jul 24 01:10:01 <gmaxwell> genjix: https://github.com/groffer/bitcoin/commit/dc2dfbab6a0f75070fc3b962da4eb2967e9659df Jul 24 01:10:02 <sacarlson> genjix: escrow? Jul 24 01:10:15 <devrandom> sipa: net.cpp:1759: error: expected ‘,’ or ‘;’ before ‘setsockopt’ Jul 24 01:10:49 <sacarlson> genjix: ya groffer I worked with him Jul 24 01:11:07 <gmaxwell> BlueMatt: I'd kinda like to get forwarding for pull 319 style transactions into .4 .. so that the damn things will actually work once they are enabled. Jul 24 01:11:11 <genjix> sacarlson: super cool Jul 24 01:11:15 <sipa> devrandom: fixed Jul 24 01:11:52 \* aviadbd has quit (Ping timeout: 252 seconds) Jul 24 01:11:56 <sacarlson> genjix: I'm not a smart programer like him I just helped test it Jul 24 01:12:25 \* deadmause has quit (Quit: deadmause) Jul 24 01:12:48 <genjix> gmaxwell: but this uses SIGHASH_ALL Jul 24 01:12:50 <genjix> ahhh oops Jul 24 01:12:53 <genjix> my bad Jul 24 01:12:57 <genjix> i mean to say Jul 24 01:13:13 <genjix> hey, where can i see some use cases for the other transaction types USING OTHER SIGHASH TYPES? Jul 24 01:13:16 <BlueMatt> gmaxwell: well I have no problem adding them to IsStandard, but that pull does a ton more...in any case why are you asking me, I dont make decisions Jul 24 01:13:16 <genjix> XD Jul 24 01:14:16 <Eliel> BlueMatt: who makes the decisions? Jul 24 01:14:26 <BlueMatt> Eliel: sipa, tcatm, jgarzik, and gavinandresen Jul 24 01:14:33 <prof7bit> there is already p2p mining: its called "solo mining" Jul 24 01:15:22 <genjix> it looks like SIGHASH_ANYONECANPAY allows for an open transaction, but that;s already possible using script Jul 24 01:15:34 <gmaxwell> BlueMatt: Because if I can't even get you to agree with me, then it's probably a waste of time to argue for it. Jul 24 01:16:01 <jrmithdobbs> haha Jul 24 01:16:19 <sacarlson> genjix: I'm still waiting for multi in pool multi out escrow or multi sign transactions Jul 24 01:16:37 <BlueMatt> gmaxwell: lol, well I would absolutely be in favor of adding a ton more stuff to IsStandard, but doing it in-client...maybe not yet? Jul 24 01:17:30 <BlueMatt> gmaxwell: right now Im of the opinion that adding more and more and more features just isnt what bitcoin needs, first code cleanup and libraritization, then let people add their own features via plugins or whatever Jul 24 01:17:32 <sacarlson> BlueMatt: my client already has a setting to turn on and off IsStandard Jul 24 01:17:40 <gmaxwell> well at least the escrow stuff has obvious super useful usecases, and an existing implementation. On the downside pull 349 needs to be resolved. Jul 24 01:17:47 \* soap has quit (Ping timeout: 240 seconds) Jul 24 01:17:59 <BlueMatt> sacarlson: Im not talking about turn it off, Im saying add more patterns to it Jul 24 01:18:02 <sacarlson> we just need to learn how to create new type transactions Jul 24 01:18:03 <gmaxwell> sacarlson: turning off isStandard is a pretty bad idea. Jul 24 01:18:19 <jrmithdobbs> sacarlson: your client? Jul 24 01:18:24 <BlueMatt> I dont think anyone would be against adding more patterns Jul 24 01:18:30 <sacarlson> jrmithdobbs: MultiCoin Jul 24 01:18:39 <BlueMatt> if thats all a pull does, Id bet it would be pulled quick Jul 24 01:19:25 <prof7bit> do it slowly. start with a simple use case that everyone can understand and implement it in a user friendly way. Jul 24 01:19:26 \* denisx (~denis@91-65-136-254-dynip.superkabel.de) has joined #bitcoin-dev Jul 24 01:19:30 <gmaxwell> Have you looked at pull 349? I guess that would be the argument against addin the multisig stuff to isstandard quite yet. Jul 24 01:19:43 <jrmithdobbs> sacarlson: link? Jul 24 01:19:44 <devrandom> sipa: + setsockopt(hListenSocket, IPPROTO_IPV6, nParameterId, (const char_)&nProtLevel, sizeof(int)); Jul 24 01:19:48 <gmaxwell> prof7bit: arguably thats what the escrow patch has down. Jul 24 01:19:49 <prof7bit> and not a ton of complicated esoteric variations Jul 24 01:19:59 <devrandom> sipa: it wants a const char* Jul 24 01:20:09 <gmaxwell> s/down/done/ Jul 24 01:20:11 <sacarlson> jrmithdobbs: http://forum.bitcoin.org/index.php?topic=24209.msg300830#msg300830 Jul 24 01:20:15 <sipa> devrandom: fine :) Jul 24 01:20:19 <sipa> does it work that way? Jul 24 01:20:22 <BlueMatt> gmaxwell: yea, that should be reviewed for 0.4 as well Jul 24 01:20:37 <sipa> devrandom: i can try to connect to you, if you like :) Jul 24 01:21:04 <devrandom> sipa: just a second Jul 24 01:21:36 <sipa> devrandom: the setsockopt call on net.cpp:1731 doesn't fail? Jul 24 01:21:49 <prof7bit> once people can use this and _understand_ it (and can explain it to other people in simple terms) then new more complicated variations of this theme will become obvious. I'm for example still struggling to see how exactly this would work in _practise_. Jul 24 01:21:59 <sacarlson> gmaxwell: these are the tests we did so far with multisign http://paste.ubuntu.com/637841/ Jul 24 01:24:05 <sacarlson> prof7bit: I can give you the poker example in words to give you an idea of a use of multi in multi out Jul 24 01:24:59 <[Tycho]> How do those multisign txes work ? Jul 24 01:25:23 <sacarlson> [Tycho]: did you read this? http://paste.ubuntu.com/637841/ Jul 24 01:25:39 <devrandom> sipa: my windows vm broke... Jul 24 01:25:49 <sipa> hehe Jul 24 01:26:13 \* MrTiggr has quit (Ping timeout: 252 seconds) Jul 24 01:26:13 <sipa> bbiaw Jul 24 01:26:15 <prof7bit> i've read an explanation already and I _think_ I _might_ have understood at least the basic idea but i have no idea how i would explain this (and why it works and how it even _can_ works) to my wife for example. Jul 24 01:26:26 <devrandom> sipa: later Jul 24 01:26:47 <sacarlson> [Tycho]: I've been buzy with other things I'll create more easy reading on escrows in the future Jul 24 01:26:53 <b4epoche_> prof7bit: "this"? Jul 24 01:27:03 \* MrTiggr (~MrTiggr@220-253-188-114.NSW.netspace.net.au) has joined #bitcoin-dev Jul 24 01:27:14 <[Tycho]> sacarlson, I was curious about the redeeming process Jul 24 01:27:33 <jrmithdobbs> prof7bit: it works like escrow, both parties sign off that it is to be released as previously agreed upon Jul 24 01:27:43 <jrmithdobbs> prof7bit: don't understand what you're asking? Jul 24 01:27:44 <prof7bit> this == the more complex kinds of transactions with escrow, etc. that make heavy use of scripts Jul 24 01:28:00 <jrmithdobbs> end users don't need to understand the script impl details Jul 24 01:28:10 <[Tycho]> It's like one person "opens" the transaction, creating a new one that can be redeemed by the user ? Jul 24 01:28:34 <sacarlson> Tycale: redeem is like a vote say you have 2 parties one sends the other recieves you also have a 3rd party added to break a tie in the event of a dispute Jul 24 01:28:39 <b4epoche_> prof7bit: you own a house? Jul 24 01:28:48 <prof7bit> end users need to know what they are doning and what it means or it will look like voodoo to them and they will not accept it Jul 24 01:28:50 <Tycale> ? Jul 24 01:28:59 <prof7bit> house? Jul 24 01:29:19 <b4epoche_> if you do, you've likely been through the escrow process... Jul 24 01:29:20 <sacarlson> Tycale: or sorry [Tycho] Jul 24 01:29:32 <jrmithdobbs> prof7bit: will not accept it? what end users do you speak of that don't think just about everything computer-related is voodoo already? Jul 24 01:29:36 <b4epoche_> almost everyone goes through it with no friggin' idea what's really happening Jul 24 01:29:43 <jrmithdobbs> i'd like to meet these mythical awesome end users Jul 24 01:29:43 <jrmithdobbs> ;p Jul 24 01:30:17 <prof7bit> b4epoche: i am talking about boitcoin. for many users even the way bitcoin works is not understood. not even remotely. Jul 24 01:30:31 <jrmithdobbs> prof7bit: and yet they use it? Jul 24 01:30:34 <b4epoche_> I know you're talking about bitcoin. Jul 24 01:30:39 <prof7bit> many dont. Jul 24 01:30:51 <sipa> i am talking about the internet. for many users even the way internet works in not understood. not even remotely. Jul 24 01:31:00 <jrmithdobbs> prof7bit: so why wouldn't "it's cryptographically secured escrow" be a good enough explanation Jul 24 01:31:08 <moa7> pipes and tubes Jul 24 01:31:10 <jrmithdobbs> prof7bit: i mean, if they don't know what escrow is, sure i see your point Jul 24 01:31:12 \* soap (~soap@cpe-76-181-78-156.columbus.res.rr.com) has joined #bitcoin-dev Jul 24 01:31:12 \* soap has quit (Changing host) Jul 24 01:31:12 \* soap (~soap@rockbox/staff/soap) has joined #bitcoin-dev Jul 24 01:31:15 <jrmithdobbs> prof7bit: but that's out of scope Jul 24 01:31:31 <sipa> you need to give people an abstraction, easy enough that they can see things working, but hiding the details Jul 24 01:31:48 <prof7bit> well, then implement it. but implement not 42 different versions of it so that nobody understands which one exactly to use and how to use it. Jul 24 01:31:53 <[Tycho]> sacarlson, so what's the workflow for redeeming ? Jul 24 01:31:56 <jrmithdobbs> sipa: ya designing a _gui_ for the escrow txns is much harder than explaining it tbqh Jul 24 01:32:14 <sipa> jrmithdobbs: exactly Jul 24 01:32:15 <b4epoche_> gui must have pictures Jul 24 01:32:37 <sipa> you don't need to know the TCP protocol to put a picture on facebook Jul 24 01:32:44 <b4epoche_> a little character labeled "you", another labeled "them", etc. Jul 24 01:33:07 <sacarlson> [Tycho]: the example sesion has it, but in the future you will play with pokerth and not see how it works just put in your chips and get paid without wory of people cheating you by pulling out there funds from the pot Jul 24 01:33:32 <[Tycho]> sacarlson, I rather interested in the inner workings. Jul 24 01:33:34 \* molecular (~molecular@e180073135.adsl.alicedsl.de) has joined #bitcoin-dev Jul 24 01:33:34 <denisx> jrmithdobbs: yesterday someone showed me the netatalk source on github and I thought I know this name! ;) Jul 24 01:33:52 <sacarlson> [Tycho]: well it's all in the code and in help Jul 24 01:34:05 <prof7bit> if i extrapolate the bitcoin dev's UI design skills and the way they think to know how the endusers might think then this will not be easy. Jul 24 01:34:07 <denisx> jrmithdobbs: do you plan to do something with this code like a fork? Jul 24 01:34:56 <prof7bit> (I'm not sure how to formulate this correctly without being too offensive) Jul 24 01:35:02 <prof7bit> sorry Jul 24 01:35:18 <sipa> prof7bit: well, imho bitcoin isn't ready for most end users Jul 24 01:35:24 <prof7bit> but development of a good UI is a science in itself Jul 24 01:35:25 <b4epoche_> I think people understand prof7bit Jul 24 01:35:32 <b4epoche_> designing a good UI is /hard/ Jul 24 01:35:37 <sacarlson> jrmithdobbs: we create webskin to simplify setup of escrow transactions in a gui type maner Jul 24 01:35:43 \* genjix (~genjix@bitcoinconsultancy.com) has left #bitcoin-dev Jul 24 01:36:00 <moa7> people understand money better than understand what programming does Jul 24 01:36:26 <prof7bit> and it is extremely diffcult to understand what the end user will think or expect when he tries to use the application. Jul 24 01:36:58 <sipa> i think bitcoin-qt will be a massive step in the right direction already Jul 24 01:36:59 <sacarlson> jrmithdobbs: for added support for escrow multisign we have this https://github.com/sacarlson/bitcoin-webskin Jul 24 01:36:59 <b4epoche_> prof7bit: indeed… years of writing exam questions has helped me a lot in that area Jul 24 01:37:16 \* phatsphere has quit (Quit: Leaving) Jul 24 01:37:22 <jrmithdobbs> denisx: no, i posted that before the maintainer released it publically Jul 24 01:37:51 <jrmithdobbs> denisx: which was verifiable on the netatalk-dev mailling list archives until someone deleted my post with the link to it Jul 24 01:37:52 <prof7bit> as a programmer you can easily totally lose the connection to the user. things that seem totally obvious to you might seem completely wrong or different in the eyes of the user. Jul 24 01:38:05 <jrmithdobbs> denisx: i made a demand for code under gpl once someone distributed it Jul 24 01:38:23 <b4epoche_> prof7bit: indeed… and 12 years of teaching has helped me with that ;-) Jul 24 01:38:38 <jrmithdobbs> denisx: http://www.reddit.com/r/linux/comments/iwyvb/netafpcom_gpl_compliance_and_censorship/ Jul 24 01:39:12 <b4epoche_> well, maybe not helped me that much, but made me realize how hard it is Jul 24 01:39:16 <AndyBr> sup bitoin =) Jul 24 01:39:53 \* Transformer (~Transform@ool-4a59e397.dyn.optonline.net) has joined #bitcoin-dev Jul 24 01:40:32 \* Transformer has quit (Excess Flood) Jul 24 01:40:39 <jrmithdobbs> denisx: i have no interest in maintaining it, but, _that_ exact set of source builds and _works_ for 10.7's timemachine, whereas the newest commit he pushed doesn't quite it has some problems (was kind of a dick thing to do on his part, push the newest code and not a tarball of the newest working version in addition to it) Jul 24 01:42:05 <denisx> jrmithdobbs: yeah, I hope someone picks it up Jul 24 01:42:29 <prof7bit> i have spent a lot of time in my life working on a totally proprietary home-brewn not very trivial application that autometed some business processes (call it online shop but it was not a shop, it was something completely different) and I have seen how ordinary humans think and what they expect and I sometimes simply could not believe it. i also learned a lot during this time.) Jul 24 01:42:45 <denisx> and moves away from SF (the open source cemetery) Jul 24 01:43:21 <jrmithdobbs> denisx: he doesn't think anyone will, but if he abandons it someone will Jul 24 01:43:31 <jrmithdobbs> denisx: the email threads linked in that link are an interesting read ;p Jul 24 01:44:15 <jrmithdobbs> denisx: he (well his coworker with strong implications that the entire organization) maintains that since netatalk was unmaintained for 5 years it wouldn't be picked up if they dropped it Jul 24 01:44:29 <denisx> jrmithdobbs: yeah, I will do read it, I'm making a german mac podcasts and can use some info to spread some news ;) Jul 24 01:44:45 \* molecular has quit (Ping timeout: 255 seconds) Jul 24 01:44:49 <jrmithdobbs> denisx: ignoring the fact that the 5 years it went unmaintained were the 5 years it _was_ basically a dead protocol and then apple suddenly picked it back up for timemachine, lol Jul 24 01:44:49 <devrandom> ;;later tell sipa outgoing works on XP SP2 after issuing the two "net sh" commands mentioned in the MS kb article Jul 24 01:44:49 <gribble> The operation succeeded. Jul 24 01:45:30 <denisx> for me it was never dead Jul 24 01:46:12 <denisx> works really nice at my homerouter since 10 years or so Jul 24 01:46:14 <jrmithdobbs> it should be Jul 24 01:46:19 <jrmithdobbs> it's an awful protocol Jul 24 01:46:38 <jrmithdobbs> all the updates apple have made have basically made afp more and more nfs-like begging the question, why not just use nfs? Jul 24 01:47:07 \* TheZimm has quit (Quit: Computer has gone to sleep.) Jul 24 01:47:26 <jrmithdobbs> if you want auth on nfs, use kerberos, they _already_ running a local kdc on every mac (which is awesome btw) Jul 24 01:47:38 <Diablo-D3> lol Jul 24 01:47:39 <Diablo-D3> kerberos Jul 24 01:47:43 <Diablo-D3> a failure of a security standard Jul 24 01:47:57 <jrmithdobbs> failure only in that it's not been widely adopted enough Jul 24 01:49:11 <jrmithdobbs> <3 kerberos Jul 24 01:49:19 * TheZimm (~TheZimm@c-98-226-5-69.hsd1.il.comcast.net) has joined #bitcoin-dev Jul 24 01:49:23 * davex__ (~dfriberg@ip68-96-143-149.om.om.cox.net) has joined #bitcoin-dev Jul 24 01:49:28 <Diablo-D3> jrmithdobbs: dude Jul 24 01:49:35 <b4epoche_> prof7bit: I used osCommerce to develop a POS system for my wife's shoe store… that was my first real experience with watching people use a UI Jul 24 01:49:37 <Diablo-D3> when an average person cant understand how kerb works Jul 24 01:49:37 <jrmithdobbs> what? Jul 24 01:49:40 <Diablo-D3> then its a failure Jul 24 01:49:42 <b4epoche_> eye-opening Jul 24 01:49:50 <jrmithdobbs> Diablo-D3: explain how cbc works to me Jul 24 01:49:54 <jrmithdobbs> without wiki Jul 24 01:49:58 <devrandom> ;;later tell sipa the latest seems to be running fine, but I can't netcat into it from an ipv6 enabled host Jul 24 01:49:58 <gribble> The operation succeeded. Jul 24 01:50:17 <jrmithdobbs> Diablo-D3: explain des, 3des, sha, bcrypt to me Jul 24 01:50:28 <jrmithdobbs> Diablo-D3: in terms a "normal" user would understand. Jul 24 01:50:34 <Diablo-D3> jrmithdobbs: dude, do I look like wikipedia to you? look it up yourself. Jul 24 01:50:52 <jrmithdobbs> Diablo-D3: then obviously all those things are failures Jul 24 01:50:52 <Diablo-D3> and yes, it IS easy to describe how a crypt hash works Jul 24 01:50:55 <jrmithdobbs> by your logic Jul 24 01:51:01 <Diablo-D3> speedy thing goes in, speedy thing comes out. Jul 24 01:51:10 <Diablo-D3> no wait, thats a portal Jul 24 01:51:28 <jrmithdobbs> then so is kerberos, "you ask for a token with your password, other machines use your token to verify who you say you are and let you login" Jul 24 01:51:43 <Diablo-D3> jrmithdobbs: kerb is difficult for admins to setup Jul 24 01:51:47 <Diablo-D3> which is really problematic Jul 24 01:51:47 <jrmithdobbs> no it's not Jul 24 01:51:54 <jrmithdobbs> incompetent ones maybe Jul 24 01:52:01 <Diablo-D3> MOST ADMINS _ARE_ INCOMPETENT Jul 24 01:52:03 <Diablo-D3> HELLO, MCFLY Jul 24 01:52:09 <jrmithdobbs> i regenned an entire realm the other day including replication in <5 minutes Jul 24 01:52:49 <jrmithdobbs> working backs is hard for incompetent admins to setup too Jul 24 01:52:53 <jrmithdobbs> therefore backups are a failure Jul 24 01:52:55 <jrmithdobbs> ... Jul 24 01:53:16 <jrmithdobbs> s/backs/backups/ Jul 24 01:53:33 <jrmithdobbs> got any more logical fallacies you'd like to throw out? Jul 24 01:56:16 <prof7bit> b4epoche: it was totally home custom made, i even developed a little app framework for it (we had php3 at that time). Parts of it were used by customers and other parts were used by us and another part of it was used by an external supplier. And it was supposed to let them all work together on the customers orders and the customers could track the progress and at some point they had to react and give approval, etc. very funny Jul 24 01:56:16 <prof7bit> system. 100s of kloc. Jul 24 01:56:58 <jrmithdobbs> Diablo-D3: btw, you do realise that MS's AD auth/sso has been done via kerberos for ~10 years now Jul 24 01:57:02 <jrmithdobbs> right? Jul 24 01:57:25 <denisx> jrmithdobbs: I think your pasties in this pastie are messed up Jul 24 01:57:30 <Diablo-D3> jrmithdobbs: I havent used MS products in a serious role for about 15 years Jul 24 01:57:35 <Diablo-D3> actually, let me rephrase Jul 24 01:57:41 <Diablo-D3> I havent used them in a serious role _ever_ Jul 24 01:58:22 <jrmithdobbs> Diablo-D3: oh so because the group of incompetent admins you dislike more than the others is capable of setting up kerberos on a platform you dislike more than others it's too hard to setup for incompetent admins. Jul 24 01:58:26 <jrmithdobbs> i see. Jul 24 01:58:40 <prof7bit> during these few years i aged approximately 120 years. Jul 24 01:58:51 <jrmithdobbs> denisx: ? Jul 24 01:58:56 <Diablo-D3> jrmithdobbs: um, nice strawman Jul 24 01:58:59 <prof7bit> at least this is how it felt Jul 24 01:59:09 <Diablo-D3> how does a MS product help secure an all linux cluster? Jul 24 01:59:10 <jrmithdobbs> Diablo-D3: no that was sarcasm Jul 24 01:59:15 <jrmithdobbs> Diablo-D3: yours was the strawman Jul 24 01:59:21 <jrmithdobbs> Diablo-D3: linux auths of MS's AD just fine. Jul 24 01:59:26 <jrmithdobbs> using kerberos. Jul 24 01:59:28 <Diablo-D3> so MS AD runs on linux now? Jul 24 01:59:36 <jrmithdobbs> that wasn't a requirement Jul 24 01:59:50 <Diablo-D3> all linux cluster implies even the auth server runs linux Jul 24 01:59:55 <jrmithdobbs> auth should be seperate from the cluster Jul 24 02:00:03 <jrmithdobbs> separate Jul 24 02:00:07 <prof7bit> it all boils down to how the user can understand it, everything else is almost meaningless. Jul 24 02:00:13 \* freakazoid (~seanl@c-67-164-106-36.hsd1.ca.comcast.net) has joined #bitcoin-dev Jul 24 02:00:16 <Diablo-D3> jrmithdobbs: hows this, no windows in the damned building. Jul 24 02:00:36 <jrmithdobbs> hosted AD Jul 24 02:00:41 <jrmithdobbs> you suck at this game Jul 24 02:00:44 <Diablo-D3> in the entire company Jul 24 02:00:51 <jrmithdobbs> 3rd party contractor providing AD Jul 24 02:00:57 <jrmithdobbs> you suck at this game Jul 24 02:01:03 <Diablo-D3> then I'd use openid and co over kerb. Jul 24 02:01:19 <jrmithdobbs> which destroys sso Jul 24 02:01:52 <Diablo-D3> not at all Jul 24 02:01:53 <denisx> jrmithdobbs: never mind, I thought some of them are in the wrong order... Jul 24 02:01:56 <jrmithdobbs> Diablo-D3: basically your argument is _you_ don't understand kerberos and _you_ can't implement, so it's too hard ;p Jul 24 02:02:05 <Diablo-D3> openid and friends are the ultimate sso Jul 24 02:02:13 <Diablo-D3> jrmithdobbs: no, I probably could WRITE a kerb impl Jul 24 02:02:38 <lolwat> lolwut openid and krb are totally different
Jul 24 02:02:46 denisx: gpgmail hasn't been updated for mail.app 5.0 so some of the indenting accidentally got lost when i signed stuff
Jul 24 02:02:54 Diablo-D3: openid doesn't provide sso
Jul 24 02:03:08 Diablo-D3: how could you impl kerb if you don't understand what sso is?
Jul 24 02:03:14 * theorb (~theorb@91.84.53.6) has joined #bitcoin-dev
Jul 24 02:03:17 jrmithdobbs: openid plus other things DO provide sso
Jul 24 02:03:24 what other things?
Jul 24 02:03:49 oauth, for example, if you need tokens.
Jul 24 02:03:57 afaik with openid you have to resend creds for every auth request != sso
Jul 24 02:04:04 how do you get listtransactions to provide more than the last 10 transactions? count=15 returns [] , does mine have a bug?
Jul 24 02:04:06 jrmithdobbs: no
Jul 24 02:04:11 openid is a sign in once tech
Jul 24 02:04:31 as long as your session exists, the sign in sticks
Jul 24 02:04:40 oh so no session timeout enforced by the auth layer? sounds like a horrible replacement for krb
Jul 24 02:04:46 * theorbtwo has quit (Ping timeout: 260 seconds)
Jul 24 02:04:55 and settable per session by the user
Jul 24 02:04:58 jrmithdobbs: its used for websites often
Jul 24 02:05:05 * theorb is now known as theorbtwo
Jul 24 02:05:12 i know what oath/openid are, and they're awful imho
Jul 24 02:05:13 now, yes, I do agree that web sign ons in general are screwy
Jul 24 02:05:24 jrmithdobbs: you can add tokens in openid sessions that add timeout
Jul 24 02:05:35 sacarlson: yeah, but the website has to kick you out first
Jul 24 02:05:52 websites that use openid typically just plop a session cookie in your browser like normal
Jul 24 02:06:02 the openid provider itself has no control there
Jul 24 02:06:11 devrandom: hmm, no incoming?
Jul 24 02:06:14 Diablo-D3: everytime you update the page a new token is provided I think
Jul 24 02:06:19 devrandom: is that on xp or w7?
Jul 24 02:06:21 sacarlson: not on most sites
Jul 24 02:06:21 sacarlson: nope
Jul 24 02:06:32 there are sites that do that, but it is NOT part of openid
Jul 24 02:06:33 sacarlson: that could be done in theory but then you'd have to reauth on every page iirc
Jul 24 02:06:41 jrmithdobbs: I"ll have to double check mine then
Jul 24 02:06:45 or cache creds
Jul 24 02:06:48 which is worse
Jul 24 02:07:00 websites typically just have a use once session cookie
Jul 24 02:07:05 openid wishes it were kerberos basically, but it's not
Jul 24 02:07:14 err oauth+openid
Jul 24 02:07:15 when it expires, you have to log in again, or get a new session cookie that the site gave you
Jul 24 02:07:37 yea if it constantly changed the tabs -> fail
Jul 24 02:08:01 jrmithdobbs: well, it depends how you define "kerb usage"
Jul 24 02:08:12 most people using kerb simply arent using everything it can do
Jul 24 02:08:18 and are using it purely for the sso backend
Jul 24 02:08:23 true
Jul 24 02:08:42 openid's only flaw imo is it requires an actual web browser (ie, its meant for web sites) to login
Jul 24 02:08:50 but it can be used for everything from auth->sso->data channel encryption->identity verification of 3rd parties
Jul 24 02:08:52 <3 kerberos
Jul 24 02:09:04 jrmithdobbs: well, theres a small problem with that
Jul 24 02:09:15 which is?
Jul 24 02:09:17 data channel encryption IS handled in openid+oauth land
Jul 24 02:09:25 out of band
Jul 24 02:09:32 its a part of the stack, but not part of either of those specs
Jul 24 02:09:49 identify verification can be done with oauth, btw
Jul 24 02:09:58 actually, it can be done with SOME openid providers too
Jul 24 02:10:24 ya that's the other problem with openid/oath is every provider is slightly different in spec-breaking ways ;p
Jul 24 02:10:26 theres at least one that, for example, offer support for shit like finger print readers and crypto dongles
Jul 24 02:10:32 not spec breaking
Jul 24 02:10:37 they just offer more choices
Jul 24 02:10:55 the website using openid doesnt NEED to know whats going on
Jul 24 02:11:04 Diablo-D3: google has actually, several times, changed user's ticket id or whatever that is their unique identifier
Jul 24 02:11:09 not joking
Jul 24 02:11:25 so if you only used google as a provider for some website you'd lose your account because your identifier changed
Jul 24 02:11:28 lol
Jul 24 02:11:34 jrmithdobbs: wtf
Jul 24 02:11:51 damn, sudo via fingerprint swipe is sexy as hell
Jul 24 02:12:03 Diablo-D3: you were correct my site doesn't change the token unless the session is broken it would appear
Jul 24 02:12:06 bluematt: pam has fucking shit for everything
Jul 24 02:12:12 no shit
Jul 24 02:12:15 i really wish i was joking, because openid/oauth are better than nothing (but not as good as kerberos)
Jul 24 02:12:27 jrmithdobbs: wtf, that site is somewhat possibly broken
Jul 24 02:12:34 I mean, wtf google and all
Jul 24 02:12:43 but Im not using that id
Jul 24 02:12:46 Diablo-D3: no google is broken, other providers have done it too
Jul 24 02:12:57 * underscor has quit (Ping timeout: 276 seconds)
Jul 24 02:13:09 tcatm, am i seriously going to have to use mod_rewrite just to name files trades.json
Jul 24 02:13:15 what Im saying is, Im not using that for the internal id on my site
Jul 24 02:13:18 now if only dmcrypt would decrypt via fingerprint scan...
Jul 24 02:13:25 Diablo-D3: was just an example
Jul 24 02:13:28 BlueMatt, you can do that
Jul 24 02:13:33 it's just silly insecure
Jul 24 02:13:40 yea, I would think so
Jul 24 02:13:41 bluematt: dmcrypt doesnt use pam for auth
Jul 24 02:13:50 it'd be interesting as hell if it did, though
Jul 24 02:13:56 BlueMatt, sudo via fingerprint swipe is also insecure as hell
Jul 24 02:14:06 Diablo-D3: I know, I was just wishing if it could use some kind of fingerprint scan hash for key
Jul 24 02:14:07 i'm working on using OTP-ish stuff for dm_crypt key storage ;p
Jul 24 02:14:24 the fingerprint is stored as a hash of some data structure, but it only results in like 12 bits of entropy
Jul 24 02:14:27 (technically it's challenge-response, but in a semi-onetime way)
Jul 24 02:14:28 jrmithdobbs: still, the problem is this
Jul 24 02:14:31 phantomcircuit: well yea, someone can grab a scan of your print from a glass or something...
Jul 24 02:14:35 jrmithdobbs: I do not want to deploy my own auth scheme
Jul 24 02:14:38 phantomcircuit: thats it?
Jul 24 02:14:46 BlueMatt, no you can bruteforce it trivially
Jul 24 02:14:49 jrmithdobbs: its easy to code, its easy to secure from the electronic side
Jul 24 02:14:52 Diablo-D3: internally?
Jul 24 02:14:54 phantomcircuit: 2**12 sounds way too small
Jul 24 02:14:58 jrmithdobbs: yeah
Jul 24 02:15:04 why wouldn't you deploy your own auth scheme?
Jul 24 02:15:05 BlueMatt, lol it is
Jul 24 02:15:07 jrmithdobbs: but its not actual authentication
Jul 24 02:15:11 phantomcircuit: maybe that was some old model?
Jul 24 02:15:40 fingers can be hacked easily.
Jul 24 02:15:48 BlueMatt: i don't trust biometric scanners, almost all of them have ended up having HORRIBLEY simple spoofing methods
Jul 24 02:15:51 yea, they can get a print from something you touch...
Jul 24 02:15:55 BlueMatt: at least, not as a lone factor
Jul 24 02:15:56 BlueMatt, my T61's builtin fingerprint swipe would result in a 64 bit "hash" of which the first 42 bits where trivially predicted
Jul 24 02:16:11 jrmithdobbs: I can have them put an email in, and then even send a click me auth url to the email, it still doesnt tell me who the people really are
Jul 24 02:16:14 * senseles (senseless@112.202.74.41) has joined #bitcoin-dev
Jul 24 02:16:18 not to mention that my fingerprints where all over the thing anyways lol
Jul 24 02:16:22 phantomcircuit: damn...again though, maybe that was an old

@orpheuslummis
Copy link

The World IPv6 Launch is coming. Ideally, Bitcoin should support IPv6 before that day.

@sipa
Copy link
Member Author

sipa commented Jan 26, 2012

Most of the changes in this pull request are in the already-merged netbase (network stack refactor). I'm working on tackling the address issue, but this pull request can be closed until then.

@sipa sipa closed this Jan 26, 2012
sipa added a commit to sipa/bitcoin that referenced this pull request Dec 12, 2016
@sipa
Squashed 'src/secp256k1/' changes from 7a49cac..8225239
7b49f22 
8225239 Merge bitcoin#433: Make the libcrypto detection fail the newer API.
12de863 Make the libcrypto detection fail the newer API.
2928420 Merge bitcoin#427: Remove Schnorr from travis as well
8eecc4a Remove Schnorr from travis as well
a8abae7 Merge bitcoin#310: Add exhaustive test for group functions on a low-order subgroup
b4ceedf Add exhaustive test for verification
83836a9 Add exhaustive tests for group arithmetic, signing, and ecmult on a small group
20b8877 Add exhaustive test for group functions on a low-order subgroup
80773a6 Merge bitcoin#425: Remove Schnorr experiment
e06e878 Remove Schnorr experiment
04c8ef3 Merge bitcoin#407: Modify parameter order of internal functions to match API parameter order
6e06696 Merge bitcoin#411: Remove guarantees about memcmp-ability
40c8d7e Merge bitcoin#421: Update scalar_4x64_impl.h
a922365 Merge bitcoin#422: Restructure nonce clearing
3769783 Restructure nonce clearing
0f9e69d Restructure nonce clearing
9d67afa Update scalar_4x64_impl.h
7d15cd7 Merge bitcoin#413: fix auto-enabled static precompuatation
00c5d2e fix auto-enabled static precompuatation
91219a1 Remove guarantees about memcmp-ability
353c1bf Fix secp256k1_ge_set_table_gej_var parameter order
541b783 Fix secp256k1_ge_set_all_gej_var parameter order
7d893f4 Fix secp256k1_fe_inv_all_var parameter order

git-subtree-dir: src/secp256k1
git-subtree-split: 8225239
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Dec 13, 2016
Squashed 'src/secp256k1/' changes from 6c527ec..8225239
64dfdde 
8225239 Merge bitcoin#433: Make the libcrypto detection fail the newer API.
12de863 Make the libcrypto detection fail the newer API.
2928420 Merge bitcoin#427: Remove Schnorr from travis as well
8eecc4a Remove Schnorr from travis as well
a8abae7 Merge bitcoin#310: Add exhaustive test for group functions on a low-order subgroup
b4ceedf Add exhaustive test for verification
83836a9 Add exhaustive tests for group arithmetic, signing, and ecmult on a small group
20b8877 Add exhaustive test for group functions on a low-order subgroup
80773a6 Merge bitcoin#425: Remove Schnorr experiment
e06e878 Remove Schnorr experiment
04c8ef3 Merge bitcoin#407: Modify parameter order of internal functions to match API parameter order
6e06696 Merge bitcoin#411: Remove guarantees about memcmp-ability
40c8d7e Merge bitcoin#421: Update scalar_4x64_impl.h
a922365 Merge bitcoin#422: Restructure nonce clearing
3769783 Restructure nonce clearing
0f9e69d Restructure nonce clearing
9d67afa Update scalar_4x64_impl.h
7d15cd7 Merge bitcoin#413: fix auto-enabled static precompuatation
00c5d2e fix auto-enabled static precompuatation
91219a1 Remove guarantees about memcmp-ability
7a49cac Merge bitcoin#410: Add string.h include to ecmult_impl
0bbd5d4 Add string.h include to ecmult_impl
353c1bf Fix secp256k1_ge_set_table_gej_var parameter order
541b783 Fix secp256k1_ge_set_all_gej_var parameter order
7d893f4 Fix secp256k1_fe_inv_all_var parameter order
c5b32e1 Merge bitcoin#405: Make secp256k1_fe_sqrt constant time
926836a Make secp256k1_fe_sqrt constant time
e2a8e92 Merge bitcoin#404: Replace 3M + 4S doubling formula with 2M + 5S one
8ec49d8 Add note about 2M + 5S doubling formula
5a91bd7 Merge bitcoin#400: A couple minor cleanups
ac01378 build: add -DSECP256K1_BUILD to benchmark_internal build flags
a6c6f99 Remove a bunch of unused stdlib #includes
65285a6 Merge bitcoin#403: configure: add flag to disable OpenSSL tests
a9b2a5d configure: add flag to disable OpenSSL tests
b340123 Merge bitcoin#402: Add support for testing quadratic residues
e6e9805 Add function for testing quadratic residue field/group elements.
efd953a Add Jacobi symbol test via GMP
fa36a0d Merge bitcoin#401: ecmult_const: unify endomorphism and non-endomorphism skew cases
c6191fd ecmult_const: unify endomorphism and non-endomorphism skew cases
0b3e618 Merge bitcoin#378: .gitignore build-aux cleanup
6042217 Merge bitcoin#384: JNI: align shared files copyright/comments to bitcoinj's
24ad20f Merge bitcoin#399: build: verify that the native compiler works for static precomp
b3be852 Merge bitcoin#398: Test whether ECDH and Schnorr are enabled for JNI
aa0b1fd build: verify that the native compiler works for static precomp
eee808d Test whether ECDH and Schnorr are enabled for JNI
7b0fb18 Merge bitcoin#366: ARM assembly implementation of field_10x26 inner (rebase of bitcoin#173)
001f176 ARM assembly implementation of field_10x26 inner
0172be9 Merge bitcoin#397: Small fixes for sha256
3f8b78e Fix undefs in hash_impl.h
2ab4695 Fix state size in sha256 struct
6875b01 Merge bitcoin#386: Add some missing `VERIFY_CHECK(ctx != NULL)`
2c52b5d Merge bitcoin#389: Cast pointers through uintptr_t under JNI
43097a4 Merge bitcoin#390: Update bitcoin-core GitHub links
31c9c12 Merge bitcoin#391: JNI: Only call ecdsa_verify if its inputs parsed correctly
1cb2302 Merge bitcoin#392: Add testcase which hits additional branch in secp256k1_scalar_sqr
d2ee340 Merge #388: bench_ecdh: fix call to secp256k1_context_create
093a497 Add testcase which hits additional branch in secp256k1_scalar_sqr
a40c701 JNI: Only call ecdsa_verify if its inputs parsed correctly
faa2a11 Update bitcoin-core GitHub links
47b9e78 Cast pointers through uintptr_t under JNI
f36f9c6 bench_ecdh: fix call to secp256k1_context_create
bcc4881 Add some missing `VERIFY_CHECK(ctx != NULL)` for functions that use `ARG_CHECK`
6ceea2c align shared files copyright/comments to bitcoinj's
70141a8 Update .gitignore
7b549b1 Merge bitcoin#373: build: fix x86_64 asm detection for some compilers
bc7c93c Merge bitcoin#374: Add note about y=0 being possible on one of the sextic twists
e457018 Merge bitcoin#364: JNI rebased
86e2d07 JNI library: cleanup, removed unimplemented code
3093576 JNI library
bd2895f Merge pull request bitcoin#371
e72e93a Add note about y=0 being possible on one of the sextic twists
3f8fdfb build: fix x86_64 asm detection for some compilers
e5a9047 [Trivial] Remove double semicolons
c18b869 Merge pull request bitcoin#360
3026daa Merge pull request bitcoin#302
03d4611 Add sage verification script for the group laws
a965937 Merge pull request bitcoin#361
83221ec Add experimental features to configure
5d4c5a3 Prevent damage_array in the signature test from going out of bounds.
419bf7f Merge pull request bitcoin#356
03d84a4 Benchmark against OpenSSL verification

git-subtree-dir: src/secp256k1
git-subtree-split: 8225239
deadalnix pushed a commit to deadalnix/bitcoin that referenced this pull request Jan 19, 2017
@sipa
Merge bitcoin#427: Remove Schnorr from travis as well
2928420 
8eecc4a Remove Schnorr from travis as well (Pieter Wuille)
sanch0panza pushed a commit to sanch0panza/bitcoin that referenced this pull request Apr 7, 2017
@gandrewstone
Merge pull request bitcoin#427 from gandrewstone/dev2
9a99acd 
Add automatic source formatting checking
classesjack pushed a commit to classesjack/bitcoin that referenced this pull request Jan 2, 2018
@Earlz
Merge pull request bitcoin#427 from qtumproject/earlz/v0.14.10
fca55e1 
Bump to v0.14.10
jtimon added a commit to jtimon/bitcoin that referenced this pull request Oct 15, 2018
@jtimon
Merge bitcoin#427: [0.17] Don't edit Chainparams after initialization
a31ab0e 
06f1b42 Don't edit Chainparams after initialization (Jorge Timón)
875a47c MOVEONLY: Move versionbits info out of versionbits.o (Jorge Timón)

Pull request description:

  This is a backport of bitcoin#13311 since it's already merged, merging this in elements-0.17 should at least make the next rebase slightly easier. And since we're heavily touching chainparams in elements, I think it's a good thing.

Tree-SHA512: 177f6396a34ecf87b609b39a108cc2b1e5b49bd8d12b705a4ae0241c7a5007db754ff01d6d045ee1e6a219ec6c6767663cd98558752c83961c4aff3378aef5a2
jtimon pushed a commit to jtimon/bitcoin that referenced this pull request Oct 17, 2018
@instagibbs
Merge bitcoin#432: [0.17] QA: Use resgtest2 chain instead of regtest …
de842cb 
…for rpc tests

a1e0c56 QA: Use resgtest2 chain instead of regtest for rpc tests (Jorge Timón)
4454c52 QA: Adapt BitcoinTestFramework for chains other than "regtest" (Jorge Timón)
a06be15 Testchains: Introduce custom chain whose constructor... (Jorge Timón)
46749eb Testchains: Qt: Simplify network/chain styles and add a default purple (Jorge Timón)
c0c1e38 Testchains: Generic selection with -chain=<str> in addition of -testnet and -regtest (Jorge Timón)
56515c3 9102: Really don't validate genesis block (Gregory Sanders)

Pull request description:

  Backport of bitcoin#8994

  The tests seem to pass with:

  ```
  python3 ./test/functional/test_runner.py -j4 --extended
  ```

  Let's please try to keep all general review things on bitcoin#8994 and elements-specific things here.

  Dependencies:

  - [x] [0.17] Don't edit Chainparams after initialization bitcoin#427
  - [x] [0.17] Test: Fix example_test.py bitcoin#434

Tree-SHA512: e216587b6f9d3a462372915e01c8eb3c65a61e4ea29f398e65a7fc03a3ea5676c4711527b5cc2c115893591e7cd5b0ecd2f1fac4faf7ef747a022e2657bc99d4
rajarshimaitra pushed a commit to rajarshimaitra/bitcoin that referenced this pull request Aug 5, 2021
@aantonop
Fixes bitcoin#427
a47b23f
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
Feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@sipa @TheBlueMatt @T-X @orpheuslummis