Richard Moore [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-06-04 to 2015-09-12
💬 Posted a total of 18 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:40:02

- reply

📅 Original date posted:2015-09-12
📝 Original message:Hey all,
I am throwing out an idea I’ve been toying with, for feedback and if it seems like an idea worth pursuing, possibly a BIP number.
The goal is to make straight forward stealth address that are SPV friendly and easy to support in software without too much special goop.
I’ve got working code at https://github.com/ricmoo/sandbox/tree/master/stealth, and here are some example transactions on the block chain:
Target Public Key: 029ed06e396761c24416cf7323ed4f1cb29763ee9e2b0fccae347d6a2a3eaecbf5
Target Public Key [tentative] Encoding (this is what you would give away): 59KkSZsVE7vErdqo8m5gtNoez44CbdwJQ5cSM1AAARzN19vkJ6NU
Revocable Payment made: b4ad20cad4cc2fcbbec09bc071dfe8c4a4b1e8e57d1e56bf51947445cfc6c7af
Irrevocable Payment made: f600643a1d32152117be0d9c652a86dc6182d2dab3be53340739395f524cd95c
Cleared out all funds from stealth address: 58eb0fdab108c7add74835466251ffe5c51c7f4cec149f06daf0435d43d9ce55
Idea overview:
There are 2 modes of operation, revocable and irrevocable payments. Revocable payments result in both parties knowing the private key, allowing for a certain level of plausible deniability when the funds are swept, as to whether the funds were actually sent or were revoked… You could imagine WikiLeaks stating they will not claim donations for 1-3 months after receiving them; if the funds are claimed after 1.5 months, did the sender actually send funds? The other option is irrevocable, where only the receiver can claim the funds (allowing them to leave them in that address until they need to be spent).
The basic idea is (the above code above gets into the nitty gritty), to send to targetPublicKey:
Given the UTXO set of inputs into a transaction, choose one at random, senderUtxo
Use ECDH(targetPublicKey, senderUtxo.privateKey) as sharedSecret
For revocable payments, you are done; use sharedSecret as your privateKey, compute the address
For irrevocable payments, create a sharedPrivateKey from the bytes of sharedSecret, use ECC addition (or would multiplication make more sense? advantages?) on the public key of sharedPrivateKey and the targetPublicKey. The receiver can then use ECC addition (or multiplication) on the sharedPrivateKey and the targetPrivateKey to generate the coresponding privateKey.
The SPV-able part, is lightly discussed in the top of stealth.js, but I haven’t played with bloom filters enough and the idea is still all too fresh in my head; the general idea is to make a 1-of-2 multisig where the first is the resulting stealth address, and the second is something (anything) that looks like a valid public key, but will match a bloom filter (given a tweak that is generated deterministically from the targetPublicKey) and matches the targetPublicKey. Again, I need much more feedback on this.
Thanks,
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150912/385fc6f2/attachment.html>

2023-06-07 17:39:43

- reply

📅 Original date posted:2015-09-05
📝 Original message:This might also be a useful page to look at:
https://en.bitcoin.it/wiki/Bitcoin_symbol
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
> On Sep 5, 2015, at 10:11 AM, Ken Shirriff via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Use of the bitcoin symbol in text is inconvenient, because the bitcoin symbol isn't in the Unicode standard. To fix this, I've written a proposal to have the common B-with-vertical-bars bitcoin symbol added to Unicode. I've successfully proposed a new character for Unicode before, so I'm familiar with the process and think this has a good chance of succeeding. The proposal is at http://righto.com/bitcoin-unicode.pdf
>
> I received a suggestion to run this proposal by the bitcoin-dev group, so I hope this email is appropriate here. Endorsement by Bitcoin developers will help the Unicode Committee realize the importance of adding this symbol, so please let me know if you support this proposal.
>
> Thanks,
> Ken
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150905/ad8ba582/attachment.html>

2023-06-07 17:38:29

- reply

📅 Original date posted:2015-08-29
📝 Original message:Yes! Good point, network should be encoded. Not sure I like this format yet, but what if it was part of the authority, like block:testnet. Like http uses port 80 by default, you could have block by default refer to block:mainnet.
Eg.
blockchain://tx:testnet3/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
I will read the RFC over more thoroughly tomorrow to get an idea of what types of things make more or less sense.
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
> On Aug 29, 2015, at 2:58 PM, Btc Drak <btcdrak at gmail.com> wrote:
>
> What about supporting different networks? What if I want to look up
> testnet for example?
>
> blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> or
>
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
>
> On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I like the idea of having a standard for this, that all explorers (and even
>> core, eventually) would understand.
>>
>> I would recommend 2 changes though. First, using a real URI scheme,
>> blockchain:// so that we can just use normal URL parsing libraries. The
>> bitcoin: thing leads to additional code to mutate it into a proper URI
>> before passing it to URL parsing. And I think it would be fine to include
>> the type looking up. For example:
>>
>> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>>
>> I think this would help the URI be more human understandable as well as give
>> the explorers the ability to optimize a bit what they are looking for when
>> hitting various databases.
>>
>> A possible future path could also include blockchain://tx/123000/4 for block
>> height, tx index... Another possibility could be blockchain://version which
>> would return a list of supported paths, version of the BIP supported, etc.
>>
>> The BIP should also specify little endian searching. I'm not sure, but would
>> it also make sense for this BIP to include what the return results should
>> look like? Maybe another, related BIP.
>>
>> RicMoo
>>
>> Sent from my self-aware iPhone
>>
>> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>>
>> Richard Moore ~ Founder
>> Genetic Mistakes Software Inc.
>> phone: (778) 882-6125
>> email: ricmoo at geneticmistakes.com
>> www: http://GeneticMistakes.com
>>
>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi!
>> My first post here, hope I'm following the right conventions.
>> I had this humble idea for a while, so I thought to go ahead and propose
>> it.
>>
>> BIP: XX
>> Title: URI scheme for Blockchain exploration
>> Author: Marco Pontello
>> Status: Draft
>> Type: Standards Track
>> Created: 29 August 2015
>>
>> Abstract
>> ========
>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>> addresses on a Blockchain explorer.
>>
>> Motivation
>> ==========
>> The purpose of this URI scheme is to enable users to handle all the
>> requests for details about blocks, transactions, etc. with their preferred
>> tool (being that a web service or a local application).
>>
>> Currently a Bitcoin client usually point to an arbitrary blockchain
>> explorer when the user look for the details of a transaction (es. Bitcoin
>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> Other times resorting to cut&paste is needed.
>> The same happens with posts and messages that reference some particular
>> txs or blocks, if they provide links at all.
>>
>> Specification
>> =============
>> The URI follow this simple form:
>>
>> blockchain: <hash/string>
>>
>> Examples:
>>
>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain:001949
>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>
>> Rationale
>> =========
>> I thought about using some more complex scheme, or adding qualifiers to
>> distinguish blocks from txs, but in the end I think that keeping it simple
>> should be practical enough. Blockchain explorers can apply the same
>> disambiguation rules they are already using to process the usual search
>> box.
>>
>> From the point of view of a wallet developer (or other tool that need to
>> show any kind of Blockchain references), using this scheme mean that he
>> can simply make it a blockchain: link and be done with it, without having
>> to worry about any specific Blockchain explorer or provide a means for the
>> user to select one.
>>
>> Blockchain explorers in turn will simply offer to handle the blockchain:
>> URI, the first time the user visit their website, or launch/install the
>> application, or even set themselves if there isn't already one.
>>
>> Users get the convenience of using always their preferred explorer, which
>> can be especially handy on mobile devices, where juggling with cut&paste
>> is far from ideal.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

2023-06-07 17:38:26

- reply

📅 Original date posted:2015-08-29
📝 Original message:I apologize, you are correct, I should not have used the word "real".
However, if you look at section 3 of the RFC, the first hierarchal level (which in http is used to describe hosts) can be any "authority", not necessarily a hostname.
So, you could use tx, block, address, etc. as the authority for their paths.
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
> On Aug 29, 2015, at 1:19 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
>
> bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical URI (a.k.a. a URL); rather, it's an opaque URI.
>
> And your suggestion is actually in violation of the URI spec, since "blockhash", "txid", "block", and "address" are not host names.
>
> More correct would be:
>
> blockchain:?blockhash=00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain:?block=189000
> blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986
>
>
>> On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev wrote:
>> I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
>>
>> I would recommend 2 changes though. First, using a real URI scheme, blockchain:// so that we can just use normal URL parsing libraries. The bitcoin: thing leads to additional code to mutate it into a proper URI before passing it to URL parsing. And I think it would be fine to include the type looking up. For example:
>>
>> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>>
>> I think this would help the URI be more human understandable as well as give the explorers the ability to optimize a bit what they are looking for when hitting various databases.
>>
>> A possible future path could also include blockchain://tx/123000/4 for block height, tx index... Another possibility could be blockchain://version which would return a list of supported paths, version of the BIP supported, etc.
>>
>> The BIP should also specify little endian searching. I'm not sure, but would it also make sense for this BIP to include what the return results should look like? Maybe another, related BIP.
>>
>>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Hi!
>>> My first post here, hope I'm following the right conventions.
>>> I had this humble idea for a while, so I thought to go ahead and propose
>>> it.
>>>
>>> BIP: XX
>>> Title: URI scheme for Blockchain exploration
>>> Author: Marco Pontello
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 29 August 2015
>>>
>>> Abstract
>>> ========
>>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>>> addresses on a Blockchain explorer.
>>>
>>> Motivation
>>> ==========
>>> The purpose of this URI scheme is to enable users to handle all the
>>> requests for details about blocks, transactions, etc. with their preferred
>>> tool (being that a web service or a local application).
>>>
>>> Currently a Bitcoin client usually point to an arbitrary blockchain
>>> explorer when the user look for the details of a transaction (es. Bitcoin
>>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>>> Other times resorting to cut&paste is needed.
>>> The same happens with posts and messages that reference some particular
>>> txs or blocks, if they provide links at all.
>>>
>>> Specification
>>> =============
>>> The URI follow this simple form:
>>>
>>> blockchain: <hash/string>
>>>
>>> Examples:
>>>
>>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>>> blockchain:001949
>>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>>
>>> Rationale
>>> =========
>>> I thought about using some more complex scheme, or adding qualifiers to
>>> distinguish blocks from txs, but in the end I think that keeping it simple
>>> should be practical enough. Blockchain explorers can apply the same
>>> disambiguation rules they are already using to process the usual search
>>> box.
>>>
>>> From the point of view of a wallet developer (or other tool that need to
>>> show any kind of Blockchain references), using this scheme mean that he
>>> can simply make it a blockchain: link and be done with it, without having
>>> to worry about any specific Blockchain explorer or provide a means for the
>>> user to select one.
>>>
>>> Blockchain explorers in turn will simply offer to handle the blockchain:
>>> URI, the first time the user visit their website, or launch/install the
>>> application, or even set themselves if there isn't already one.
>>>
>>> Users get the convenience of using always their preferred explorer, which
>>> can be especially handy on mobile devices, where juggling with cut&paste
>>> is far from ideal.
>

2023-06-07 17:38:25

- reply

📅 Original date posted:2015-08-29
📝 Original message:I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
I would recommend 2 changes though. First, using a real URI scheme, blockchain:// so that we can just use normal URL parsing libraries. The bitcoin: thing leads to additional code to mutate it into a proper URI before passing it to URL parsing. And I think it would be fine to include the type looking up. For example:
blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://block/189000
blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
I think this would help the URI be more human understandable as well as give the explorers the ability to optimize a bit what they are looking for when hitting various databases.
A possible future path could also include blockchain://tx/123000/4 for block height, tx index... Another possibility could be blockchain://version which would return a list of supported paths, version of the BIP supported, etc.
The BIP should also specify little endian searching. I'm not sure, but would it also make sense for this BIP to include what the return results should look like? Maybe another, related BIP.
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> ========
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==========
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
>
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
>
> Specification
> =============
> The URI follow this simple form:
>
> blockchain: <hash/string>
>
> Examples:
>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =========
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box.
>
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
>
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
>
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/d07a9a4c/attachment-0001.html>

2023-06-07 15:41:51

- reply

📅 Original date posted:2015-07-10
📝 Original message:Hey guys,
With all the recent congestion and discussion regarding FSS-RBF, I was wondering if there good reasons not to have CPFP as a default policy? Or is it?
I was also wondering, with CPFP, should the transaction fee be based on total transactions size, or the sum of each transaction’s required fee? For example, a third transaction C whose unconfirmed utxo from transaction B has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for the 3 transactions it is going to commit.
I tried to test it out a few days ago, sending 0.0008 btc without any fee, then that utxo into another transaction w/ 0.0001 btc. It still hasn’t confirmed, which could be any of: a) CPFP doesn’t have enough hash power, b) the amounts are too small, c) the coins are too new, d) the fee should have actually been 0.0002 btc, e) the congestion is just too great; or some combination.
Just curious as whatnot…
Thanks,
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/1dd11f95/attachment.html>

2023-06-07 15:41:51

- reply

📅 Original date posted:2015-07-10
📝 Original message:By ignored, do you mean the nodes/miners didn’t even include the low fee transaction in their memory pools, so would no longer have access to it? If a node decides to not include it in its memory pool for this reason, I guess it won’t send out any INV messages either?
Could the broadcaster of TX_b rebroadcast TX_a? Then I guess any node that did add it to its memory pool would realize it’s not new and not rebroadcast it to those who didn’t, so it won’t propagate… Although, after receiving the orphan transaction TX_b, it could re-(pay attention) to an INV with TX_a (for a short-ish time to prevent further DoS vectors)? Assuming the sender of TX_b has a copy of TX_a…
> On Jul 10, 2015, at 12:13 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
>
> CPFP is interesting, but it does not fully cover the case it is trying to address: If TX_a goes out without sufficient fee, sending out a new TX_b will not help TX_a suddenly reach nodes/miners that ignored TX_a.
>
>
> On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me at ricmoo.com <mailto:me at ricmoo.com>> wrote:
> Hey guys,
>
> With all the recent congestion and discussion regarding FSS-RBF, I was wondering if there good reasons not to have CPFP as a default policy? Or is it?
>
> I was also wondering, with CPFP, should the transaction fee be based on total transactions size, or the sum of each transaction’s required fee? For example, a third transaction C whose unconfirmed utxo from transaction B has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for the 3 transactions it is going to commit.
>
> I tried to test it out a few days ago, sending 0.0008 btc without any fee, then that utxo into another transaction w/ 0.0001 btc. It still hasn’t confirmed, which could be any of: a) CPFP doesn’t have enough hash power, b) the amounts are too small, c) the coins are too new, d) the fee should have actually been 0.0002 btc, e) the congestion is just too great; or some combination.
>
> Just curious as whatnot…
>
> Thanks,
> RicMoo
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125 <tel:%28778%29%20882-6125>
> email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
> www: http://GeneticMistakes.com <http://geneticmistakes.com/>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/c2959632/attachment-0001.html>

2023-06-07 15:41:17

- reply

📅 Original date posted:2015-06-30
📝 Original message:I’m not planning to take a firm stance against or for, but one problem with your analogy is that airplanes [currently] are not elastic (until we get TARDIS technology, or semi-TARDIS-like technology); they take up space and resources proportional to their capacity.
It is not the block size that is increasing, it is the *maximum* block size… So, it’s more like saying the *maximum* airplane size is increasing, which I think may be somewhat true (although, I agree, probably not exponentially). It would be more like an airplane whose capacity was doubling every two years, but would shrink when that extra capacity was not needed and only consume the maintenance, fuel, et cetera needed for its current size.
My semi-firm-ish stance is that kicking the can down the road with a static increase is less better. We can always soft-fork the limit down if the *actual* block size is growing too fast. When (and/or if) we need to. I also think 8MB is a rather large jump, for either static or dynamic.
*shrug*
RicMoo
> On Jun 30, 2015, at 11:34 AM, Michael Naber <mickeybob at gmail.com> wrote:
>
> As you know I'm trying to lobby for a block size increase to a static 8MB.
>
> I'm happy to try to get the testing done that people want done for this, but I think the real crux of this issue is that we need to get consensus that we intend to continually push the block size upward as bounded only by technology.
>
> Imagine an engineer (Gavin) at Boeing (Bitcoin Core) said he was going to build an airplane (block) that was going to move 8x as many people (transactions) as today’s planes (blocks), all while costing about the same amount to operate. Imagine he then went on to tell you that he expects to double the plane’s (block's) capacity every two years!
>
> Without full planes (blocks), will the airlines (miners) go out of business, since planes (blocks) will never be full and the cost to add people (transactions) to a plane (block) will approach zero? Probably not. Airlines (miners) still have to pay for pilots, security screening staff, fuel, etc (engineers, hash rate, electricity, etc) so even if their airplanes (blocks) can hold limitless people (transactions), they would still have to charge sufficient fees to stay in business.
>
> What tests do you need done to move to 8MB? Pitch in and help get those tests done; agree that we'll run more tests next year or the year after when technology might allow for 16 MB blocks. Do you really want to be the guy holding back bigger planes? Do you really want to artificially constrain block size below what technology allows?
>
> In the face of such strong market demand for increased capacity in globally aware global consensus, do you really think you can prevent supply from meeting demand when the technology exists to deliver it? Do you really want to force a fork because you and others won't agree to a simple raise to a static 8MB?
>
> Do what's best for Bitcoin and define what needs to get done to agree to a simple block size increase to a static 8MB.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/7556f050/attachment-0001.html>

2023-06-07 15:36:18

- reply

📅 Original date posted:2015-06-17
📝 Original message:Awesome graph!
It would be interesting if you could use your Excel voodoo (or whatever graph app you use) to add density as a heat map, making areas with more blocks red and regions with less blocks blue…
> On Jun 1, 2015, at 8:42 PM, Tom Harding <tomh at thinlink.com> wrote:
>
> On 6/1/2015 10:21 AM, Adam Back wrote:
>> if it stays as is for a year, in a wait and see, reduce spam, see
>> fee-pressure take effect as it has before, work on improving improve
>> decentralisation metrics, relay latency, and do a blocksize increment
>> to kick the can if-and-when it becomes necessary and in the mean-time
>> try to do something more long-term ambitious about scale rather than
>> volume.
>
> What's your estimate of the lead time required to kick the can,
> if-and-when it becomes necessary?
>
> The other time-series I've seen all plot an average block size. That's
> misleading, because there's a distribution of block sizes. If you bin
> by retarget interval and plot every single block, you get this
>
> http://i.imgur.com/5Gfh9CW.png
>
> The max block size has clearly been in play for 8 months already.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150617/2b106d0e/attachment.html>

2023-06-07 15:32:51

- reply

📅 Original date posted:2015-04-29
📝 Original message:I have a library, pycoind (https://github.com/ricmoo/pycoind <https://github.com/ricmoo/pycoind>) you might find useful.
>>> import pycoind
>>> str(pycoind.script.Tokenizer('76a9143f320f852a51643d3ffbaa1f49bfe521dd97764a88ac'.decode('hex')))
'OP_DUP OP_HASH160 3f320f852a51643d3ffbaa1f49bfe521dd97764a OP_EQUALVERIFY OP_CHECKSIG'
> On Apr 29, 2015, at 1:12 PM, Braun Brelin <bbrelin at gmail.com> wrote:
>
> Hi all,
>
> I'm trying to find a good python script that will take the hash of the locking and
> unlocking tx scripts and output the actual op codes.
>
> Any ideas where to look?
>
> Thanks,
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150429/72422ca0/attachment.html>

2023-06-07 15:27:37

- reply

📅 Original date posted:2014-11-27
📝 Original message:Heya,
I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought it might make more sense to instead have a OP_CHECKLOCKTIME which would simply push an OP_TRUE or OP_FALSE onto the stack?
That way someone could include multiple OP_CHECKLOCKTIME conditions in a single script. It is trivial to always emulate OP_CHECKLOCKTIMEVERIFY by using a OP_CHECKLOCKTIME OP_VERIFY sequence.
As a second question, would it possibly make more sense to, rather than relying on the nLockTime in a transaction, allow an opcode that would use similar semantics, but against an item in the stack? Then you could essentially include multiple nLockTimes in a single script and make arbitrarily interesting (complicated?) scripts based on block height and/or block timestamp.
The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using
nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY
Just something that came to mind while reading about OP_CHECKLOCKTIMEVERIFY.
Thanks,
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com <mailto:ricmoo at geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141127/be90f9d6/attachment.html>

2023-06-07 15:25:18

- reply

📅 Original date posted:2014-08-19
📝 Original message:Oh, I see. I misread, thinking you wanted the dev team to have a private key and share the public key, similar to alerts. But each peer would have a public/private key pair and use something akin to ECDH for a symmetric key and transport using a block cipher?
How would you share the public key? If I were a man-in-the-middle, I could intercept the public key, generate my own and pass that along and then decouple the pipe when the other side shares their public key.
Also, you should not ignore your SSH fingerprint, as you exactly open yourself to mitm attacks.
On Aug 19, 2014, at 11:11 AM, Raúl Martínez <rme at i-rme.es> wrote:
> Only messages between peers are encrypted, only during transit.
>
> Before sending a transaction to Node B you use his public key, so Node B has the key
>
> El 19/08/2014 17:05, "Richard Moore" <me at ricmoo.com> escribió:
> If you encrypt all messages with an asymmetric cipher, how would each node make use of the blockchain in an encrypted form? Each node would be able to encrypt the data, but only the Bitcoin Core Dev could decrypt it?
>
>
> On Aug 19, 2014, at 5:49 AM, Raúl Martínez <rme at i-rme.es> wrote:
>
>> Hi,
>> I believe that all comunications should be encrypted by default, no matter that is public information (tx info), the only exception I would make would be block packets (to avoid increasing propagation time).
>>
>> I suggest that Bitcoin Core should generate a public/private key pair and share the public one with peers.
>>
>> This could provide privacy and integrity but not autentication.
>>
>> This way you can impersonate a bitcoin node (active mitm) but you cant just be passive and record all transactions send or recieved by an IP address.
>>
>> Today you can just watch for incoming/outgoing transactions to determine what tx are created in the Node, when you find one you can see the Bitcoin address inputs and outputs and track that person's bitcoins.
>> As an example, SSH provides this kind of encryption, althogh Bitcoin Core should ignore fingerprint changes (caused due to reinstalls).
>>
>> Please feel free to disqus why this is not needed or why you like this idea.
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo at geneticmistakes.com
> www: http://GeneticMistakes.com
>
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/6f49bfd8/attachment.html>

2023-06-07 15:25:11

- reply

📅 Original date posted:2014-08-13
📝 Original message:Hey all,
Sorry to keep bugging you all, as I slowly verify the blockchain one transaction after another with my own implementation, but I have found another transaction that is obviously correct (as it is verified by the legit client) that has me seeking clarification.
This multisig output script:
https://blockchain.info/tx-index/12809044/0 (txid: 274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857)
contains a public key:
00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e
Are invalid public keys permitted and silently ignored? Or does the 0x00 prefix have some interesting meaning?
Thanks again,
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140813/817f6fb3/attachment.html>

2023-06-07 15:24:17

- reply

📅 Original date posted:2014-07-19
📝 Original message:Hey all,
I'm wondering if anyone can help explain to me tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
(https://blockchain.info/tx/70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d)
The input signature script is:
304402206b5c3b1c86748dcf328b9f3a65e10085afcf5d1af5b40970d8ce3a9355e06b5b0220cdbdc23e6d3618e47056fccc60c5f73d1a542186705197e5791e97f0e6582a3201
Which decodes to:
r= 48560432700441876832361368709121298776045893858160378595187765610521057848155
s= -22732680560694206332190468058638664750027418114195068375538144640549433890254
(http://lapo.it/asn1js/#304402206B5C3B1C86748DCF328B9F3A65E10085AFCF5D1AF5B40970D8CE3A9355E06B5B0220CDBDC23E6D3618E47056FCCC60C5F73D1A542186705197E5791E97F0E6582A32)
The ECC library I'm using is failing to verify this, which I think makes sense, since I the point needs to be positive, no? But it is obviously valid, as it has been verified and spent. I have tried simply modulo curve.order to positive-ify it, but that didn't seem to work either. Given a point P (with Py < 0) is there some fancy way to bring it into the elliptic curve space, such that Px >= 0 and Py >= 0?
Thanks!
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com

2023-06-07 15:23:42

- reply

📅 Original date posted:2014-07-13
📝 Original message:Hey all,
I'm working on the UTXO database for my Python implementation of bitcoind and have found a situation I did not realize was valid, but since it seems to be, had a quick question.
If you look at block #546 the 4th transaction's first input uses its own block's 3rd transaction as an input.
https://blockchain.info/block/000000005a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6
My question is, would the other way be valid, that is, could the 3rd transaction of a block, use the 4th transaction from the same block as an input? Or are transactions processed strictly top to bottom?
Thanks,
RicMoo
P.S. If it is valid, another question; what would happen if a transaction was self-referencing? I realize it would be very difficult to find one, but if I could find a transaction X whose input was X and had an output Y, would Y be a new valid utxo, without being a generation transaction input?
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140713/8ed59da4/attachment.html>

2023-06-07 15:22:35

- reply

📅 Original date posted:2014-06-09
📝 Original message:Hey all again,
I am implementing BIP38 wallets right now, and had another idea I would like to put out there for discussion.
Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was wondering if it would make sense to include an extra byte in the address which would encode the parameters used? For now, they are fine, as it takes over 3 minutes to to hash once in my pure-Python implementation in CPython (3 seconds in pypy). But with all the latest scrypt mining ASICS hitting the market, and the difficulty rising of the scrypt alt coins, it may become more profitable in the future to try hacking wallets to gobble up their funds. Currently all the hardware is tuned for (1024, 1, 1) and with adaptive-N, it only targets upgrading the N value, so having p =r = 8 certainly means that hardware won’t affect BIP 38… But who knows in the future if they start making Adaptive-N-r-p ASICS.
It also provides a way to vastly secure more important master keys… Maybe for a key that is cold storage of millions of dollars that won’t be touched for multiple years, I don’t mind waiting an hour on commodity hardware to decrypt it.
I was thinking, for example, if we used 1 byte, c, we could use a formula:
N = 2 ** (c + 11)
r = 2 ** c
p = r
Although, even a full byte is overkill… Maybe we can use the top three bits for something else? With 5 bits, the space becomes:
c = 0 => (1024, 1, 1) (same as scrypt mining, albeit requires twice the dkLength)
c = 3 => (16384, 8, 8) (current specs)
c = 31 => (2199023255552,2147483648, 2147483648) (highest difficulty, requiring (5.6 * 10 ** 12) Gigabytes of memory per hash)
Anyways, just thinking out loud… I think even this space is too large… We could also use the top 5 bits for N and lower 3 bits of r, p, if more granularity seems more useful (maybe somebody *wants* their passwords easy to parallelize but still difficult to break?)
N = 2 ** (10 + ((c >> 3) & 0x1f))
r = p = 2 ** ((c & 0x07) * 3)
Would put N = [1024, 2048, ..., 2199023255552] and r = p = [1, 8, 64, 512, ..., 2097152]
The biggest issue would be backwards compatibility. The 6P should obviously stay the same, as it “requires something extra” and the thing required is a passphrase. But maybe we could use one of the reserved bits to indicate that the address is adaptive? The decoded length of the address will also change though, which could pose issues if, for example, bounds checks aren’t being done (bad, but it happens) or in the case of things like python implementations, might assume the length correct an use derived_half2 = decoded[23:] which would now come back with the last byte of derived_half1 and be one byte too long, unchecked, passed into AES, an exception is raised because it is not one 16-byte block. These however seem assumptions that the developer should guard against.
This would retain backward compatibility though, as without the adaptive bit set, new and old implementations can decode the address fine (new implementations assuming c = 3); new implementations can detect the adaptive bit and select the correct kdrf parameters. old implementations on adaptive addresses would hopefully fail upon seeing the length is wrong or that the reserved bits are not 0, otherwise the checksum should fail… But if it does by some 1 in 4 billion chance match, the wallet may successfully import a newly created private key and address… Does this seem likely, or are current implementations ensuring the decoded length and bits are set to 0?
Otherwise, we *could* if all else fails, use “6A” for adaptive, or “6p”… But I don’t really like polluting the namespace for a minor tweak.
Randomly,
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com

2023-06-07 15:22:22

- reply

📅 Original date posted:2014-06-05
📝 Original message:I was considering names like getcheckpoints() to use the terminology that already seemed to be in place, but they were too long :)
I have been using getheaders() in my thick client to quickly grab all the headers before downloading the full blocks since I can grab more at a time. Even with getblocks(), there is the case for a getgist() call. Right now you call getblocks(), which can take some time to get the corresponding inv(), at which time you can then start the call to getdata() as well as the next call to getblocks().
With a gist, for example of segment_count 50, you could call getgist(), then with the response, you could request 50 getblocks() each with a block_locator of 1 hash from the gist (and optimally the stop_hash of the next hash in the gist) to 50 different peers, providing 25,000 (50 x 500) block hashes.
Currently:
>>> getblocks()
<<< inv()
>>> getdata()
<<< block(), block(), block(), … (x 500)
Saturates one peer, while leaving the rest un-used. Step 1 and 2 can be repeated and dispatched to different peers, but there is still the latency between the two calls.
Gist:
>>> getgist()
<<< inv()
>>> getblocks(), getblocks(), getblocks(), … (x segment_count, 1 per peer)
<<< inv(), inv(), inv(), … (x segment_count, 1 per peer)
>>> getdata(), getdata(), getdata(), … (x segment_count, 1 per peer)
<<< block(), block(), block(), … (x (500 * segment_count), ie. 500 in per peer)
Each peer can be saturated.
I will try to run some experiments this weekend to get numbers as to whether there is actually any performance improvement using a gist, or whether the getdata(), block() latency ends up dominating the time anyways.
RicMoo
On Jun 4, 2014, at 11:42 PM, Mike Hearn <mike at plan99.net> wrote:
> Why do you want to optimise this? getheaders is used by SPV clients not full nodes. SPV clients like bitcoinj can and do simply ship with gist files in them, then getheaders from the last "checkpoint" (I wish I hadn't reused terminology like that but this is what bitcoinj calls them).
>
> In practice when I look at performance issues with current SPV clients, getheaders speed is not on my radar.
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140605/a9500408/attachment.html>

2023-06-07 15:22:22

- reply

📅 Original date posted:2014-06-04
📝 Original message:Bitcoin development team,
I recently started implementing my own Python full-node, and had an idea, so I’m prowling through BIP 001 for this proposal, which says to e-mail you kind folks to make sure the idea is original (enough) and that there aren’t other existing means to accomplish what I was thinking. :)
The only way to grab all the headers seems to be to serially get one, then the next and so on, as you need the last hash of a headers() call to the next getheaders(). But we are on a peer-to-peer network, potentially able to getheaders() from many peers simultaneously, if we only knew the hash to look for.
What I was thinking is something to the effect of a getgist() command, fully backward compatible (any node not understanding it, can silently ignore it… Otherwise version or services could be used to announce the capability, but that seems like a little overkill). The inputs to getgist() would be similar to getheaders(); version, hash_count, block_locator_hash, stop_hash and an additional field, segment_count. The response would be a normal headers() message, except, not sequential block headers… Rather they would be spaced out, preferably 2000-block-hash-aligned from the first block hash. So, for example, if you have a blockchain with 198,005 blocks, and you passed it the block locator of height 0 (the genesis block), and a segment_count of 25, you would expect (approximately, the actual algorithm needs to be figured out), the block hashes at the following 25 (segment_count) heights:
1, 8000, 16000, 24000, 32000, 40000, 48000, 56000, 64000, 72000, 80000, 88000, 96000, 104000, 112000, 120000, 128000, 136000, 144000, 152000, 160000, 168000, 176000, 184000, 192000
Which can now be spread across 25 different nodes, fetching the block headers (albeit, out of order, possibly increasing the complexity of the local block chain database) but vastly increasing the speed the whole blockchain can have all headers synced.
I still need to perform some tests to see what type of speed gains there are, but I would suspect it should be segment_count times faster.
Existing methods could be to use checkpoint-ish nodes or bootstrap data files, but these begin relying on semi-cetralizenesses.
Ideas? Suggestions? Concerns? Prior it-ain’t-gonna-works?
Thanks!
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo at geneticmistakes.com
www: http://GeneticMistakes.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/55a199b0/attachment.html>