Thanks! I had no idea it existed already  |
|
|
|
Hello all, the bitcoin wiki is a great source of documentation about bitcoin, but please, please, think about people who do not have a regular internet connection. I already have a dump of Wikipedia which I browse with a few Perl scripts (see here if you are interested). I really would like to do the same with the bitcoin wiki. Could anyone create a xml dump such as those which are avaible on wikipedia at http://download.wikimedia.org. I presume that the same tool can be used since it uses the same wiki engine, right? It would really be cool. |
|
|
|
Au fait je pense à un truc. Si jamais ce projet se concrétise, envisagez s'il vous plait une diffusion en P2P ( http://freetorrent.fr), et un format libre genre OggVorbis. La diffusion en P2P pourrait vous permettre de ne pas être radin sur la taille des podcasts et donc éventuellement de faire aussi de la vidéo. |
|
|
|
|
J'espère que Davout n'a pas donné l'idée aux gens de Merdosoft d'installer une blackdoor anti-bitcoin dans la prochaine version de Windaube.
|
|
|
|
My bash bitcoin tools has now a vanityFromPublicPoint function that implements your idea. Exemple: $ vanityFromPublicPoint 04234F25164361B0021E32B8A4A4043FC9A609D7810E0D2AD72674C078D99DA32D5700F2ECCBDAE9D2345E19D64BA6C628706F5FB0D4FB78E66D097D97DDF8822A "Grondi1u"
The public key must be entered as a first argument, in 04[XPOSINHEX][YPOSINHEX] format. The target string is the second argument. You can try the above line if you want. Were you ever find a matching address, I might buy it to you  |
|
|
|
With the new version there is a command called new-bitcoin-key that returns a brand new key in WIF, along with its bitcoin address and its public point. All in YAML: $ . bitcoin.sh
$ new-bitcoin-key
---
WIF: 5HrkBfQH17QvcAshezqpXzKZRd6ogyxMF4pCgXzJG4QkW4S4en7
bitcoin address: 152PktNSb9MnfavZ76pW1Ry9sXsa17snjF
public key: 045960320CAE057C2F3CEA1D58CA587B7207E7CD0BD8104AF7C563717B14013557E926246A48C8C38ADB2E7483B57DE85A8EEB33CC52BDD037B6C87CD41E358D48
There is also a function called vanityFromPublicPoint that allows searching for a vanity address from a public point: $ vanityFromPublicPoint 045960320CAE057C2F3CEA1D58CA587B7207E7CD0BD8104AF7C563717B14013557E926246A48C8C38ADB2E7483B57DE85A8EEB33CC52BDD037B6C87CD41E358D48 "Grondi1u"
This allows people to sell vanity addresses! (see https://bitcointalk.org/index.php?topic=83749.0) |
|
|
|
Jeez, I can't believe the code is so small.
I wish I understood it better.
Well, to be honnest I crunched it to show off. Here is the more verbose version: # Elliptic curve algebra and cryptography using dc
#
# Curve parameters are assumed to be stored in registers p, a, b.
# Subgroup generator is stored in register G with a base-p encoding.
# The order of the subgroup is in register o.
# secp256k1
I16i
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F sp
0000000000000000000000000000000000000000000000000000000000000007 sb
0000000000000000000000000000000000000000000000000000000000000000 sa
79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8 rlp*+ sG
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 so
i
# Most macros assume the modulus is in register 'm'.
# By default m is a copy of p.
lpsm
[ # a modulo that behaves well with negative numbers ( x -- y )
[_1*lm1-*lm%q]St
d0>t lm%
Lts#
]s%
# negation
[_1*l%x]s_
# modular arithmetics ( x y -- z )
[+l%x]s+ [*l%x]s* [-l%x]s-
[Smddl%x-lm/rl%xLms#]s~ [rd0>_rlm|]s|
[ # modular inverse ( x -- y )
l%xsc lmsd
1su 0sv 0sr 1st
[q]SQ
[
lc0=Q
ldlcl~x lc sd sc sq
lrlqlu*- ltlqlv*- lu lv st sr sv su
lXx
]dSXx
LXs#LQs#
lr l%x
]sI
[ # doubling ( A -- B )
lpSm
[+q]S0 d0=0
lpl~x
sy dsx
d*3* la l+x
2ly* lIx
* l%x dsl
d* 2lx * l-x
d lx r l-x ll l*x ly l-x
rlp*+
Lms# L0s#
]sD
[ # addition ( A B -- C )
lpSm
[+q]S0
[2;A lDx q]Sd
d0=0 rd0=0
d2:A lp~ 1:A 0:A
d2:B lp~ 1:B 0:B
2;A 2;B =d
[0q]Sx 2;A 0;B 1;B l_x rlm*+ =x
0;A 0;B l-x lIx dsi
1;A 1;B l-x l*x dsl
d* 0;A l-x 0;B l-x d
0;A r l-x ll l*x 1;A l-x
rlp*+
L0s# Lds# Lxs# Lms#
]sA
# multiplication ( A n -- B )
[
rs.0r
[r l. lAx r]SP
[q]sQ
[
d0!<Q
d2%1=P
2/
l. lDx s.
lLx
]dSLx
s# LPs# LQs#
]sM
I would really like to offer a VeriFone-terminal program that generated Bitcoin addresses and spit out paper wallets. My biggest barrier is the lack of desire to start chopping up OpenSSL and figuring out what to carve out to feed to its dinosaur compiler.
If I had a function that could just do: privkey_to_bitcoin_address(char[32] privkey, char* bitcoinaddressbuffer) that had no external dependencies, I'd have this built in a heartbeat. It's a 32 bit platform.
This should not be too difficult. Couldn't you just compile one statically?? |
|
|
|
I finally wrote a non-recursive, yet much simpler code: sub mult {
my $k = shift;
my $point = shift->clone;
my $result = EC::Point->horizon;
for (; $k > 0; $point = double($point), $k /= 2) {
$result += $point if $k%2 == 1;
}
return $result;
}
To me it is much better than messing aroung with binary shift operators. |
|
|
|
I wrote this dc library for elliptic curve arithmetics on secp256k1: I16iFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2Fsp
7sb0sa483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798lp*+sG
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141soilpsm
[[_1*lm1-*lm%q]Std0>tlm%Lts#]s%[_1*l%x]s_[+l%x]s+[*l%x]s*[-l%x]s-[Smdd
l%x-lm/rl%xLms#]s~[l%xsclmsd1su0sv0sr1st[q]SQ[lc0=Qldlcl~xlcsdscsqlrlq
lu*-ltlqlv*-lulvstsrsvsulXx]dSXxLXs#LQs#lrl%x]sI[lpSm[+q]S0d0=0lpl~xsy
dsxd*3*lal+x2ly*lIx*l%xdsld*2lx*l-xdlxrl-xlll*xlyl-xrlp*+Lms#L0s#]sD[lp
Sm[+q]S0[2;AlDxq]Sdd0=0rd0=0d2:Alp~1:A0:Ad2:Blp~1:B0:B2;A2;B=d[0q]Sx2;A
0;B1;Bl_xrlm*+=x0;A0;Bl-xlIxdsi1;A1;Bl-xl*xdsld*0;Al-x0;Bl-xd0;Arl-xll
l*x1;Al-xrlp*+L0s#Lds#Lxs#Lms#]sA[rs.0r[rl.lAxr]SP[q]sQ[d0!<Qd2%1=P2/l.
lDxs.lLx]dSLxs#LPs#LQs#]sM
It does addition and multiplication of any point. Examples: Doubling the subgroup generator (G): $ dc "$THE_ABOVE_CODE lG lDx lm~f"
Multiplying G by a large number stored in shell variable n: $ dc "$THE_ABOVE_CODE $n lG lMx lm~f"
An so on (the macro for addition is in register 'A'). |
|
|
|
I wrote a pure dc elliptic curve library: I16iFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2Fsp
7sb0sa483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798lp*+sG
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141soilpsm
[[_1*lm1-*lm%q]Std0>tlm%Lts#]s%[_1*l%x]s_[+l%x]s+[*l%x]s*[-l%x]s-[Smdd
l%x-lm/rl%xLms#]s~[l%xsclmsd1su0sv0sr1st[q]SQ[lc0=Qldlcl~xlcsdscsqlrlq
lu*-ltlqlv*-lulvstsrsvsulXx]dSXxLXs#LQs#lrl%x]sI[lpSm[+q]S0d0=0lpl~xsy
dsxd*3*lal+x2ly*lIx*l%xdsld*2lx*l-xdlxrl-xlll*xlyl-xrlp*+Lms#L0s#]sD[lp
Sm[+q]S0[2;AlDxq]Sdd0=0rd0=0d2:Alp~1:A0:Ad2:Blp~1:B0:B2;A2;B=d[0q]Sx2;A
0;B1;Bl_xrlm*+=x0;A0;Bl-xlIxdsi1;A1;Bl-xl*xdsld*0;Al-x0;Bl-xd0;Arl-xll
l*x1;Al-xrlp*+L0s#Lds#Lxs#Lms#]sA[rs.0r[rl.lAxr]SP[q]sQ[d0!<Qd2%1=P2/l.
lDxs.lLx]dSLxs#LPs#LQs#]sM
I wrote this because it was fun, and because I wanted to rely on openssl as little as possible. With this library you can do addition, doubling and multiplication with points on secp256k1. For example, if you want to compute 10^100 times the subgroup generator, i.e. the bitcoin private key whose integer value is 10^100, you can type (assuming the above code is in a "ec.dc" file): $ dc -f ec.dc -e '10 100^ lG lMx lm~f'
I'm planning to use this to do a few cool things, including a simple function for creating a vanity address from a public key. This will allow people to create some for others without needing trust. |
|
|
|
Ben écoute, si le français n'est pas ta langue maternelle, permets-moi de te féliciter parce que tu as posté ce message avec très peu de fautes et dans un français très compréhensible. Ce n'est pas si commun, et même pour des francophones natifs ! Sinon, bonne continuation pour ton site |
|
|
|
|
Sorry I haven't read the whole thread but that is basically Diffie-Hellman, right?
Anyway it sounds to me like a pretty good idea and a possibility for an additionnal business for miners.
An offline tool will be easy to write. My Perl bitcoin library almost aready does the job.
|
|
|
|
To me it's kind of cool.
Recursion is cool on paper. In the real world, unless you have a compiler smart enough to handle tail recursions properly it's dog slow. But then again, it's Perl and Python, so who cares about speed in the first place. The Perl6 developpers are working hard on dealing with tail recursion (I think it's done already in rakudo). I guess the Python team is concerned about that too. Also, the maximum amount of recursive call here is 256. That sure is a lot but it is capped so it should be fine I guess. |
|
|
|
I found out that a really slow part was the elliptic curve exponentiation (this is needed when converting a private key to a bitcoin address). So I wrote a wrapper to make it possible to compute this using BC. It is used when the environment variable "PERL6_EC_METHOD" is set to "BC". It's now about five times faster. Here is the bc code: /*
*
* A small library for elliptic curve arithmetics and cryptography with
* bitcoin.
*
*
*/
scale=0;
/* secp256k1 parameters */
ibase=16;
p= FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F;
b= 7;
a= 0;
gx=79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798;
gy=483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8;
go=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141;
ibase=A;
/* A modulo function that behaves well with negative numbers */
define true_mod(n, m) {
if (n >= 0) return n%m else return -n*(m-1)%m;
}
/* modular inverse function */
define inverse_mod ( n, m ) {
auto c, tc, d, td, uc, tuc, vc, tvc, ud, vd, q;
c = true_mod(n, m); d = m; uc=1; vc=0; ud=0; vd=1; q=0;
while (c != 0) {
q = d / c;
tc = c;
c = true_mod(d, c);
d = tc;
tuc = uc;
tvc = vc;
uc = ud - q*uc;
vc = vd - q*vc;
ud = tuc;
vd = tvc;
}
return true_mod(ud, m);
}
/* This test function should print a long sequence of '1'. */
define test_inverse_mod () {
auto n, i;
n = 2017;
for (i=1; i<n; i++) print (i * inverse_mod(i, n)), n;
}
/*
* Elliptic curve operations.
*
* For simplicity, we'll ignore the possibiliy of a
* point at horizon.
*
* BC functions can not return multiple values,
* so we'll use a base-p encoding for points.
*
*/
define add( point_a, point_b ) {
auto i, l, x, y, xa, ya, xb, yb;
xa = point_a / p; ya = point_a % p;
xb = point_b / p; yb = point_b % p;
i = inverse_mod( xb - xa, p );
l = true_mod((yb - ya) * i, p);
x = l^2 - xa - xb;
y = l*(xa - x) - ya;
return true_mod(x, p) *p + true_mod(y, p);
}
define double( point ) {
auto l, x, y, xout, yout;
x = point / p; y = point % p;
l = true_mod((3*x^2 + a) * inverse_mod( 2*y, p ), p);
xout = true_mod(l^2 - 2*x, p);
yout = true_mod(l*(x - xout) - y, p);
return xout * p + yout;
}
define mult( k, point ) {
if (k == 1) return point;
if (k == 2) return double( point );
if (k % 2 == 0) return double( mult( k/2, point ) );
return add(point, double( mult( k/2, point ) ));
}
];
our sub compute(Str $expression) {
return map {:16($_)},
qqx[
echo "{code}
tmp = $expression;
obase=16;
tmp / p
tmp % p
quit" |
bc -q
].comb: /<xdigit>+/;
}
|
|
|
|
As I was trying to speeden my Perl6 bitcoin library, I realized something that is worth mentionning, imho. In the elliptic curve arithmetics library, the implementation of "mult" is kind of weird and tough to understand. Here is the relevant part in Python: def __mul__( self, other ):
"""Multiply a point by an integer."""
def leftmost_bit( x ):
assert x > 0
result = 1L
while result <= x: result = 2 * result
return result // 2
e = other
if self.__order: e = e % self.__order
if e == 0: return INFINITY
if self == INFINITY: return INFINITY
assert e > 0
# From X9.62 D.3.2:
e3 = 3 * e
negative_self = Point( self.__curve, self.__x, -self.__y, self.__order )
i = leftmost_bit( e3 ) // 2
result = self
# print "Multiplying %s by %d (e3 = %d):" % ( self, other, e3 )
while i > 1:
result = result.double()
if ( e3 & i ) != 0 and ( e & i ) == 0: result = result + self
if ( e3 & i ) == 0 and ( e & i ) != 0: result = result + negative_self
# print ". . . i = %d, result = %s" % ( i, result )
i = i // 2
return result
Well, I don't know about you, but to me, this is ugly. I love recursive functions, so whenever I think I can write one, I think hard about how to actually do it. It appeared to me that this one is a good candidate. Here is what I'd do:
def __mul__( self, other ):
"""Multiply a point by an integer."""
e = other
if self.__order: e = e % self.__order
if e == 0: return INFINITY
if self == INFINITY: return INFINITY
assert e > 0
if e == 1: return self
if e == 2: return self.double
assert e > 2
if e%2 == 0: return (e/2 * self).double
return self + (e/2 * self).double
Well, I didn't try this particular one because I don't like python, but the same idea worked fine with my perl implementation for instance: sub mult {
no warnings qw(recursion);
my $k = shift;
my $u = shift;
return
$k == 1 ? $u :
$k == 2 ? double $u :
$k%2 == 0 ? double mult $k/2, $u :
add $u, double mult $k/2, $u
;
}
To me it's kind of cool. |
|
|
|
I'm assuming with SIGHASH_SINGLE the output scripts are blank but the VarInt is still there, so each output up to before the input index will have 9 bytes, 8 for the value and 1 for the VarInt. Can anyone verify that? Or is it just the value with 8 bytes? Trying to track it down in the C++ client was taking too long.
Also how are output value signs represented as serialised data? Similar to the script, except as little endian? Twos compliment? The serialisation code in the C++ client is just too over my head for me to understand.
I'm not sure I understand exactly your problem, but maybe it could help if I tell you that I had lots of difficulty trying to understand the bitcoin serialisation protocol, until I read Gavin's bitcointools python code. It is much easier to understand than C++. It helped me a lot for my perl library. |
|
|
|
|
(registering to this thread)
|
|
|
|
Berkeley DB, as it's being used in the existing bitcoin client, is a perfect example of why not to use NoSQL.
Has Satoshi ever explained his choice for BerkeleyDB instead of a SQL-based relationnal db? |
|
|
|
Ce n'est pas une vidéo mais un podcast audio en français qui parle de bitcoin (il n'y en a pas tant que ça): le n° 3 de "Monnaie libre" publié aujourd'hui par Stéphane Laborde (Galuel). A relayer et reprendre largement sur vos propres blogs car il est compréhensible par des noobs. Excellente interview. T'as été très complet, Boussac. Et Laborde a été étonnamment tolérant. Bravo à vous deux donc. Une petite critique tout de même: je t'ai trouvé un brun trop consensuel. Pas un mot sur Silk Road par exemple. Quant à ce que tu dis sur la fiscalité et sur le fait que bitcoin ne change pas grand chose dans ce domaine, j'ai l'impression que tu as éludé un peu la question et que ce n'est pas aussi simple que tu le dis. |
|
|
|
Lots of improvements. The Bitcoin::DataStream class is now implemented. This allows me to create a block object from a hexdump and check its proof-of-work. However, it requires a customed version of rakudo with more complete pack/unpack functions. They can be found on my fork of rakudo: http://github.com/grondilu/rakudoIt's still pretty slow, though. But I love the syntax of the whole thing, for instance for creating a new, random bitcoin address: use Bitcoin;
say my $k = Bitcoin::Key.new;
say $k.address;
What is really missing now is a decent database library. If someone would like to port BerkeleyDB on perl6, it would be awesome. |
|
|
|
|
Show Posts
