Patrick Strateman [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-06-06 to 2016-02-07
💬 Posted a total of 24 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, patch, BIP Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1l3uf9m4yw2y7x8wyjeswhelsqyy8ql4jaca4nyy6en0s474yadssg69pvv

Profile Code

nprofile1qqs0c7yja6j89z0rrhzfvc8tulcqzzrs06ewuw6ejzdvehc2l2jwkcg2fcp7e

Author Public Key

npub1l3uf9m4yw2y7x8wyjeswhelsqyy8ql4jaca4nyy6en0s474yadssg69pvv

Show more details

Last Notes

2023-06-07 17:48:47

- reply

📅 Original date posted:2016-02-07
📝 Original message:I would expect that custodians who fail to produce coins on both sides
of a fork in response to depositor requests will find themselves in
serious legal trouble.
Especially if the price moves against either fork.
On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
>
> On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>> They *must* be able to send their customers both coins as separate
>> withdrawals.
>>
> Supporting the obsolete chain is unnecessary. Such support has not
> been offered in any cryptocurrency hard fork before, as far as I know.
> I do not see why it should start now.
>>
>> If not, that amounts to theft of their customers funds.
>>
> If they announce their planned behavior before the fork, I do not see
> any ethical or legal issues.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:45:55

- reply

📅 Original date posted:2015-12-08
📝 Original message:Payment recipients would need to operate a daemon for each chain, thus
guaranteeing no scaling advantage.
(There are other issues, but I believe that to be enough of a show
stopper not to continue).
On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:
> Hello,
>
> I am seeking some expert feedback on an idea for scaling Bitcoin. As a
> brief introduction: I work in the payment industry and I have twenty
> years' experience in development. I have some experience with process
> groups and ordering protocols too. I think I understand Satoshi's
> paper but I admit I have not read the source code.
>
> The idea is to run more than one simultaneous chain, each chain
> defeating double spending on only part of the coin. The coin would be
> partitioned by radix (or modulus, not sure what to call it.) For
> example in order to multiply throughput by a factor of ten you could
> run ten parallel chains, one would work on coin that ends in "0", one
> on coin that ends in "1", and so on up to "9".
>
> The number of chains could increase automatically over time based on
> the moving average of transaction volume.
>
> Blocks would have to contain the number of the partition they belong
> to, and miners would have to round-robin through partitions so that an
> attacker would not have an unfair advantage working on just one partition.
>
> I don't think there is much impact to miners, but clients would have
> to send more than one message in order to spend money. Client messages
> will need to enumerate coin using some sort of compression, to save
> space. This seems okay to me since often in computing client software
> does have to break things up in equal parts (e.g. memory pages, file
> system blocks,) and the client software could hide the details.
>
> Best wishes for continued success to the project.
>
> Regards,
> Akiva
>
> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK AT MATH"
>
>
>
> _______________________________________________
> 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/20151208/82e0a25d/attachment.html>

2023-06-07 17:45:55

- reply

📅 Original date posted:2015-12-08
📝 Original message:If partition is selected from a random key (the hash of the output for
example) then payment recipients would need to operate a full node on
each of the chains.
What's the point of partitioning if virtually everybody needs to operate
each partition?
The mining aspect has it's own set of issues, but I'm not going to get
into those.
On 12/08/2015 01:23 PM, Akiva Lichtner wrote:
> It's true that miners would have to be prepared to work on any
> partition. I don't see where the number affects defeating double
> spending, what matters is the nonce in the block that keeps the next
> successful miner random.
>
> I expect that the number of miners would be ten times larger as well,
> so an attacker would have no advantage working on one partition.
>
> On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Payment recipients would need to operate a daemon for each chain,
> thus guaranteeing no scaling advantage.
>
> (There are other issues, but I believe that to be enough of a show
> stopper not to continue).
>
> On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:
>> Hello,
>>
>> I am seeking some expert feedback on an idea for scaling Bitcoin.
>> As a brief introduction: I work in the payment industry and I
>> have twenty years' experience in development. I have some
>> experience with process groups and ordering protocols too. I
>> think I understand Satoshi's paper but I admit I have not read
>> the source code.
>>
>> The idea is to run more than one simultaneous chain, each chain
>> defeating double spending on only part of the coin. The coin
>> would be partitioned by radix (or modulus, not sure what to call
>> it.) For example in order to multiply throughput by a factor of
>> ten you could run ten parallel chains, one would work on coin
>> that ends in "0", one on coin that ends in "1", and so on up to "9".
>>
>> The number of chains could increase automatically over time based
>> on the moving average of transaction volume.
>>
>> Blocks would have to contain the number of the partition they
>> belong to, and miners would have to round-robin through
>> partitions so that an attacker would not have an unfair advantage
>> working on just one partition.
>>
>> I don't think there is much impact to miners, but clients would
>> have to send more than one message in order to spend money.
>> Client messages will need to enumerate coin using some sort of
>> compression, to save space. This seems okay to me since often in
>> computing client software does have to break things up in equal
>> parts (e.g. memory pages, file system blocks,) and the client
>> software could hide the details.
>>
>> Best wishes for continued success to the project.
>>
>> Regards,
>> Akiva
>>
>> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK
>> AT MATH"
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/e19fe53b/attachment.html>

2023-06-07 17:45:28

- reply

📅 Original date posted:2015-12-02
📝 Original message:If compression is to be used a custom compression algorithm should be
written.
Bitcoin data is largely incompressible outside of a tiny subset of fields.
On 12/01/2015 11:33 PM, Simon Liu via bitcoin-dev wrote:
> Hi Pavel,
>
> (my earlier email was moderated, so the list can only see it via your
> reply),
>
> Yes, an attacker could try and send malicious data to take advantage of
> a compression library vulnerability... but is it that much worse than
> existing attack vectors which might also result in denial of service,
> crashes, remote execution?
>
> Peter, perhaps your BIP can look at possible ways to isolate the
> decompression phase, such as having incoming compressed blocks be saved
> to a quarantine folder and an external process/daemon decompress and
> verify the block's hash?
>
> Regards,
> Simon
>
>
> On 12/01/2015 10:47 PM, Pavel Janík wrote:
>>> On 02 Dec 2015, at 00:44, Simon Liu <simon at bitcartel.com> wrote:
>>>
>>> Hi Matt/Pavel,
>>>
>>> Why is it scary/undesirable? Thanks.
>> Select your preferable compression library and google for it with +CVE.
>>
>> E.g. in zlib:
>>
>> http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1820/GNU-Zlib.html
>>
>> …allows remote attackers to cause a denial of service (crash) via a crafted compressed stream…
>> …allows remote attackers to cause a denial of service (application crash)…
>> etc.
>>
>> Do you want to expose such lib to the potential attacker?
>> --
>> Pavel Janík
>>
>>
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:43:52

- reply

📅 Original date posted:2015-10-22
📝 Original message:Benchmarks?
I cant imagine that's very fast.
On 10/22/2015 02:26 PM, Jeff Garzik via bitcoin-dev wrote:
> Here is the beginnings of an implementation to replace leveldb with
> sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite
>
> It builds, but still needs work before passing tests.
>
> It was noted that leveldb is unmaintained, and this is part of
> researching alternatives that are maintained and reliable.
>
>
>
>
> _______________________________________________
> 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/20151022/a4fb1966/attachment.html>

2023-06-07 17:40:55

- reply

📅 Original date posted:2015-09-18
📝 Original message:Full nodes using UTXO set commitments is a change to the bitcoin
security model.
Currently an attacker with >50% of the network hashrate can rewrite history.
If full nodes rely on UTXO set commitments such an attacker could create
an infinite number of bitcoins (as in many times more than the current
21 million bitcoin limit).
Before we consider mechanisms for UTXO set commitments, we should
seriously discuss whether the security model reduction is reasonable.
On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> Currently, when a new node wants to join the network, it needs to retrieve the entire blockchain history, starting from January 2009 and up until now, in order to derive a UTXO set that it can verify new blocks/transactions against. With a blockchain size of 40GB and a UTXO size of around 1GB, the extra bandwidth required is significant, and will keep increasing indefinitely. If a newly mined block were to include the UTXO set hash of the chain up until the previous block — the hash of the UTXO set on top of which this block builds — then new nodes, who want to know whether a transaction is valid, would be able to acquire the UTXO set in a trustless manner, by only verifying proof-of-work headers, and knowing that a block with an invalid UTXO set hash would be rejected.
>
> I’m not talking about calculating a complicated tree structure from the UTXO set, which would put further burden on already burdened Bitcoin Core nodes. We simply include the hash of the current UTXO set in a newly created block, such that the transactions in the new block build *on top* of the UTXO set whose hash is specified. This actually alleviates Bitcoin Core nodes, as it will now become possible for nodes without the entire blockchain to answer SPV queries (by retrieving the UTXO set trustlessly and using this to answer queries). It also saves bandwidth for Bitcore Core nodes, who only need to send roughly 1GB of data, in order to synchronise a node, rather than 40GB+. I will continue to run a full Bitcoin Core node, saving the entire blockchain history, but it shouldn’t be a requirement to hold the entire transaction history in order to start verifying new transactions.
>
> As far as I can see, this also forces miners to actually maintain an UTXO set, rather than just build on top of the chain with the most proof-of-work. Producing a UTXO set and verifying a block against a chain is the same thing, so by including the hash of the UTXO set we force miners to verify the block that they want to build on top of.
>
> Am I missing something obvious, because as far as I can see, this solves the problem of quadratic time complexity for initial sync: http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
>
> The only added step to verifying a block is to hash the UTXO set. So it does require additional computation, but most modern CPUs have a SHA256 throughput of around 500 MB/s, which means it takes only two seconds to hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s). A small sacrifice for the added ease of initial syncing, in my opinion.
>
> /Rune
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:38:15

- reply

📅 Original date posted:2015-08-27
📝 Original message:Are you aware of the prior work in this field?
https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/
On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
> Hi,
>
> I am proposing to create a AML-KYC module to control the network and
> also qualify use cases in OFAC compliant way.
> Here is the attached doc.
>
> Please provide your feedback and suggestions.
>
> Best,
> Prabhat Kumar Singh
>
>
> _______________________________________________
> 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/20150827/427f2fc0/attachment.html>

2023-06-07 17:36:47

- reply

📅 Original date posted:2015-08-18
📝 Original message:First of all I would like to say... LOL
Second Andrew LeCody is correct, this is off topic.
On 08/18/2015 04:31 PM, F L via bitcoin-dev wrote:
> Bitcoin XT contains an unmentioned addition which periodically
> downloads lists of Tor IP addresses for blacklisting, this has
> considerable privacy implications for hapless users which are being
> prompted to use the software. The feature is not clearly described,
> is enabled by default, and has a switch name which intentionally
> downplays what it is doing (disableipprio). Furthermore these claimed
> anti-DoS measures are trivially bypassed and so offer absolutely no
> protection whatsoever.
>
> Connections are made over clearnet even when using a proxy or
> onlynet=tor, which leaks connections on the P2P network with the real
> location of the node. Knowledge of this traffic along with uptime
> metrics from bitnodes.io can allow observers to easily correlate the
> location and identity of persons running Bitcoin nodes. Denial of
> service can also be used to crash and force a restart of an
> interesting node, which will cause them to make a new request to the
> blacklist endpoint via the clearnet on relaunch at the same time their
> P2P connections are made through a proxy. Requests to the
> blacklisting URL also use a custom Bitcoin XT user agent which makes
> users distinct from other internet traffic if you have access to the
> endpoints logs.
>
>
> https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
>
>
>
> _______________________________________________
> 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/20150818/081aad9b/attachment.html>

2023-06-07 17:36:18

- reply

📅 Original date posted:2015-08-17
📝 Original message:Nobody is going to click that...
On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> 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/20150817/7ba96795/attachment-0001.html>

2023-06-07 17:36:03

- reply

📅 Original date posted:2015-08-16
📝 Original message:The first question to answer here is simple:
What value would there be in requiring a minimum block size?
I see no value.
On 08/16/2015 05:30 PM, Jeff Garzik via bitcoin-dev wrote:
> "minimum" an interesting topic.
>
> - Traffic levels may not produce a minimum size block
> - Miners can always collude to produce a lowered maximum block size, a
> sort of minimum maximum
>
>
>
> On Sun, Aug 16, 2015 at 12:41 PM, Levin Keller via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hey everyone,
>
> as with the current "max block size" debate I was wondering: Is
> anyone here in favor of a minimum block size (say 2 MB or so)? If
> so I would be interested in an exchange (maybe off-list) of ideas.
> I am in favor of a lower limit and am giving it quite a bit of
> thought at the moment.
>
> Cheers
>
> Levin
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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/20150816/32305f4e/attachment.html>

2023-06-07 17:33:10

- reply

📅 Original date posted:2015-08-10
📝 Original message:If a path cannot be built to the recipient through the lightning network
then a standard transaction should be used.
On 08/10/2015 01:27 AM, Thomas Zander via bitcoin-dev wrote:
> On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote:
>> I thought it's worth mentioning there is a specific Lightning Network
>> development mailing list at
>> http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
>> some pretty interesting explanations in the archives.
> While that is interesting, and I'll surely check it out, I think this list
> should get a good idea of what the limitations are.
>
> Where does it NOT make sense to use LN, where would it be better to put the
> transaction directly on the blockchain?
>
> This is what I'd like to know.
>
> Gavins usecase is useful, I'm also wondering about remittances and allowing
> international payments and global economy (company in Nairobi buys stock from
> company in Spain).

2023-06-07 17:33:09

- reply

📅 Original date posted:2015-08-09
📝 Original message:That was not in reply to you.
On 08/09/2015 03:09 PM, Hector Chu wrote:
> Right, you've stated a bunch of facts, but how does it answer my
> concerns of the exploding cost of the network the more interconnected
> it it?
>
> On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I suspect there is some amount of confusion here on terms.
>
> The hub is essentially swapping funds between payment channels.
>
> The hub's entire business is centered around having payment
> channels open with other hubs/users.
>
> If the hub requires user funds to open these channels... then the
> users have no reason to pay the hub anything in fees.
>
> A hub that doesn't use it's own funds to open payment channels to
> other hubs/merchants is useless.
>
>
> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org
>> <mailto:mark at friedenbach.org>> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the
>> creation of the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if
>> it does, Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether
>> the fee depends on the amount deposited, and whether it depends
>> on the amount of time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of
>> fees. Can you guess it?
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/03767706/attachment.html>

2023-06-07 17:33:08

- reply

📅 Original date posted:2015-08-09
📝 Original message:I suspect there is some amount of confusion here on terms.
The hub is essentially swapping funds between payment channels.
The hub's entire business is centered around having payment channels
open with other hubs/users.
If the hub requires user funds to open these channels... then the users
have no reason to pay the hub anything in fees.
A hub that doesn't use it's own funds to open payment channels to other
hubs/merchants is useless.
On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org
> <mailto:mark at friedenbach.org>> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation
> of the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it
> does, Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the
> fee depends on the amount deposited, and whether it depends on the
> amount of time it stays there.
>
> I predict "all of the above." There is a name for these kinds of
> fees. Can you guess it?
>
>
>
> _______________________________________________
> 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/20150809/81b04cea/attachment-0001.html>

2023-06-07 17:33:07

- reply

📅 Original date posted:2015-08-09
📝 Original message:On the contrary those costs are clearly very low.
Both the time value of money and operating expenses will be trivial with
even a small volume of transactions.
The true cost of operating a hub is clearly in the enhanced risk of loss.
It's clear that risk of loss will be moderated by market forces.
The hubs which are better at securing their systems will reduce their
risk of loss and obtain a competitive advantage.
It's also important to note that the risk of loss is the same whether
the hub is doing 1 transaction/second or 1 million transactions/second.
At 1 transaction/second the cost (but not necessarily the fees) is going
to be quite high.
At 1 million transactions/second the cost is going to be very very low.
On 08/09/2015 03:03 PM, Hector Chu wrote:
> Ok good. We have established it to be a non-trivial cost.
> Now, what is the growth complexity of the total cost of the network in
> terms of number of connections each hub has to other hubs? And then,
> consider a payment channel with many hops in it. The end-to-end users
> would have to swallow all the costs of the hubs in the channel.
>
> On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> The costs of operating a hub are as follows:
>
> Time value of the funds the Hub has locked up in payment channels.
> Enhanced risk of loss of control of private keys (the keys
> necessarily need to be on an internet connected system).
> Operating costs (I expect this will be minimal).
>
> The hub can charge a fee for it's services to recoup these costs.
>
>
> On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
>> Tom, my understanding is that the money that is debited from a
>> payment hub is simultaneously credited from either another
>> payment hub or the person making the payment, so that the net
>> funds flow at a payment hub always sums to zero. So no, there is
>> no credit advanced by the payment hub to anyone.
>>
>> Given Mark's previous answer of using CPFP and other tricks to
>> pay for the Bitcoin transaction fees, we can assume that Bitcoin
>> fees do not play a part in the payment channel balances.
>>
>> So, the interesting question is what are the costs of running a
>> payment hub? The tx fees that a payment hub would have to pay to
>> settle its Bitcoin transactions would be passed on as a cost to
>> the clients of the payment hub. Also there is a cost to locking
>> up funds in a payment channel (time value of money). The lost
>> interest or opportunity cost on those funds would need to be paid
>> for by its clients as well. And don't forget normal running costs
>> such as networking and electricity.
>>
>> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"
>> <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of the channel.
>> There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and
>> if it does, Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds,
>> whether the fee depends on the amount deposited, and whether
>> it depends on the amount of time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds
>> of fees. Can you guess it?
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/07c84557/attachment.html>

2023-06-07 17:33:07

- reply

📅 Original date posted:2015-08-10
📝 Original message:> I would be surprised if the rates charged to consumers for BTC credit
aren't much closer to today's BTC borrowing rates.
The borrowing rates you're talking about involve the risk of default.
In lightning the hubs funds are not at risk so long as they maintain
control of the private keys.
The rates charged by hubs will almost certainly be orders of magnitude
below the rates charged on the various p2p lending sites....
But that seems fairly obvious... did I miss something?
On 08/09/2015 06:52 PM, Tom Harding via bitcoin-dev wrote:
> On 8/9/2015 2:45 PM, Hector Chu wrote:
>> Tom, my understanding is that the money that is debited from a payment
>> hub is simultaneously credited from either another payment hub or the
>> person making the payment, so that the net funds flow at a payment hub
>> always sums to zero.
>
> That describes the steady-state dynamics. I refer to the hub funding
> required to initiate and maintain the ability to receive payments.
>
> If Bob opens a channel at his hub, doesn't use it for spending, and
> Alice sends 1 BTC to the channel, her payment can only be applied if the
> hub has funded the channel with at least 1 BTC.
>
> Yes, the hub receives an offsetting payment (from Alice, ultimately) in
> another channel. But to make this work, it must subject 1 BTC to shared
> control with Bob and forfeit the use of that money for other purposes
> (opportunity cost) while the channel is open. The opportunity cost is
> likened to gold lease rates in the LN paper. I would be surprised if
> the rates charged to consumers for BTC credit aren't much closer to
> today's BTC borrowing rates. We'll see.
>
> Burying this cost in general fees might not work very well, because
> different Bobs may want different maximum payment amounts, and channels
> open for different lengths of time.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:33:06

- reply

📅 Original date posted:2015-08-09
📝 Original message:The costs of operating a hub are as follows:
Time value of the funds the Hub has locked up in payment channels.
Enhanced risk of loss of control of private keys (the keys necessarily
need to be on an internet connected system).
Operating costs (I expect this will be minimal).
The hub can charge a fee for it's services to recoup these costs.
On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero. So no, there is no credit advanced by the payment
> hub to anyone.
>
> Given Mark's previous answer of using CPFP and other tricks to pay for
> the Bitcoin transaction fees, we can assume that Bitcoin fees do not
> play a part in the payment channel balances.
>
> So, the interesting question is what are the costs of running a
> payment hub? The tx fees that a payment hub would have to pay to
> settle its Bitcoin transactions would be passed on as a cost to the
> clients of the payment hub. Also there is a cost to locking up funds
> in a payment channel (time value of money). The lost interest or
> opportunity cost on those funds would need to be paid for by its
> clients as well. And don't forget normal running costs such as
> networking and electricity.
>
> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org
> <mailto:mark at friedenbach.org>> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit
> involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it
> does, Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether
> the fee depends on the amount deposited, and whether it depends on
> the amount of time it stays there.
>
> I predict "all of the above." There is a name for these kinds of
> fees. Can you guess it?
>
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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/20150809/862c0d23/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-18
📝 Original message:Relay nodes do not need a mempool, but do need some mechanism to avoid
DoS issues.
Wallet nodes can use the mempool for fee estimation (in addition to
looking at past blocks).
On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote:
> As in, do relay nodes need to keep a record of the transactions they've
> relayed? Strictly speaking, the answer is no: one a tx is relayed modulo
> DoS concerns the entire thing can be discarded by the node. (unconfirmed
> txs spending other unconfirmed txs can be handled by creating packages
> of transactions, evaluated as a whole)
>
> To mitigate DoS concerns, we of course have to have some per-UTXO limit
> on bandwidth relayed, but that task can be accomplished by simply
> maintaining some kind of per-UTXO record of bandwidth used. For instance
> if the weighted fee and fee/KB were recorded, and forced to - say -
> double for each additional tx relayed that spent a given UTXO you would
> have a clear and simple upper limit of lifetime bandwidth. Equally it's
> easy to limit bandwidth moment to moment by asking peers for highest
> fee/KB transactions they advertise first, stopping when our bandwidth
> limit is reached.
>
> You probably could even remove IsStandard() pretty much entirely with
> the right increasingly expensive "replacement" policy, relying on it
> alone to provide anti-DoS. Obviously this would simplify some of the
> debates around mining policy! This could even be re-used for scalable a
> general-purpose messaging network paid by coin ownership if the UTXO set
> is split up, and some kind of expiration over time policy is
> implemented.
>
> Miners of course would still want to have a mempool, but that codebase
> may prove simpler if it doesn't have to work double-duty for relaying as
> well.
>
>
>
> _______________________________________________
> 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/20150718/55ceedea/attachment.html>

2023-06-07 15:41:07

- reply

📅 Original date posted:2015-06-28
📝 Original message:Fraud proofs need to be at least more efficient than full node validation.
Currently they are not.
On 06/27/2015 09:54 PM, Eric Lombrozo wrote:
> Fraud proofs actually don’t need to be made super efficient…but they do need to be secure, of course.
>
> The trick is aligning incentives. In order for fraud proofs to be widely available there needs to be a market for them - there must be a way to buy one (because producing one is not free). What makes such a scheme actually practical is that very few of these fraud proofs ever need to actually be executed - it’s a classical Nimzowischian case of the threat being much stronger than the execution.
>
> - Eric Lombrozo
>
>> On Jun 27, 2015, at 7:13 PM, Patrick Strateman <patrick.strateman at gmail.com> wrote:
>>
>>> Further, it appears clear that the original author intended
>> organizations operating full network nodes would provide connectivity to
>> light clients and these light clients would make up the majority of the
>> user base.
>>
>> Satoshi also believed that fraud proofs would be widely available and
>> practical.
>>
>> If fraud proofs were practical SPV client security would be much closer
>> to full node security than it is today.
>>
>> Unfortunately no design for fraud proofs which is both efficient and
>> secure has been proposed; much less implemented and deployed.
>>
>> In building a system as new and innovative as bitcoin certain things
>> will be wrong.
>>
>> The perception that SPV clients could be made nearly as secure as full
>> nodes is one example of something that was wrong.
>>
>> On 06/27/2015 05:14 PM, Santino Napolitano wrote:
>>> There is much heated debate going on right now and I know it can be very stressful but I'd like to point out that it is really amazing how passionately so many feel about this once very small project. Let's not forget there is something really special going on here and we're all part of it.
>>>
>>> The current debate has little to do with block size or hard-forks, IMO. It's about the nature of Bitcoin and what it means to people and how it will grow. I would like to take a moment to share my interpretation of the original author's intent based on everything I could find and read from this person. This is not to say their original vision is paramount-- or even that I got it completely correct but I think it might do us some good to think about.
>>>
>>> It seems as though the incentive conceived of for running a full network node was that it would enable mining. The proceeds from mining (new coins and transaction fees) would be the reward and provide a reason to continue operating these nodes. If fees are ever to be a sufficient reward and still allow for a practical and useful system the size of the blocks must grow significantly as must the user base. I'm not sure that this is really contested but I haven't exhaustively reviewed everyone's opinion so please excuse me if I have marginalized you. If you do contest that I would be interested in hearing it.
>>>
>>> Further, it appears clear that the original author intended organizations operating full network nodes would provide connectivity to light clients and these light clients would make up the majority of the user base. This is completely consistent with current trends in Internet consumption, e.g. tablets and phones are becoming more preferred to even owning a traditional computer. Having the system be entirely decentralized and trustless for every client does not appear to me to be the original design goal. Yes, the whitepaper speaks of the design goal as not having a need for a trusted third party but it does not say that some amount of trust won't be preferred by a majority of users. In fact, in the SPV section it implies some amount of localized trust is perhaps a necessary trade-off and maybe businesses should still run their own full network node if they want the stronger completely trustless guarantee. The global decentralized consensus appears meant to make the network
>> r
>>> esilient to a single government or other adversary's ability to shut the network down. If you really want to trust no one it is your option at a cost and should be possible by design. The author further gives evidence that they believe Moore's observation would keep the idea of running a full network node a practical one at global scale for perpetuity. It does not appear as if they intended for every individual to run one at home nor in their pocket.
>>>
>>> If my interpretation seems incorrect please do point it out. I hope this hasn't been too off-topic and distracting. The original author's engineering ingenuity is what gave me any interest in this project so re-visiting their design and scaling intentions might be helpful for us to move forward-- together.
>>>
>>> _______________________________________________
>>> 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 15:41:06

- reply

📅 Original date posted:2015-06-27
📝 Original message:> Further, it appears clear that the original author intended
organizations operating full network nodes would provide connectivity to
light clients and these light clients would make up the majority of the
user base.
Satoshi also believed that fraud proofs would be widely available and
practical.
If fraud proofs were practical SPV client security would be much closer
to full node security than it is today.
Unfortunately no design for fraud proofs which is both efficient and
secure has been proposed; much less implemented and deployed.
In building a system as new and innovative as bitcoin certain things
will be wrong.
The perception that SPV clients could be made nearly as secure as full
nodes is one example of something that was wrong.
On 06/27/2015 05:14 PM, Santino Napolitano wrote:
> There is much heated debate going on right now and I know it can be very stressful but I'd like to point out that it is really amazing how passionately so many feel about this once very small project. Let's not forget there is something really special going on here and we're all part of it.
>
> The current debate has little to do with block size or hard-forks, IMO. It's about the nature of Bitcoin and what it means to people and how it will grow. I would like to take a moment to share my interpretation of the original author's intent based on everything I could find and read from this person. This is not to say their original vision is paramount-- or even that I got it completely correct but I think it might do us some good to think about.
>
> It seems as though the incentive conceived of for running a full network node was that it would enable mining. The proceeds from mining (new coins and transaction fees) would be the reward and provide a reason to continue operating these nodes. If fees are ever to be a sufficient reward and still allow for a practical and useful system the size of the blocks must grow significantly as must the user base. I'm not sure that this is really contested but I haven't exhaustively reviewed everyone's opinion so please excuse me if I have marginalized you. If you do contest that I would be interested in hearing it.
>
> Further, it appears clear that the original author intended organizations operating full network nodes would provide connectivity to light clients and these light clients would make up the majority of the user base. This is completely consistent with current trends in Internet consumption, e.g. tablets and phones are becoming more preferred to even owning a traditional computer. Having the system be entirely decentralized and trustless for every client does not appear to me to be the original design goal. Yes, the whitepaper speaks of the design goal as not having a need for a trusted third party but it does not say that some amount of trust won't be preferred by a majority of users. In fact, in the SPV section it implies some amount of localized trust is perhaps a necessary trade-off and maybe businesses should still run their own full network node if they want the stronger completely trustless guarantee. The global decentralized consensus appears meant to make the network r
> esilient to a single government or other adversary's ability to shut the network down. If you really want to trust no one it is your option at a cost and should be possible by design. The author further gives evidence that they believe Moore's observation would keep the idea of running a full network node a practical one at global scale for perpetuity. It does not appear as if they intended for every individual to run one at home nor in their pocket.
>
> If my interpretation seems incorrect please do point it out. I hope this hasn't been too off-topic and distracting. The original author's engineering ingenuity is what gave me any interest in this project so re-visiting their design and scaling intentions might be helpful for us to move forward-- together.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:40:34

- reply

📅 Original date posted:2015-06-26
📝 Original message:Planning for a hard forks which change the consensus rules (including
the blocksize limit) is something we can all agree is worthy of time and
effort.
However there is clearly not consensus sufficient today to deploy a hard
fork that changs the blocksize without there being serious and
potentially experiment ending consequences.
For a proposed hard fork to reach a level of consensus necessary to be
safe requires that there be a clear and self evident course of action.
That simply does not exist on the blocksize limit question.
On 06/26/2015 11:23 AM, Jeff Garzik wrote:
> Failure to plan now for a hard fork increase 6(?) months in the future
> produces that lumpy, unpredictable market behavior.
>
> The market has baked in the years-long behavior of low fees. From the
> market PoV, inaction does lead to precisely that, a sudden change over
> the span of a few months.
>
> At a higher level, people look at bitcoin and see people delaying,
> waiting, dawdling until the barn is actually on fire before taking
> action to put out the fire.
>
> They see a system that is not responsive to higher level externalities
> of people & businesses making plans for the future. Based on current
> proposal of change-through-inaction, businesses will simply shelve
> plans to use bitcoin and not bother putting those new users on the
> network.
>
> If you wait until the need to increase block size is acute, it is
> already too late. (1) Businesses have permanently shelved plans to
> use bitcoin and (2) change at that point produces _larger_ disruption
> to the fee market.
>
> Hard forks require planning many months in advance. Gavin's timing is
> sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal.
>
>
>
>
>
>
>
> On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
>
> I am not saying that economic change is what we want. Only that it
> is inevitable, independent of whether larger blocks happen or not.
>
> I am saying that acting because of fear of economic change is a
> bad reason. The reason for increase should be because of the
> higher utility. We need it at some point, but there should be no rush.
>
> I do understand that we want to avoid a *sudden* change in
> economic policy, but I'm generally not too worried. Either fees
> increase and they get paid, and we're good. But more likely is
> that some uses just move off-chain because the block chain does
> not offer what they need. That's sad, but it is inevitable at any
> size: some uses fit, some don't.
>
> --
> Pieter
>
> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com
> <mailto:jgarzik at gmail.com>> wrote:
>
> It is not "fear" of fee pressure.
>
> 1) Blocks are mostly not-full on average.
>
> 2) Absent long blocks and stress tests, there is little fee
> pressure above the anti-spam relay fee metric, because of #1.
>
> 3) As such, inducing fee pressure is a delta, a change from
> years-long bitcoin economic policy. Each time we approach the
> soft limit, Bitcoin Core increases the soft limit to prevent
> "full" blocks. Mike Hearn et. al. lobbies miners to upgrade.
>
> (note - this is not an endorsement of these actions - it is a
> neutral observation)
>
> 4) Inaction leads to consistent fee pressure as the months
> tick on and system volume grows; thus, inaction leads to
> economic policy change.
>
> 5) Economic policy change leads to market and software
> disruption. The market and software - notably wallets - is
> not prepared for this.
>
> 6) If you want to change economic policy, that's fine. But be
> honest and admit you are arguing for a change, a delta from
> current market expectations and behavior.
>
> 7) It is critical to first deal with what _is_, not what you
> wish the world to be. You want a fee market to develop.
> There is nothing wrong with that desire. It remains a delta
> from where we are today, and that is critically relevant in a
> $3b+ market.
>
>
>
>
>
>
>
>
> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
>
> Hello all,
>
> here I'm going to try to address a part of the block size
> debate which has been troubling me since the beginning:
> the reason why people seem to want it.
>
> People say that larger blocks are necessary. In the long
> term, I agree - in the sense that systems that do not
> evolve tend to be replaced by other systems. This
> evolution can come in terms of layers on top of Bitcoin's
> blockchain, in terms of the technology underlying various
> aspects of the blockchain itself, and also in the scale
> that this technology supports.
>
> I do, however, fundamentally disagree that a fear for a
> change in economics should be considered to necessitate
> larger blocks. If it is, and there is consensus that we
> should adapt to it, then there is effectively no limit
> going forward. This is similar to how Congress voting to
> increase the copyright term retroactively from time to
> time is really no different from having an infinite
> copyright term in the first place. This scares me.
>
> Here is how Gavin summarizes the future without increasing
> block sizes in PR 6341:
>
> > 1. Transaction confirmation times for transactions with
> a given fee will rise; very-low-fee transactions will fail
> to get confirmed at all.
> > 2. Average transaction fee paid will rise
> > 3. People or applications unwilling or unable to pay the
> rising fees will stop submitting transactions
> > 4. People and businesses will shelve plans to use
> Bitcoin, stunting growth and adoption
>
> Is it fair to summarize this as "Some use cases won't fit
> any more, people will decide to no longer use the
> blockchain for these purposes, and the fees will adapt."?
>
> I think that is already happening, and will happen at any
> scale. I believe demand for payments in general is nearly
> infinite, and only a small portion of it will eventually
> fit on a block chain (independent of whether its size is
> limited by consensus rules or economic or technological
> means). Furthermore, systems that compete with Bitcoin in
> this space already offer orders of magnitude more capacity
> than we can reasonably achieve with any blockchain
> technology at this point.
>
> I don't know what subset of use cases Bitcoin will cater
> to in the long term. They have already changed - you see
> way less betting transactions these days than a few years
> ago for example - and they will keep changing, independent
> of what effective block sizes we end up with. I don't
> think we should be afraid of this change or try to stop it.
>
> If you look at graphs of block sizes over time (for
> example, http://rusty.ozlabs.org/?p=498), it seems to me
> that there is very little "organic" growth, and a lot of
> sudden changes (which could correspond to changing
> defaults in miner software, introduction of popular
> sites/services, changes in the economy). I think these can
> be seen as the economy changing to full up the available
> space, and I believe these will keep happening at any size
> effectively available.
>
> None of this is a reason why the size can't increase.
> However, in my opinion, we should do it because we believe
> it increases utility and understand the risks; not because
> we're afraid of what might happen if we don't hurry up.
> And from that point of view, it seems silly to make a huge
> increase at once...
>
> --
> Pieter
>
>
> _______________________________________________
> 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
>
>
>
>
>
> _______________________________________________
> 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/20150626/6adbfdb4/attachment-0001.html>

2023-06-07 15:39:55

- reply

📅 Original date posted:2015-06-22
📝 Original message:If you truly have a consensus then the rational behavior is to
permanently change the nodes behavior after the trigger.
On 06/22/2015 02:21 PM, Gavin Andresen wrote:
> On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
> > Since it's possible that block timestamps aren't chronological
> in order, what would happen if a block following a size increase
> trigger is back in the past before the size increase? Would that
> block have a lower size restriction again? Would using block
> height not be a more stable number to work with?
>
> In the nVersion bits proposal that I co-authored we solved that
> issue by
> comparing the timestamp against the median time, which is
> guaranteed by
> the protocol rules to monotonically advance.
>
>
> That complicates the implementation quite a bit.
>
> I mostly implemented a variant that replaced the MAX_BLOCK_SIZE
> constant with a function that took both a timestamp and a block
> height, and there are several places in the current reference
> implementation where digging out the block height (or, worse,
> calculating the median timestamp for the block) would involve changing
> quite a few functions in the call-chain or acquiring the cs_main lock
> to consult the current best chain.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20150622/7494ff4d/attachment-0001.html>

2023-06-07 15:35:46

- reply

📅 Original date posted:2015-05-27
📝 Original message:There is absolutely no reason to do this.
Any reasonable micro-controller can build merkle tree roots
significantly faster than is necessary.
1 Th/s walks the nonce range once every 4.3ms.
The largest valid merkle trees are 14 nodes high.
That translates to 28 SHA256 ops per 4.3ms or 6511 SHA256 ops/second.
For reference an RPi 1 model B does 2451050 SHA256 ops/second.
On 05/27/2015 03:52 PM, Sergio Lerner wrote:
> I like the idea but I think we should leave at least 16 bits of the
> version fixed as an extra-nonce.
> If we don't then miners may use them as a nonce anyway, and mess with
> the soft-fork voting system.
> My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102
>
> Best regards
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:03:51

- reply

📅 Original date posted:2013-06-21
📝 Original message:It's well answered by this stack exchange question.
http://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence
On 06/20/2013 05:54 PM, Marko Otbalkana wrote:
> Could anyone tell me what CTxIn::nSequence is meant for?
>
> Best Regards,
> -Marko
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130620/1e2140bf/attachment.html>

2023-06-07 15:02:55

- reply

📅 Original date posted:2013-06-05
📝 Original message:If you're only interested in storing the best chain then a fairly simple
schema is possible.
CREATE TABLE blocks (
hash bytea NOT NULL PRIMARY KEY,
index integer NOT NULL UNIQUE,
CONSTRAINT block_hash_size_check CHECK ((octet_length(hash) = (256 /
8)))
);
CREATE TABLE transaction_inputs (
output_transaction_id bytea NOT NULL,
output_index integer NOT NULL,
block_index integer NOT NULL,
CONSTRAINT transaction_id_size_check CHECK
((octet_length(output_transaction_id) = (256 / 8))),
PRIMARY KEY (output_transaction_id, output_index)
);
CREATE INDEX transaction_inputs_block_index_idx ON transaction_inputs
USING btree (block_index)
CREATE TABLE transaction_outputs (
transaction_id bytea NOT NULL,
index integer NOT NULL,
amount numeric(16,8) NOT NULL,
type character varying NOT NULL,
addresses character varying[],
block_index integer NOT NULL,
spent boolean DEFAULT false NOT NULL,
CONSTRAINT transaction_id_size_check CHECK
((octet_length(transaction_id) = (256 / 8))),
PRIMARY KEY (transaction_id, index)
);
CREATE INDEX transaction_outputs_addresses_idx ON transaction_outputs
USING gin (addresses);
CREATE INDEX transaction_outputs_block_index_idx ON transaction_outputs
USING btree (block_index);
On 06/05/2013 05:53 PM, Marko Otbalkana wrote:
> Could anyone point me to work/project(s) related to storing the block
> chain in a database, like PostgreSQL, MySQL? How about any tools that
> can read the block chain from the Satoshi client and convert it into
> different formats?
>
> Thanks,
> -Marko
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130605/3673d6e4/attachment.html>