+1 for something based on git. Github has a dedicated wiki feature that
is git-backed:
https://github.com/bitcoinjs/node-bitcoin-p2p/wiki/
git://github.com/bitcoinjs/node-bitcoin-p2p.wiki.git
On 10/27/2011 6:15 PM, Daniel F wrote:
> +1 on git. not necessarily as replacement, but at least as back
Yup, +1 for Git.
On Thu, Oct 27, 2011 at 6:15 PM, Daniel F wrote:
> +1 on git. not necessarily as replacement, but at least as backup.
> could possibly use markdown and github pages, which automagically
> pushes git commits out to the website (uses markdown syntax, iirc)
>
> On Thu, Oct 27, 2011
+1 on git. not necessarily as replacement, but at least as backup.
could possibly use markdown and github pages, which automagically
pushes git commits out to the website (uses markdown syntax, iirc)
On Thu, Oct 27, 2011 at 11:22 AM, Nils Schneider wrote:
> Can we use a git repo or something more
> However, I ran into the problem that IsStandard() also
> checks that the size of scriptSig is not above 200. Adding an extra
> signature there triggers this limit. I guess there is no way around
> that?
D'oh! I forgot about that check (and should have remembered, I had to
increase it for my 'st
Can we use a git repo or something more redundant for BIPs? They're
rather important and the wiki has been unreliable before.
On 27.10.2011 17:15, Amir Taaki wrote:
> Anybody know how to contact MT about getting it back online? I still
> haven't finished copy-editing the BIPs and need access to th
Anybody know how to contact MT about getting it back online? I still haven't
finished copy-editing the BIPs and need access to them since there's a new one
to be added.
--
The demand for IT networking professionals contin
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
> If you assume the client has all previous transactions, then you could
> get the transaction input's prevout (from the memory pool or disk) and
> then ExtractAddress() from it.
I now created a patch based on this idea. To avoid slowing down
listt
Am Mo, 24.10.2011, 13:09, schrieb Pieter Wuille:
> As far as your green transactions idea is concerned, maybe we could
> provide an interface
> to mark certain addresses as 'trusted', and have an RPC call to request
> all incoming
> transaction that originate from trusted sources?
That would be fi
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
> Green addresses could be implemented as a second signature in the
> scriptSig. You'd have to hack your bitcoin client, but you could
> generate a transaction that had ... as the
> input instead of .
>
> The will be ignored by old clients.
(taking this a bit out of order)
On Thu, Oct 27, 2011 at 3:32 AM, Michael Grønager wrote:
> OK, let me try to explain what I see is the problem:
[snip]
> This, I find a nice and clean setup, where cryptographic keys can be mapped
> to assets.
From my perspective that clean boundary remains: Fun
OK, let me try to explain what I see is the problem:
So far we the bitcoin addresses are (for all practical purposes) a one-to-one
mapping between a pubkey and uint160. This mean that your wallet is defined
solely by your privatekeys (from which you can extract pubkeys and then uint160
btc-addr
11 matches
Mail list logo
