<unnamed>

Public Key

npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd

Profile Code

nprofile1qqsydxr0s6uhejtc9xsrrvpjp9jy6y6tjwwszceh23nlpvfk8cxcwhspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds76evgv

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-09 14:47:01 CEST

- reply

📅 Original date posted:2017-02-06
📝 Original message:
On Mon, Feb 6, 2017 at 4:32 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I think you do not need the second timeout.
>
> TX2 would be signed by Bob only once he could get back the second Output
> of TX1.
>
Alice must have a fully signed version of TX2 before the timeout finishes.
If she doesn't, then Bob can reclaim TX1/1 once the timeout expires and
then refuse to sign TX2.
If Alice has a signed version of TX2, then she can broadcast it and
immediately close the channel (claiming TX1/0).
Once that has been accepted, she can then claim TX1/1.
> So Bob does not have to worry about Alice closing the channel with TX2.
>
> Nicolas,
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170206/8a33414e/attachment.html>

2023-06-09 14:47:00 CEST

- reply

📅 Original date posted:2017-02-06
📝 Original message:
I created a possible step by step protocol with checks that each step is
safe.
I think your scheme needs a 2nd timeout, so Bob has a time between Alice
broadcasting AliceSecret and Alice closing the channel with TX2.
TX1
Input
1 from Alice
1 from Bob
Output
1: (Alice + Bob + timeout(2T)) OR (Bob + AliceSecret)
1: (Bob + timeout(T)) OR (Alice + AliceSecret)
TX2
Input
TX1:1: signed by (Alice + Bob)
Output
Initial channel paying Alice 100%
Process:
Step 1
Alice creates TX1, signs it and sends it to Bob.
If Alice refuses this step, then nothing has happened, so it is a safe
abort.
Step 2
Bob signs it and sends Alice the tx hash.
Bob could sign and broadcast it. If he does that, then Alice spends her
output to get her money back, so it is a safe abort.
If Bob refuses to complete this step, Alice should spend her input to
prevent Bob broadcasting the TX1 later. This is also a safe abort.
NOTE:
* This is an ongoing check Alice must perform.
* If (timeout / 2) passes before all the steps are completed, Alice should
try to
** double spend her input into TX1
** spend her output from TX1
Step 3
Alice creates TX2, signs it and sends it to Bob.
If Alice refuses to complete this step, then Bob simply discards TX1.
Alice can't broadcast it since she does not have a fully signed version of
TX1.
Step 4
Bob signs TX2 and sends it to Alice.
If Bob refuses to complete this step, the Alice should spend her input or
her output of TX1 (if Bob has broadcast TX1). This is a safe abort.
Step 5
Bob broadcasts TX1
If Bob refuses to complete this step, the Alice should spend her input.
This is a safe abort.
Step 6
Alice should make sure TX1 is included in the chain without mutation.
If it is ok, then Alice does nothing.
If it is mutated, then Alice should spend her output immediately.
If Alice refuses to complete this step, then Bob can reclaim his money
after the timeout and Alice loses access to her money. Alice has an
incentive to complete this step.
Step 7 (mutated TX only)
Bob can spend his output using AliceSecret.
If Bob refuses to complete this step, then he doesn't get his money, but
Alice is not harmed.
Step 7 (valid setup)
Bob spends his output after the timeout. Once he has spent his output,
then the channel is setup.
There is a potential race condition here.
After the timeout has expired, Alice could broadcast 2 transactions
- TX2 (to close the channel paying Alice 100%)
- transaction to spend TX1/1 (i.e. Alice + Alice secret)
Bob would be broadcasting his transaction to claim TX1/1 at around the same
time.
The network might accept Alice's 2 transactions, before Bob has a chance to
claim TX1/0 (with Bob + AliceSecret).
Adding an extra timeout with the later expiry to TX1/0 means that Alice
cannot broadcast TX2 until Bob has a chance to claim his output.
On Mon, Feb 6, 2017 at 2:25 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> Alice opening channel of 1BTC
>
> Input:
> 1 BTC From Alice
> 1 BTC From Bob
> Output:
> 1 BTC Alice+Bob OR Bob+AliceSecret
> 1 BTC Bob+Timeout OR Alice+AliceSecret (aka the bounty)
>
> If bob is unresponsive, Alice can get the bounty.
> If Alice unresponsive, bob can get the bounty after timeout.
> If Alice takes the bounty, Bob can take the escrow .
>
> If Alice responsive, bob wait for getting the bounty. The use of the
> channel will start after bob get the bounty back.
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170206/ea7b8785/attachment.html>

2023-06-07 20:26:34 CEST

- reply

📅 Original date posted:2020-08-17
📝 Original message:On Mon, Aug 17, 2020 at 6:04 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Taproot MAST to the rescue.
>
Another option would be a binary payout
You pay 64 + 32 + 16 + 8 + 4 + 2 + 1 as outputs. The outputs are
enabled/disabled based on the diff value. This would require division and
also binary operators.
D = (int) ((100 * diff) / (1 trillion))
Output 0: 1.28: If (D & 128) then pay Alice otherwise Bob
Output 0: 0.64: If (D & 64) then pay Alice otherwise Bob
Output 0: 0.32: If (D & 32) then pay Alice otherwise Bob
Output 0: 0.16: If (D & 16) then pay Alice otherwise Bob
Output 0: 0.8: If (D & 8) then pay Alice otherwise Bob
Output 0: 0.4: If (D & 4) then pay Alice otherwise Bob
Output 0: 0.4: If (D & 4) then pay Alice otherwise Bob
Output 0: 0.4: If (D & 4) then pay Alice otherwise Bob
This has log performance in terms of the number of ticks like the MAST
solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200817/a3fd8bd8/attachment.html>

2023-06-07 20:26:33 CEST

- reply

📅 Original date posted:2020-08-16
📝 Original message:On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My understanding is that adding a single op_difficulty operation as
> proposed would enable not true difficulty futures but binary options
> on difficulty.
>
> https://en.wikipedia.org/wiki/Binary_option
Any kind of opcode is a binary option. Either the output can be spent or
it can't.
You could get a pseudo-continuous future by having lots of outputs with
different thresholds.
Alice and Bob create a transaction with 100 outputs and each having 1% of
the future's value.
Output 0: Pay Alice if diff < 1.00 trillion else Bob
Output 1: Pay Alice if diff < 1.01 trillion else Bob
....
Output 98: Pay Alice if diff < 1.98 trillion else Bob
Output 99: Pay Alice if diff < 1.99 trillion else Bob
If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob
gets outputs 25-99. The future has a tick size of 1%. It isn't very
efficient though
It would be good to have the option to specify a block height for the
future too. If it triggered on block time, then miners have an incentive
to give false block times.
I am not clear if there is a way to solve the accounting for the
> payouts, but perhaps there is a way to do this with covenants.
>
I agree you would need covenants or something similar.
There needs to be a way to check the outputs (value and script) of the
spending transaction. You also need a way for Alice and Bob to create
their spending transaction in sequence.
Output 0: Pay Alice if [output value 0] <= Diff / 1 trillion AND [output
value 1] >= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
To spend her output, Alice has to create a transaction which pays Bob and
assigns the coins in the right ratio. [output value x] means the output
value of the spending transaction for output x.
To get it to work Alice creates a transaction with these restrictions
Output 0:
Script: Anything (Alice gets it to pay herself)
Value: <= Diff / 1 trillion
Output 1:
Script: Must pay to Bob
Value: >= (2 trillion - Diff) / 1 trillion
You also need to handle overflows with the calculations.
Bob can then spend output 1 and get his money.
There is a hold-up risk if Alice doesn't spend her money. You can make the
output script so either of them can spend their coins to avoid that.
Output 0:
Pay Alice if [output value 0] <= Diff / 1 trillion AND [output value 1]
>= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
OR
Pay Bob if [output value 0] <= (2 trillion - Diff) / 1 trillion AND
[output value 1] >= Diff / (1 trillion) AND [output 1 pays to Alice]
You would need a covenant-like instruction to check the output values and
scripts and the diff opcode to get the difficulty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200816/63df27eb/attachment.html>

2023-06-07 20:10:24 CEST

- reply

📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> *2.* Timestamps are not necessary to avoid double-spending. A simple
> ordering of blocks is sufficient, so exchanging timestamps with enumeration
> would work double-spending wise. Permissioned consensus protocols, such as
> hyperledger, indeed have no timestamps (in version 1.0).
>
The timestamps simply needs to be reasonably accurate. Their main purpose
is to allow difficulty updates.
They can also be used to check that the node has caught up.
> It uses a simple average of block time in the last 2016 blocks. But such
> averages ignore any values besides the first and last one in the interval.
> Hence, if the difficulty is constant, the following sequence is valid from
> both the protocol and the miners incentives point of views:
>
> 1, 2, 3,…., 2015, 1209600 (time of two weeks), 2017, 2018, 2019,….,
> 4031, 1209600*2, 4033, 4044, …
>
Much of Bitcoin operates on the assumption that a majority of miners are
honest. If 50%+ of miners set their timestamp reasonably accurately (say
within 10 mins), then the actual timestamp will move forward at the same
rate as real time.
Dishonest miners could set their timestamp as low as possible, but the
median would move foward if more than half of the timestamps move forward.
> If we want to be pedantic, the best lower bound for a block timestamp is
> the timestamp of the block that closes the adjustment interval in which it
> resides.
>
If you are assuming that the miners are majority dishonest, then they can
set the limit to anything as long as they don't move it more than 2 hours
into the future.
The miners could set their timestamps so that they increase 1 week fake
time every 2 weeks real time and reject any blocks more than 2 hours ahead
of their fake time. The difficulty would settle so that one block occurs
every 20 mins.
>
> Possible improvement:
> -----------------------------
> We may consider exchanging average with standard deviation in the
> difficulty adjustment formula. It both better mirrors changes in the hash
> power along the interval, and disables the option to manipulate timestamps
> without affecting the difficulty.
>
> I'm aware that this change requires a hardfork, and won't happen any time
> soon. But does it make sense to add it to a potential future hard fork?
>
For check locktime, the median of the last 11 blocks is used as an improved
indicator of what the actual real time is. Again, it assumes that a
majority of the miners are honest.
>
>
> _______________________________________________
> 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/20180129/0d61ce0b/attachment.html>

2023-06-07 20:08:40 CEST

- reply

📅 Original date posted:2017-12-11
📝 Original message:On Mon, Dec 11, 2017 at 9:56 PM, Jim Posen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Omitting nBits entirely seems reasonable, I wrote up a possible
> implementation here
> <https://github.com/bitcoin/bitcoin/compare/master...jimpo:compact-headers-difficulty>.
> The downside is that it is more complex because it leaks into the
> validation code. The extra 4 byte savings is certainly nice though.
>
A compromise would be to have 1 byte indicating the difference since the
last header.
Since the exponent doesn't use the full range you could steal bits from
there to indicate mode.
- no change
- mantissa offset (for small changes)
- full difficulty
This would support any nBits rule and you say 3 of the 4 bytes.
> Can you elaborate on how parallel header fetching might work? getheaders
> requests could probably already be pipelined, where the node requests the
> next 2,000 headers before processing the current batch (though would make
> sense to check that they are all above min difficulty first).
>
I suggest adding a message where you can ask for the lowest N hashes
between 2 heights on the main chain.
The reply is an array of {height, header} pairs for the N headers with the
lowest hash in the specified range.
All peers should agree on which headers are in the array. If there is
disagreement, then you can at least narrow down on which segment there is
disagreement.
It works kind of like a cut and choose. You pick one segment of the ones
he gave you recursively.
You can ask a peer for proof for a segment between 2 headers of the form.
- first header + coinbase with merkle branch
- all headers in the segment
This proves the segment has the correct height and that all the headers
link up.
There is a method called "high hash highway" that allows compact proofs of
total POW.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171211/76d17ddf/attachment-0001.html>

2023-06-07 20:05:24 CEST

- reply

📅 Original date posted:2017-09-06
📝 Original message:On Tue, Sep 5, 2017 at 10:51 PM, Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>
Someone could have created a timelocked transaction that depends on a zero
value output.
This could be protected by requiring a tx version number change. Only zero
outputs in the new version would be affected.
I am not sure how strictly people are sticking to that rule though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/ea09555c/attachment.html>

2023-06-07 19:54:44 CEST

- reply

📅 Original date posted:2016-12-14
📝 Original message:On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
> In a sum tree, however, since the nSigOp is implied, any redefinition
> requires either a hardfork or a new sum tree (and the original sum tree
> becomes a placebo for old nodes. So every softfork of this type creates a
> new tree)
>
That's a good point.
> The only way to fix this is to explicitly commit to the weight and nSigOp,
> and the committed value must be equal to or larger than the real value.
> Only in this way we could redefine it with softfork. However, that means
> each tx will have an overhead of 16 bytes (if two int64 are used)
>
The weight and sigop count could be transmitted as variable length
integers. That would be around 2 bytes for the sigops and 3 bytes for the
weight, per transaction.
It would mean that the block format would have to include the raw
transaction, "extra"/tree information and witness data for each transaction.
On an unrelated note, the two costs could be combined into a unified cost.
For example, a sigop could have equal cost to 250 bytes. This would make
it easier for miners to decide what to charge.
On the other hand, CPU cost and storage/network costs are not completely
interchangeable.
Is there anything that would need to be summed fees, raw tx size, weight
and sigops that the greater or equal rule wouldn't cover?
On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.
linuxfoundation.org> wrote:
On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:
> > Any new merkle algorithm should use a sum tree for partial validation and
> > fraud proofs.
>
> PR welcome.
>
Fair enough. It is pretty basic.
https://github.com/luke-jr/bips/pull/2
It sums up sigops, block size, block cost (that is "weight" right?) and
fees.
_______________________________________________
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/20161214/42189554/attachment.html>

2023-06-07 19:54:44 CEST

- reply

📅 Original date posted:2016-12-14
📝 Original message:On Wed, Dec 14, 2016 at 3:45 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
> I think that’s too much tech debt just for softforkability.
>
> The better way would be making the sum tree as an independent tree with a
> separate commitment, and define a special type of softfork (e.g. a special
> BIP9 bit).
>
One of the problems with fraud proofs is withholding by miners. It is
important that proof of publication/archive nodes check that the miners are
actually publishing their blocks.
If you place the data in another tree, then care needs to be taken that the
merkle path information can be obtained for that tree.
If an SPV node asks for a run of transactions from an archive node, then
the archive node can give the merkle branch for all of those transactions.
The archive node inherently has to check that tree.
The question is if there is a way to show that data is not available, but
without opening up the network to DOS. If enough people run full nodes
then this isn't a problem.
>
> When the softfork is activated, the legacy full node will stop validating
> the sum tree. This doesn’t really degrade the security by more than a
> normal softfork, as the legacy full node would still validate the total
> weight and nSigOp based on its own rules. The only purpose of the sum tree
> is to help SPV nodes to validate. This way we could even completely
> redefine the structure and data committed in the sum tree.
>
Seems reasonable. I think the soft-fork would have to have a timeout
before actually activating. That would give SPV clients time to switch
over.
That could happen before the vote though, so it isn't essential. The SPV
clients would have to support both trees and then switch mode. Ensuring
that SPV nodes actually bother would be helped by proving that the network
actually intends to soft fork.
The SPV client just has to check that every block has at least one of the
commitments that it accepts so that it can understand fraud proofs.
>
> I’d like to combine the size weight and sigOp weight, but not sure if we
> could. The current size weight limit is 4,000,000 and sigop limit is
> 80,000. It’s 50:1. If we maintain this ratio, and define
> weight = n * (total size + 3 * base size) + sigop , with n = 50
> a block may have millions of sigops which is totally unacceptable.
>
You multiplied by the wrong term.
weight = total size + 3 * base size + n * sigop , with n = 50
weight for max block = 8,000,000
That gives a maximum of 8,000,000 / 50 = 160,000 sigops.
To get that you would need zero transaction length. You could get close if
you have transactions that just repeat OP_CHECKSIG over and over (or maybe
something with OP_CHECKMULTISIG).
>
> On the other hand, if we make n too low, we may allow either too few
> sigop, or a too big block size.
>
> Signature aggregation will make this a bigger problem as one signature may
> spend thousands of sigop
>
>
>
> On 14 Dec 2016, at 20:52, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>
>
> On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
>
>> In a sum tree, however, since the nSigOp is implied, any redefinition
>> requires either a hardfork or a new sum tree (and the original sum tree
>> becomes a placebo for old nodes. So every softfork of this type creates a
>> new tree)
>>
>
> That's a good point.
>
>
>> The only way to fix this is to explicitly commit to the weight and
>> nSigOp, and the committed value must be equal to or larger than the real
>> value. Only in this way we could redefine it with softfork. However, that
>> means each tx will have an overhead of 16 bytes (if two int64 are used)
>>
>
> The weight and sigop count could be transmitted as variable length
> integers. That would be around 2 bytes for the sigops and 3 bytes for the
> weight, per transaction.
>
> It would mean that the block format would have to include the raw
> transaction, "extra"/tree information and witness data for each transaction.
>
> On an unrelated note, the two costs could be combined into a unified
> cost. For example, a sigop could have equal cost to 250 bytes. This would
> make it easier for miners to decide what to charge.
>
> On the other hand, CPU cost and storage/network costs are not completely
> interchangeable.
>
> Is there anything that would need to be summed fees, raw tx size, weight
> and sigops that the greater or equal rule wouldn't cover?
>
> On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev
>> wrote:
>> > Any new merkle algorithm should use a sum tree for partial validation
>> and
>> > fraud proofs.
>>
>> PR welcome.
>>
>
> Fair enough. It is pretty basic.
>
> https://github.com/luke-jr/bips/pull/2
>
> It sums up sigops, block size, block cost (that is "weight" right?) and
> fees.
> _______________________________________________
> 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/20161214/9774c7f0/attachment-0001.html>

2023-06-07 19:54:43 CEST

- reply

📅 Original date posted:2016-12-10
📝 Original message:On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Something not yet done:
> 1. The new merkle root algorithm described in the MMHF BIP
>
Any new merkle algorithm should use a sum tree for partial validation and
fraud proofs.
Is there something special about 216 bits? I guess at most 448 bits total
means only one round of SHA256. 16 bits for flags would give 216 for each
child.
Even better would be to make the protocol extendable. Allow blocks to
indicate new trees and legacy nodes would just ignore the extra ones. If
Bitcoin supported that then the segregated witness tree could have been
added as a easier soft fork.
The sum-tree could be added later as an extra tree.
> 3. Communication with legacy nodes. This version can’t talk to legacy
> nodes through the P2P network, but theoretically they could be linked up
> with a bridge node
>
The bridge would only need to transfer the legacy blocks which are coinbase
only, so very little data.
> 5. Many other interesting hardfork ideas, and softfork ideas that works
> better with a header redesign
>
That is very true.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/f53e0cac/attachment.html>

2023-06-07 19:54:43 CEST

- reply

📅 Original date posted:2016-12-11
📝 Original message:On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:
> > Any new merkle algorithm should use a sum tree for partial validation and
> > fraud proofs.
>
> PR welcome.
>
Fair enough. It is pretty basic.
https://github.com/luke-jr/bips/pull/2
It sums up sigops, block size, block cost (that is "weight" right?) and
fees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/0455d03e/attachment.html>

2023-06-07 19:54:18 CEST

- reply

📅 Original date posted:2016-11-16
📝 Original message:On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Are checkpoints good now? Are hard forks okay now?
>
I think that at least one checkpoint should be included. The assumption is
that no 50k re-orgs will happen, and that assumption should be directly
checked.
Checkpointing only needs to happen during the headers-first part of the
download.
If the block at the BIP-65 height is checkpointed, then the comparisons for
the other ones are automatically correct. They are unnecessary, since the
checkpoint protects all earlier block, but many people would like to be
able to verify the legacy chain.
This makes the change a soft-fork rather than a hard fork. Chains that
don't go through the checkpoint are rejected but no new chains are allowed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/da3702fc/attachment.html>

2023-06-07 19:52:13 CEST

- reply

📅 Original date posted:2016-08-06
📝 Original message:On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> * reversal of transactions is impossible
>
I think it would be more accurate to say that the requirement is that
reversal doesn't happen unexpectedly.
If it is clear in the script that reversal is possible, then obviously the
recipient can take that into consideration.
> * keep private keys private and safe. Lose them, it's like losing cash,
> you can just forget about it.
>
Key management is a thing. Managing risk by keeping some keys offline is
an important part of that.
> * while we try hard to make 0-conf as safe as possible (if there's no
> RBF flag on the transaction), we make it almost impossible or very very
> expensive to reverse a confirmed transaction.
>
BitGo has an "instant" system where they promise to only sign one
transaction for a given output. If you trust BitGo, then this is safe from
double spending, since a double spender can't sign two transactions.
If BitGo had actually implemented a daily withdrawal limit, then their
system ends up similar to cold storage. Only 10% of the funds at Bitfinex
could have been withdrawn before manual intervention was required (with
offline keys).
Who will accept
> such an input and treat it as a payment if it can be reversed during the
> settlement layer?
Obviously, if a payment is reversible, then you treat it as a reversible
payment. The protection here relates to moving coins from the equivalent
of cold storage to hot storage.
It is OK if it takes longer, since security is more important than
convenience for coins in cold storage.
> The linked page describes that merchants will never accept payments from
> 'vaults', and it will take 24 hours for coins to be irreversible moved
> outside the 'vault'.
This relates to the reserves held by the exchange. A portion of the funds
are in hot storage with live keys. These funds can be stolen by anyone who
gets access to the servers. The remaining funds are held in cold storage
and they cannot be accessed unless you have the offline keys. These funds
are supposed to be hard to reach and require manual intervention.
I think this is a wrong approach. hacks and big losses are sad, but all
> the time users / exchanges are to blame for wrong implementations or
> terrible security practices.
>
Setting up offline keys to act as firebreaks is part of good security
practices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160806/7bcdc140/attachment-0001.html>

2023-06-07 19:52:11 CEST

- reply

📅 Original date posted:2016-08-03
📝 Original message:On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism;
>
I think reversing transactions is not likely to be acceptable. You could
add an opcode that requires that an output be set to something.
[target script] SPENDTO
This would require that [target script] is the script for the corresponding
output. This is a purely local check.
For example, if SPENDTO executes as part of the script for input 3, then it
checks that output 3 uses the given script as its scriptPubKey. The value
of input 3 and output 3 would have to be the same too.
This allows check sequence verify to be used to lock the spending script
for a while. This doesn't allow reversal, but would give a 24 hour window
where the spenders can reverse the transaction.
[IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
key> CHECKSIG] SPENDTO <live public key2> CHECKSIG
Someone with the live public key can create a transaction that spends the
funds to the script in the square brackets.
Once that transaction hits the blockchain, then someone with the <offline
protected key> has 24 hours to spend the output before the person with the
live keys can send the funds onward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/3e551535/attachment-0001.html>

2023-06-07 19:50:28 CEST

- reply

📅 Original date posted:2016-05-10
📝 Original message:The various chunks in the double SHA256 are
Chunk 1: 64 bytes
version
previous_block_digest
merkle_root[31:4]
Chunk 2: 64 bytes
merkle_root[3:0]
nonce
timestamp
target
Chunk 3: 64 bytes
digest from first sha pass
Their improvement requires that all data in Chunk 2 is identical except for
the nonce. With 4 bytes, the birthday paradox means collisions can be
found reasonable easily.
If hard forks are allowed, then moving more of the merkle root into the 2nd
chunk would make things harder. The timestamp and target could be moved
into chunk 1. This increases the merkle root to 12 bytes in the 2nd
chunk. Finding collisions would be made much more difficult.
If ASIC limitations mean that the nonce must stay where it is, this would
mean that the merkle root would be split into two pieces.
On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
> What's the best way to do this? Ideally this would be SPV compatible, but
> if it
> requires changes from SPV clients that's ok too. Also the fix this should
> be
> compatible with existing mining hardware.
>
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20160510/cb6a2690/attachment.html>

2023-06-07 19:49:30 CEST

- reply

📅 Original date posted:2016-03-02
📝 Original message:On Wed, Mar 2, 2016 at 4:27 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> For example, it is theoretically possible that 100% of miners (not 50%
> or 10%) will shut off their hardware. This is because it is revenue
> which ~halves, not profit.
It depends on how much is sunk costs and how much is marginal costs too.
If hashing costs are 50% capital and 50% marginal, then the entire network
will be able to absorb a 50% drop in subsidy.
50% capital costs means that the cost of the loan to buy the hardware
represents half the cost.
Assume that for every $100 of income, you have to pay $49 for the loan and
$49 for electricity giving 2% profit. If the subsidy halves, then you only
get $50 of income, so lose $48.
But if the bank repossesses the operation, they might as well keep things
running for the $1 in marginal profit (or sell on the hardware to someone
who will keep using it).
Since this drop in revenue is well known in advance, businesses will spend
less on capital. That means that there should be less mining hardware than
otherwise.
A 6 month investment with 3 months on the high subsidy and 3 months on low
subsidy would not be made if it only generated a small profit for the first
3 and then massive losses for the 2nd period of 3 months. For it to be
made, there needs to be large profit during the first period to compensate
for the losses in the 2nd period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/1b50893e/attachment-0001.html>

2023-06-07 19:49:13 CEST

- reply

📅 Original date posted:2016-02-18
📝 Original message:I wrote a bip last year about extended transaction information. The idea
was to include the scriptPubKey that was being spent along with
transactions.
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki
This makes it easier possible to verify the transactions locally. An
extended transaction would contain the current transaction and also the
CTxOuts that are being spent.
For each entry in the UTXO set, a node could store
UTXO_hash = hash(txid_parent | n | CTxOut)
Witness transactions will do something similar. I wonder if it would be
possible to include the CTxOut for each input that isn't a segregated
witness output, as part of the witness data. Even for witness data, it
would be good to commit to the value of the output as part of the witness.
There was a suggestion at one of the conferences to have the witness data
include info about the block height/index of the output that each input is
spending.
The effect of this change is that nodes would only have to store the
UTXO_hashes for each UTXO value in the database. This would make it much
more efficient.
It would also make it easier to create a simple consensus library. You
give the library the transaction and the witness and it returns the
UTXO_hashes that are spent, the UTXO_hashes that are created, the fee,
sigops and anything that needs to be summed.
Validating a block would mostly (famous last words) mean validating the
transactions in the block and then adding up the totals.
The advantage of including the info with the transactions is that it saves
each node having to include a lookup table to find the data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160218/231703a0/attachment.html>

2023-06-07 19:48:30 CEST

- reply

📅 Original date posted:2016-02-04
📝 Original message:On Thu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> No, the "triggering block" you mentioned is NOT where the hardfork starts.
> Using BIP101 as an example, the hardfork starts when the first >1MB is
> mined. For people who failed to upgrade, the "grace period" is always zero,
> which is the moment they realize a hardfork.
Clients have to update in some way to get the benefit of this right?
An SPV client which fully validated the header chain would simply reject
the hard forking header. Last time I checked, the Bitcoinj SPV wallet
ignored the version bits, and just followed the longest chain. Is that
still the case?
In fact, does Core enforce the 95% rule for the soft-forks before checking
for long forks? I am assuming that it happens when checking headers rather
than when checking full blocks.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/d79be3a8/attachment.html>

2023-06-07 19:47:47 CEST

- reply

📅 Original date posted:2016-01-11
📝 Original message:On Fri, Jan 8, 2016 at 3:46 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> How many years until we think a 2^84 attack where the work is an ECDSA
> private->public key derivation will take a reasonable amount of time?
>
I think the EC multiply is not actually required. With compressed public
keys, the script selection rule can just be a sha256 call instead.
V is the public key of the victim, and const_pub_key is the attacker's
public key.
if prev_hash % 2 == 0:
script = "2 V 0x02%s 2 CHECKMULTISIG" % (sha256(prev_hash)))
else:
script = "CHECKSIG %s OP_DROP" % (prev_hash, const_pub_key)
next_hash = ripemd160(sha256(script))
If a collision is found, there is a 50% chance that the two scripts have
different parity and there is a 50% chance that a compressed key is a valid
key.
This means that you need to run the algorithm 4 times instead of 2.
The advantage is that each step is 2 sha256 calls and a ripemd160 call. No
EC multiply is required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160111/be7bd486/attachment.html>

2023-06-07 19:47:09 CEST

- reply

📅 Original date posted:2015-12-26
📝 Original message:On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Unfortunately, this also means longer confirmation times, lower
> throughput, and lower miner revenue. Note, however, that confirmations
> would (on average) represent more PoW, so fewer confirmations would be
> required to achieve the same level of security.
>
No, the re-target compensates so that the number of blocks in the last two
weeks is 2016. If a soft fork forces miners to throw away 25% of their
blocks, then the difficulty will drop by 75% to keep things balanced.
Throwing away 75% of blocks has the same effect on difficulty as destroying
75% of mining hardware.
The block interval will only increase until the next re-target.
Slowly increasing the fraction of blocks which are thrown away gives the
re-target algorithm time to adjust, so it is another advantage.
If the rule was instantly changed so that 95% of blocks were thrown away,
then there could be up to 40 weeks until the next retarget and that would
give 200 minute block times until the adjustment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/c9da101f/attachment.html>

2023-06-07 19:47:01 CEST

- reply

📅 Original date posted:2015-12-20
📝 Original message:On Sun, Dec 20, 2015 at 12:42 PM, Natanael <natanael.l at gmail.com> wrote:
> If total difficulty is X and the ratio for full blocks to candidate blocks
> shared with the pool is Y, then the candidate block PoW now has to meet X/Y
> while hashing the candidate block PoW + the pool's commitment hash must
> meet Y, which together makes for X/Y*Y and thus the same total difficulty.
This gives the same total difficulty but miners are throwing away otherwise
valid blocks.
This means that it is technically a soft fork. All new blocks are valid
according to the old rule.
In practice, it is kind of a hard fork. If Y is 10, then all upgraded
miners are throwing away 90% of the blocks that are valid under the old
rules.
>From the perspective of non-upgraded clients, the upgraded miners operate
at a 10X disadvantage.
This means that someone with 15% of the network power has a majority of the
effective hashing power, since 15% is greater than 8.5% (85% * 0.1).
The slow roll-out helps mitigate this though. It gives non-upgraded
clients time to react. If there is only a 5% difference initially, then
the attacker doesn't get much benefit.
The main differences are that there's a public key identifier the miners
> are told about in advance and expect to see in block templates, and that
> that now the pool has to publish this commitment value together with the
> block that also contains the commitment hash, and that this is verified
> together with the PoW.
I don't think public keys are strictly required. Registering them with
DNSSEC is way over the top. They can just publish the key on their website
and then use that for their identity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/d23c9ae8/attachment.html>

2023-06-07 19:47:01 CEST

- reply

📅 Original date posted:2015-12-20
📝 Original message:On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> An attacker pool (A) can take a certain portion of its hashpower,
> use it to mine on behalf of victim pool (B), furnish partial proofs of work
> to B, but discard any full blocks it discovers.
>
I wonder if part of the problem here is that there is no pool identity
linked to mining pools.
If the mining protocols were altered so that miners had to indicate their
identity, then a pool couldn't forward hashing power to their victim.
If the various mining protocols were updated, they could allow checking
that the work has the domain name of the pool included. Pools would have
to include their domain name in the block header.
A pool which provides this service is publicly saying that they will not
use the block withholding attack. Any two pools which are doing it cannot
attack each other (since they have different domain names). This creates
an incentive for pools to start supporting the feature.
Owners of hashing power also have an incentive to operate with pools which
offer this identity. It means that they can ensure that they get a payout
from any blocks found.
Hosted mining is weaker, but even then, it is possible for mining hosts to
provide proof that they performed mining. This proof would include the
identity of the mining pool. Even if the pool was run by the host, it
would still need to have the name embedded.
Mining hosts might be able to figure out which of their customers actually
check the identity info, and then they could redirect the mining power of
those who generally don't check. If customers randomly ask for all of the
hashing power, right back to when they joined, then this becomes expensive.
Mining power directly owned by the pool is also immune to this effect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/feb0d395/attachment.html>

2023-06-07 19:46:21 CEST

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We are not avoiding a choice. We don't have the authority to make a choice.
>
This is really the most important question.
Bitcoin is kind of like a republic where there is separation of powers
between various groups.
The power blocs in the process include
- Core Devs
- Miners
- Exchanges
- Merchants
- Customers
Complete agreement is not required for a change. If merchants and their
customers were to switch to different software, then there is little any of
the other groups could do.
Consensus is nice, certainly, and it is a good social norm to seek
widespread agreement before committing to a decision above objection.
Committing to no block increase is also committing to a decision against
objections.
Having said that, each of the groups are not equal in power and
organisation.
Merchants and their customers have potentially a large amount of power, but
they are disorganised. There is little way for them to formally express a
view, much less put their power behind making a change. Their potential
power is crippled by public action problems.
On the other extreme is the core devs. Their power is based on legitimacy
due to having a line of succession starting with Satoshi and respect gained
due to technical and political competence. Being a small group, they are
organised and they are also more directly involved.
The miners are less centralised, but statements supported by the majority
of the hashing power are regularly made. The miners' position is that they
want dev consensus. This means that they have delegated their decision
making to the core devs.
The means that the two most powerful groups in Bitcoin have given the core
devs the authority to make the decision. They don't have carte blanche
from the miners.
If the core devs made the 2MB hard-fork with a 75% miner threshold, it is
highly likely that the other groups would accept it.
That is the only authority that exists in Bitcoin. The check is that if
the authority is abused, the other groups can simply leave (or use
checkpointing)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/35172889/attachment.html>

2023-06-07 19:46:16 CEST

- reply

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
There is a risk that miners would eventually react by just refusing to
accept blocks that spend dormant outputs. This is a risk even without the
protocol, but I think if there are already lots of UTXO-lite nodes
deployed, it would be much easier to just define them as the new
(soft-forked) consensus rule.
There is a precedent for things to be disabled rather than fixed when
security problems arise.
Imagine a crisis caused by a security related bug with the revival proofs.
Disabling them is much lower risk than trying to find/fix the bug and then
deploy the fix. The longer it takes, the longer the security problem
remains.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
Is this how it works?
Source transaction is included in block Y.
If the output is spent before Y + 420,000, then no further action is taken.
The miner for block Y + 420,000 will include a commitment to
merkle_hash(Block Y's unspent outputs).
It is possible for someone to prove that they didn't spend their
transaction before Y + 420,000.
I think the miners have to remember the "live" UTXO merkle root for every
block?
With the path to the UTXO and the miner can recalculate the root for that
block.
If there were 20 dormant outputs being spent, then the miner would have to
commit to 20 updates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/a4cf6d21/attachment.html>

2023-06-07 19:45:38 CEST

- reply

📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 5:41 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> A far better place than the generation transaction (which I assume means
> coinbase transaction?) is the last transaction in the block. That allows
> you to save, on average, half of the hashes in the Merkle tree.
>
This trick can be improved by only using certain tx counts. If the number
of transactions is limited to a power of 2 (other than the extra
transactions), then you get a path of length zero.
The number of non-zero bits in the tx count determings how many digests are
required.
https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
This gets the benefit of a soft-fork, while also keeping the proof lengths
small. The linked bip has a 105 byte overhead for the path.
The cost is that only certain transaction counts are allowed. In the worst
case, 12.5% of transactions would have to be left in the memory pool. This
means around 7% of transactions would be delayed until the next block.
Blank transactions (or just transactions with low latency requirements)
could be used to increase the count so that it is raised to one of the
valid numbers.
Managing the UTXO set to ensure that there is at least one output that pays
to OP_TRUE is also a hassle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/99821607/attachment.html>

2023-06-07 19:44:18 CEST

- reply

📅 Original date posted:2015-11-06
📝 Original message:I meant not to use the OP_PUSH opcodes to do the push.
Does OP_0 give a zero length byte array?
Would this script return true?
OP_0
OP_PUSHDATA1 (length = 1, data = 0)
OP_EQUAL
The easiest definition is that OP_0 and OP_1 must be used to push the data
and not any other push opcodes.
On Fri, Nov 6, 2015 at 9:32 AM, Oleg Andreev <oleganza at gmail.com> wrote:
>
> > One and zero should be defined as arrays of length one. Otherwise, it is
> still possible to mutate the transaction by changing the length of the
> array.
> >
> > They should also be minimally encoded but that is covered by previous
> rules.
>
> These two lines contradict each other. Minimally-encoded "zero" is an
> array of length zero, not one. I'd suggest defining this explicitly here as
> "IF/NOTIF argument must be either zero-length array or a single byte 0x01".
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151106/435de781/attachment.html>

2023-06-07 19:44:17 CEST

- reply

📅 Original date posted:2015-11-06
📝 Original message:One and zero should be defined as arrays of length one. Otherwise, it is
still possible to mutate the transaction by changing the length of the
array.
They should also be minimally encoded but that is covered by previous rules.
On Fri, Nov 6, 2015 at 8:13 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have a new BIP draft for fixing OP_IF and OP_NOTIF malleability. Please
> comment:
> https://github.com/jl2012/bips/blob/master/opifmalleability.mediawiki
>
> Copied below:
>
> BIP: x
> Title: Dealing with OP_IF and OP_NOTIF malleability
> Author: jl2012 <jl2012 at xbt.hk>
> Status: Draft
> Type: Standards Track
> Created: 2015-11-06
>
> Abstract
>
> As an supplement to BIP62, this document specifies proposed changes to the
> Bitcoin transaction validity rules in order to make malleability of
> transactions with OP_IF and OP_NOTIF impossible.
>
> Motivation
>
> OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system.
> The programme flow is decided by whether the top stake value is 0 or not.
> However, this behavior opens a source of malleability as a third party may
> alter a non-zero flow control value to any other non-zero value without
> invalidating the transaction.
>
> As of November 2015, OP_IF and OP_NOTIF are not commonly used in the
> blockchain. However, as more sophisticated functions such as
> OP_CHECKLOCKTIMEVERITY are being introduced, OP_IF and OP_NOTIF will become
> more popular and the related malleability should be fixed. This proposal
> serves as a supplement to BIP62 and should be implemented with other
> malleability fixes together.
>
> Specification
>
> If the transaction version is 3 or above, the flow control value for OP_IF
> and OP_NOTIF must be either 0 or 1, or the transaction fails.
>
> This is to be implemented with BIP62.
>
> Compatibility
>
> This is a softfork. To ensure OP_IF and OP_NOTIF transactions created
> before the introduction of this BIP will still be accpeted by the network,
> the new rules only apply to transactions of version 3 or above.
>
> For people who want to preserve the original behaviour of OP_IF and
> OP_NOTIF, an OP_0NOTEQUAL could be used before the flow control code to
> transform any non-zero value to 1.
>
> Reference
>
> BIP62: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
>
> _______________________________________________
> 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/20151106/d815e1ae/attachment.html>

2023-06-07 19:44:00 CEST

- reply

📅 Original date posted:2015-11-01
📝 Original message:On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think it is very important to make it clear that non-standard txs and
> non-standard scripts may become invalid in the future
>
There can be unavoidable situations which cause locked coins become
unspendable.
In an ideal world, soft forks that make UTXOs unspendable should increase
the tx version number. BIP-13 should have done that. That would make the
change opt-in.
The disabled opcodes like OP_CAT were a DOS/network security change.
Invalidating locked coins is another reason that they shouldn't have been
disabled permanently.
It would have been better to disable them for six months, so at least
people can get their coins back after that. Inherently, protecting the
network required some limitations being added so that nodes couldn't be
crashed.
For guidelines
* Transaction version numbers will be increased, if possible
* Transactions with unknown/large version numbers are unsafe to use with
locktime
* Reasonable notice is given that the change is being contemplated
* Non-opt-in changes will only be to protect the integrity of the network
Locked transaction that can be validated without excessive load on the
network should be safe to use, even if non-standard.
An OP_CAT script that requires TBs of RAM to validate crosses the threshold
of reasonableness.
>
> Gavin Andresen via bitcoin-dev 於 2015-10-28 10:06 寫到:
>
>> I'm hoping this fits under the moderation rule of "short-term changes
>> to the Bitcoin protcol" (I'm not exactly clear on what is meant by
>> "short-term"; it would be lovely if the moderators would start a
>> thread on bitcoin-discuss to clarify that):
>>
>> Should it be a requirement that ANY one-megabyte transaction that is
>> valid
>> under the existing rules also be valid under new rules?
>>
>> Pro: There could be expensive-to-validate transactions created and
>> given a
>> lockTime in the future stored somewhere safe. Their owners may have no
>> other way of spending the funds (they might have thrown away the
>> private
>> keys), and changing validation rules to be more strict so that those
>> transactions are invalid would be an unacceptable confiscation of
>> funds.
>>
>> Con: It is extremely unlikely there are any such large, timelocked
>> transactions, because the Core code has had a clear policy for years
>> that
>> 100,000-byte transactions are "standard" and are relayed and
>> mined, and
>> larger transactions are not. The requirement should be relaxed so that
>> only
>> valid 100,000-byte transaction under old consensus rules must be valid
>> under new consensus rules (larger transactions may or may not be
>> valid).
>>
>> I had to wrestle with that question when I implemented BIP101/Bitcoin
>> XT
>> when deciding on a limit for signature hashing (and decided the right
>> answer was to support any "non-attack"1MB transaction; see
>> https://bitcoincore.org/~gavin/ValidationSanity.pdf [1] for more
>> details).
>>
>> --
>>
>> --
>> Gavin Andresen
>>
>>
>> Links:
>> ------
>> [1] https://bitcoincore.org/~gavin/ValidationSanity.pdf
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/ba76df82/attachment.html>

2023-06-07 19:43:40 CEST

- reply

📅 Original date posted:2015-10-19
📝 Original message:On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As with the previous version, which was using a hard-fork, the normalized
> transaction ID is computed only considering the non-malleable parts of a
> transaction, i.e., stripping the signatures before computing the hash of
> the transaction.
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
Is this proposal recursive?
*Coinbase transaction *
* n-txid = txid
*Non-coinbase transactions*
* replace sigScripts with empty strings
* replace txids in TxIns with n-txid for parents
The 2nd step is recursive starting from the coinbases.
In effect, the rule is that txids are what they would have been if n-txids
had been used right from the start.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151019/c7c17563/attachment.html>

2023-06-07 19:41:31 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
There never was a rule that soft-forks require total consensus. It is
desirable but not mandatory.
A majority of miners can inherently implement a soft fork against the
wishes of the rest of the users.
Merchant/exchange/user checkpointing is the defense and therefore is a
perfectly valid response to miners taking such an action. If a soft fork
is opposed by a large section of the users, then threatening (and
implementing) a checkpoint is the correct response.
No group can force through a hard fork, it inherently requires buy-in from
a large portion of the userbase. That is where the "total consensus"
requirement comes from. Naturally, absolute total consensus isn't actually
required but you do need very large consensus and also consensus across the
various sub-groups.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/0a0f7108/attachment.html>

2023-06-07 19:40:09 CEST

- reply

📅 Original date posted:2015-09-16
📝 Original message:On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> I couldn't see a use for it, since partial enforcement of a soft fork is
> pretty useless.
>
It isn't useful for actually using the feature, but some miners might set
the bit but not actually create blocks that comply with the new rule.
This would cause their blocks to be orphaned until they fixed it.
OK, *that* variant makes perfect sense, and is no more complex, AFAICT.
>
> So, there's two weeks to detect bad implementations, then you everyone
> stops setting the bit, for later reuse by another BIP.
>
It could be more than two weeks if the support stays between 80% and 90%
for a while.
75%+ checks that blocks with the bit set follow the rule.
95%+ enters lock-in and has the same rules as 75%+, but is irreversible at
that point.
> You need a timeout: an ancient (non-mining, thus undetectable) node
> should never fork itself off the network because someone reused a failed
> BIP bit.
>
I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and
the other is "AGAINST". If against hits 25%, then it is deemed a failure.
The 2nd bit wouldn't be used normally. This means that proposals can be
killed quickly if they are obviously going to fail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/c60f2225/attachment.html>

2023-06-07 19:36:59 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What problem am I missing if we just mask of the offending bits. For my
> own project which uses auxpow (and thus has weird nVersion), I also used
> the bitmasking method to get rid of auxpow version bits before making the
> standard integer comparisons to deploy BIP66 using IsSuperMajority():
>
> if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...))
> { //...}
>
What if version number 257 is used in the future? That would appear to be
a version 1 block and fail the test.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/aeb28a8e/attachment.html>

2023-06-07 19:36:28 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:One of the comments made by the mining pools is that they won't run XT
because it is "experimental".
Has there been any consideration to making available a version of XT with
only the blocksize changes?
The least "experimental" version would be one that makes the absolute
minimum changes to core.
The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip
changes. This saves creating a new function.
Without the consensus measuring code, the patch would be even easier.
Satoshi's proposal was just a block height comparison (a year in advance).
The state storing code is also another complication. If the standard
"counting" upgrade system was used, then no state would need to be stored
in the database.
On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla at riseup.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> (My replies below)
>
> On 06/26/2015 06:47 AM, Tier Nolan wrote:
> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam at cypherspace.org
> > <mailto:adam at cypherspace.org>> wrote:
> >
> > The hard-cap serves the purpose of a safety limit in case our
> > understanding about the economics, incentives or game-theory is
> > wrong worst case.
> >
> >
> > True.
>
> Yep.
>
> >
> > BIP 100 and 101 could be combined. Would that increase consensus?
>
> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
> is a better alternative to Gavin's proposal(s), but that I didn't
> think that this should be taken to mean that I am saying one thing is
> "superior" to Gavin's work, rather, I emphasized that Gavin work with
> Jeff and Adam.
>
> At least, at this stage the things are in a BIP process.
>
> If the BIP 100 and BIP 101 would be combined, what would that look
> like on paper?
>
> >
> > - Miner vote threshold reached - Wait notice period or until
> > earliest start time - Block size default target set to 1 MB - Soft
> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -
> > Miner vote to decide soft limit (lowest size ignoring bottom 20%
> > but 1MB minimum)
> >
> > Block size updates could be aligned with the difficulty setting
> > and based on the last 2016 blocks.
> >
> > Miners could leave the 1MB limit in place initially. The vote is
> > to get the option to increase the block size.
> >
> > Legacy clients would remain in the network until >80% of miners
> > vote to raise the limit and a miner produces a >1MB block.
> >
> > If the growth rate over-estimates hardware improvements, the devs
> > could add a limit into the core client. If they give notice and
> > enough users update, then miners would have to accept it.
> >
> > The block size becomes min(miner's vote, core devs). Even if 4
> > years notice is given, blocks would only be 4X optimal.
> >
> >
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=
> =rtTH
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/8f7d94b9/attachment.html>

2023-06-07 19:36:20 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I haven't run any statistics or simulations, but I'm concerned that the
> interplay between the random distribution of transaction arrival and the
> random distribution of block times may lead to false signals.
>
You could just take the average of all the block sizes for the last 2016
window.
If average of last 2016 > 50% of the limit, then increase by 6.25%
Otherwise, decrease by 6.25%
This means that the average would be around 50% of the limit. This gives
margin to create larger blocks when blocks are happening slowly.
A majority of miners could force the limit upwards by creating spam but
full blocks.
It could be coupled with a hard limit that grows at whatever is seen as the
maximum reasonable. This would be both a maximum and a minimum.
All of these schemes add state to the system. If the schedule is
predictable, then you can check determine the maximum block size purely
from the header and coinbase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/a048bb7b/attachment.html>

2023-06-07 17:47:55 CEST

- reply

2023-06-07 17:43:14 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:Rather than re-enable OP_LEFT, a NOP could be re-purposed in a soft fork.
OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]] [LEN_PARAM] OP_LEFTEQUALVERIFY
OP_DROP OP_CHECKSIG
A B L OP_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match.
If not, then the script immediately fails. If either array is less than L
bytes or if there are fewer than 3 values on the stack, then it also fails.
The OP_DROP is needed as the new opcode must count as a NOP for legacy
nodes.
A change like this would only cause a once-off improvement in efficiency,
so it is less likely to be worth the effort.
It also requires most clients to be updated to support the new address
system.
A different BIP could be added for that.
An alternative way to add new opcodes is to use a different script engine
like with P2SH.
On Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> While we're all debating the block size, please review this proposal to
> modestly increase the number of transactions per block.
>
> https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63
>
> Best,
>
> Jeremy
>
>
>
> _______________________________________________
> 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/20150722/f9295b82/attachment.html>

2023-06-07 17:42:39 CEST

- reply

📅 Original date posted:2015-07-20
📝 Original message:On Mon, Jul 20, 2015 at 8:10 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> After deployment, the maximum serialized size of a transaction allowed
> in a block shall be 100,000 bytes.
>
This could render transactions with a locktime in the future as unspendable.
It is pretty low probability that someone has created a >100kB locked
transaction though.
It violates the principle that no fork should render someone's coins
unspendable.
At the cost of weakening the protection, the rule could be made to only
apply to version 2 transactions.
*Specification*
The transaction version is increased to version two.
All coinbase transactions must be version two or higher.
If any of its parent transactions are version two or higher
then the transaction must be version two or higher.
The maximum serialized size of a version two transactions allowed in
a block is 100,000 bytes.
As time passes more and more of the UTXO set will be from version two
transactions. To launch the attack, the attacker needs an historical UTXO
entry.
Standard software would create version two transactions even if all inputs
were version one.
The rule could be applied to all transactions most of the time, and have
daily blocks that allow legacy transactions.
This rule shall apply to version 1 transactions too unless the block
height is
a multiple of 100.
At the risk of encouraging feature creep, if the transaction size is being
limited, it would be useful to also limit the size of all its inputs.
This helps with fraud proofs and offline signing.
*Specification*
The transaction version is increased to version two.
All coinbase transactions must be version two or higher.
If any of its parent transactions are version two or higher
then the transaction must be version two or higher.
The maximum serialized size of a version two transactions allowed in
a block is 100,000 bytes.
The maximum of the total serialized size of a version two transaction
and all
of its parents allowed in a block shall be 200,000 bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/ff1d1869/attachment.html>

2023-06-07 17:42:34 CEST

- reply

📅 Original date posted:2015-07-17
📝 Original message:On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr <luke at dashjr.org> wrote:
> Hardforks are not something where voting makes sense. They need consensus
> among /nodes/, not majority among /miners/. No hardfork has ever had such a
> vote.
>
Agreed.
I meant that since some of the new hard fork proposals use a voting system
for activation, they may not want to establish that precedent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/b2bc54e3/attachment.html>

2023-06-07 17:42:29 CEST

- reply

📅 Original date posted:2015-07-17
📝 Original message:On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> While this isn't technically a change, it does mean that both are no
> longer linked together.
>
I meant both block and transaction sizes are no longer linked together.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/2fcef783/attachment.html>

2023-06-07 17:42:28 CEST

- reply

📅 Original date posted:2015-07-17
📝 Original message:Transaction sizes are still limited to 1MB with this patch. While this
isn't technically a change, it does mean that both are no longer linked
together.
Since this has no voting step, I assume the intention is that as a
compromise suggestion, it would have full support.
It establishes a precedent for hard forks not to require a vote though.
On Fri, Jul 17, 2015 at 4:55 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan to
> my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then this
> solution is at least available and a known quantity. A good backup plan.
>
> Benefits: conservative increase. proves network can upgrade. permits
> some added growth, while the community & market gathers data on how an
> increased block size impacts privacy, security, centralization, transaction
> throughput and other metrics. 2MB seems to be a Least Common Denominator
> on an increase.
>
> Costs: requires a hard fork. requires another hard fork down the road.
>
>
>
> _______________________________________________
> 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/20150717/1858d303/attachment.html>

2023-06-07 17:41:52 CEST

- reply

📅 Original date posted:2015-07-10
📝 Original message:On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <me at ricmoo.com> wrote:
> 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.
>
It should be whatever gives the highest fee. In effect, child pays for
parent creates compound transactions.
A: 250 bytes, 0 fee
B: 300 bytes: 0.0005 fee
C: 400 bytes: 0.0001 fee
There are 3 combinations to consider
A: 0 fee for 250 bytes = 0 per byte
A&B: 0.0005 fee for 550 bytes = 0.91 uBTC per byte
A&B&C: 0.0006 fee for 950 bytes = 0.63uBTC per byte
This means that the A&B combination has the best fee per byte value. A&B
should be added to the memory pool (if 0.91 uBTC per byte is above the
threshold).
Once A&B are added, then C can be reconsidered on its own.
C: 0.0001 for 400 bytes = 0.25 BTC per byte
If that is above the threshold, then C should be added.
In practice, it isn't possible to check every combination. If there are N
transactions, then checking all triple combinations costs around N cubed.
A 2 pass system could get a reasonably efficient result.
B is 0.0005 fee for 300 bytes = 1.67 uBTC per byte and is assumed to be a
high value transaction.
The algorithm would be
Pass 1:
Process all transactions in order of BTC per byte, until block is full
If the transaction's parents are either already in the pool or a
previous block, add the transaction.
Pass 1:
Process all non-included transactions in order of BTC per byte, until block
is full
If the transaction's parents are either already in the pool or a
previous block, add the transaction.
Otherwise, consider the transaction plus all non-included ancestors as
a single transaction
If this combined transaction has a higher BTC per byte than the
lowest transaction(s),
add the combined transaction
drop the other transaction(s)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/68d6acca/attachment.html>

2023-06-07 17:40:35 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman <
patrick.strateman at gmail.com> wrote:
> 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.
>
Safety increases with more lead-in time. If the reference client was
updated so that the hard fork happened in two years, it would be pretty
safe. Miners would have time to update.
If miners (or the community) objected, it is sort of like a game of chicken.
This is one of the problems with not making decisions in advance, the
resulting hard fork is inherently safer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/dd5e7ab9/attachment.html>

2023-06-07 17:40:11 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process that
> does work (thank you very much!) and is well documented.
>
There is no process for handling hard forks, which aren't bug fixes.
Soft forks have a defined process of something like
- BIP proposal + discussion
- Proposed code
- Dev acceptance
- Release
- Miner vote/acceptance
The devs have a weak veto. If they refuse to move forward with changes,
miners could perform a soft fork on their own. They don't want to do that,
as it would be controversial and the devs know the software better.
The miner veto is stronger (for soft forks) but not absolute. The devs
could checkpoint/blacklist a chain if miners implemented a fork that wasn't
acceptable (assuming the community backed them).
When ASICs arrived, it was pointed out by some that the devs could hit back
if ASICs weren't made publicly available. If they slightly tweaked the
hashing algorithm, then current generation of ASICs would be useless. The
potential threat may have acted as a disincentive for ASIC manufacturers to
use the ASICs themselves.
Moving forward with agreement between all involved is the recommended and
desirable approach.
Consensus between all parties is the goal but isn't absolutely required.
This escape valve is partly what makes consensus work. If you dig your
heels in, then the other side can bypass you, but they have an incentive to
try to convince you to compromise first. The outcome is better if a middle
ground can be found.
Hard forks are different. The "checks and balances" of weak vetoes are not
present. This means that things can devolve from consensus to mutual
veto. Consensus ceases to be a goal and becomes a requirement.
This is partly a reflection of the nature of hard forks. Everyone needs to
upgrade. On the other hand, if most of the various groups upgrade, then
users of the legacy software would have to upgrade or get left behind. If
5% of the users decided not to upgrade, should they be allowed to demand
that nobody else does?
There is clearly some kind of threshold that is reasonable.
The fundamental problem is that there isn't agreement on what the block
size is. Is it equal in status to the 21 million BTC limit?
If Satoshi had said that 1MB was part of the definition of Bitcoin, then I
think people would accept it to the same extent as they accept the 21
million coin limit. It might cause people to leave the coin though.
It was intended to be temporary, but people have realized that it might be
a good idea to keep it. In effect both sides could argue that they should
be considered the status quo.
I wonder if a coin toss would be acceptable :). "Come to an agreement or
we decide by coin toss"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/b2ce86a5/attachment-0001.html>

2023-06-07 17:39:41 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:On Mon, Jun 22, 2015 at 8:10 PM, Martin Schwarz <martin.schwarz at gmail.com>
wrote:
> Gavin,
>
> in 2022 your proposal (BIP as well as code) crosses the 32MB maximum
> message size limit. In order to avoid deployment of code that
> deterministically
> fails fatally in 2022, I'd propose to stop the doublings at 32MB for now
> and fix
> the message size limit in the mean time.
There is an exception in the code for "block" messages.
https://github.com/gavinandresen/bitcoinxt/commit/c81898ec46e4962daf975e352931b848026fdc34#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR3548
This means 2MB limit for all other messages. "block" messages are limited
to the max block size for 2 hours into the future.
I think setting it to a week into the future might be better, since it is
only a DOS protection. This would guarantee that message sizes are
reasonable. The size check would still be done anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/2457767e/attachment.html>

2023-06-07 17:39:40 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than
the standard 1000. Given that the threshold is lower than is normal for
hard-forks, noise on the measurement could cause an activation even if less
than 75% of miners agree. It also means that the vote has to be sustained
for longer and inherently gives a longer notice period.
Two weeks seems low for an upgrade warning. I guess there would be an
alert on the network.
Do old nodes detect an upgrade by version numbers? If that was headers
only, then they could detect that large blocks have activated.
Have you considered a "fail" condition? For example, if 750 of the last
1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the
miners. Alternatively, if the rule doesn't activate by 11th Jan 2017, then
it is disabled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/c4698689/attachment.html>

2023-06-07 17:39:09 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> If we want a non-repudiation mechanism in the protocol, we should
> explicitly define one rather than relying on “prima facie” assumptions.
> Otherwise, I would recommend not relying on the existence of a signed
> transaction as proof of intent to pay…
>
Outputs could be marked as "locked". If you are performing a zero
confirmation spend, then the recipient could insist that you flag the
output for them as non-reducible.
This reduces privacy since it would be obvious which output was change. If
both are locked, then the fee can't be increased.
This would be information that miners could ignore though.
Creating the right incentives is hard though. Blocks could be
"discouraged" if they have a double spend that is known about for a while
which reduces payment for a locked output.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/f5cec10d/attachment.html>

2023-06-07 17:38:21 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:On Tue, Jun 16, 2015 at 6:18 AM, Venzen <venzen at mail.bihthai.net> wrote:
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.
The main principle of open source software is that anyone can fork the code
if they wish. They don't do it very often, but they can.
This means that if a project dies, someone can take it over. If some of
the devs want to take things in a different direction, they can. Users can
decide which version they prefer.
The software itself is what is valuable.
In the case of bitcoin, the blockchain is also (very) valuable. Simply
splitting into two projects is not possible for bitcoin.
Otherwise, the discussion would have ended already, those who want a larger
block would simply create a fork of the software and create an alt chain.
The fundamental problem is that there is no clear way to make this decision
once and for all.
An agreed set of rules for a hard fork would be a nice thing to have, but
it is hard to have rules about how to change fundamental rules.
I think using the soft fork rules (maybe with a higher threshold than 95%)
plus a delay is a reasonable compromise on hard fork rules.
Even then, it would be nice to include users of the software too. Peter
Todd's suggestion of encoding a vote in transactions is a step in that
direction (YES transactions in YES blocks and NO transactions in NO blocks).
> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.
Nobody owns it, so there is no court of final appeal.
If miners vote >95% for the fork, users could still refuse to accept the
change.
Maybe the sequence could be
version 3 blocks means no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
version 6 blocks means YES to fork & NO transactions
Transaction matching rule:
version 1, 2, 3 transactions means no opinion (can be in any block)
version 4 transactions means YES to fork (cannot be in version 6 blocks)
version 5 transactions means NO to fork (cannot be in version 5 blocks)
Rules
0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching
rule activates for version 5 & 6 blocks
1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4
blocks are rejected
2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6
blocks are rejected
3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the
last 1000 are version 5 or 6, then the fork is accepted
4) 25,000 blocks after 3 is accepted, hard fork actually takes effect
Once miner acceptance is achieved, then only version 5 and 6 blocks are
allowed. The split between version 5 and 6 blocks should be roughly in
proportion to the number of transactions of each kind produced.
75% of miners can kill the fork by producing version 4 blocks, but 95% is
needed for acceptance. Even then, transaction volume needs to support the
fork. I think 75% is reasonable here. (95% of miners and 75% of
merchants/users is a pretty strong majority).
> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>
They are still suggesting some kind of fork threshold process (or at least
that is what is being suggested)
If their system requires 95% miner approval, they aren't taking unilateral
action. Miners are though if they vote in favour.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/382e07b0/attachment.html>

2023-06-07 17:34:08 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:On Fri, May 29, 2015 at 3:09 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>
> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting big miners to
>> do the same, and use the soft-fork block version voting mechanism to
>> (hopefully) get a majority and then a super-majority willing to produce
>> bigger blocks. The purpose of that process is to prove to any doubters that
>> they'd better start supporting bigger blocks or they'll be left behind, and
>> to give them a chance to upgrade before that happens.
>>
>
> How do you define that the movement is successful?
>
Sorry again, I keep auto-sending from gmail when trying to delete.
In theory, using the "nuclear option", the block size can be increased via
soft fork.
Version 4 blocks would contain the hash of the a valid extended block in
the coinbase.
<block height> <32 byte extended hash>
To send coins to the auxiliary block, you send them to some template.
OP_P2SH_EXTENDED <scriptPubKey hash> OP_TRUE
This transaction can be spent by anyone (under the current rules). The
soft fork would lock the transaction output unless it transferred money
from the extended block.
To unlock the transaction output, you need to include the txid of
transaction(s) in the extended block and signature(s) in the scriptSig.
The transaction output can be spent in the extended block using P2SH
against the scriptPubKey hash.
This means that people can choose to move their money to the extended
block. It might have lower security than leaving it in the root chain.
The extended chain could use the updated script language too.
This is obviously more complex than just increasing the size though, but it
could be a fallback option if no consensus is reached. It has the
advantage of giving people a choice. They can move their money to the
extended chain or not, as they wish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/8bedd264/attachment.html>

2023-06-07 17:34:07 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> But if there is still no consensus among developers but the "bigger blocks
> now" movement is successful, I'll ask for help getting big miners to do the
> same, and use the soft-fork block version voting mechanism to (hopefully)
> get a majority and then a super-majority willing to produce bigger blocks.
> The purpose of that process is to prove to any doubters that they'd better
> start supporting bigger blocks or they'll be left behind, and to give them
> a chance to upgrade before that happens.
>
How do you define that the movement is successful?
For
> Because if we can't come to consensus here, the ultimate authority for
> determining consensus is what code the majority of merchants and exchanges
> and miners are running.
>
The measure is miner consensus. How do you intend to measure
exchange/merchant acceptance?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/84672694/attachment.html>

2023-06-07 17:34:05 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:On Fri, May 29, 2015 at 12:26 PM, Mike Hearn <mike at plan99.net> wrote:
> IMO it's not even clear there needs to be a size limit at all. Currently
> the 32mb message cap imposes one anyway
>
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least some multiple of the max block size
allowed.
Alternatively, the merkle block message already incorporates the required
functionality.
Send
- headers message (with 1 header)
- merkleblock messages (max 1MB per message)
The transactions for each merkleblock could be sent directly before each
merkleblock, as is currently the case.
That system can send a block of any size. It would require a change to the
processing of any merkleblocks received.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/21895008/attachment.html>

2023-06-07 17:34:02 CEST

- reply

📅 Original date posted:2015-05-19
📝 Original message:On Mon, May 18, 2015 at 2:42 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> OK. Be nice if these were cleaned up, but I guess it's a sunk cost.
>
Yeah.
On the plus side, as people spend their money, old UTXOs would be used up
and then they would be included in the cost function. It is only people
who are storing their money long term that wouldn't.
They are unlikely to have consumed their UTXOs anyway, unless miners
started paying for UTXOs.
We could make it a range.
UTXOs from below 355,000 and above 375,000 are included. That can create
incentive problems for the next similar change, I think a future threshold
is better.
> He said "utxo_created_size" not "utxo_created" so I assumed scriptlen?
>
Maybe I mis-read.
> But you made that number up? The soft cap and hard byte limit are
> different beasts, so there's no need for soft cost cap < hard byte
> limit.
>
I was thinking about it being a soft-fork.
If it was combined with the 20MB limit change, then it can be anything.
I made a suggestion somewhere (her or forums not sure), that transactions
should be allowed to store bytes.
For example, a new opcode could be added, <byte_count> OP_LOCK_BYTES.
This makes the transaction seem <byte_count> larger. However, when
spending the UTXO, that transaction counts as <byte_count> smaller, even
against the hard-cap.
This would be useful for channels. If channels were 100-1000X the
blockchain volume and someone caused lots of channels to close, there
mightn't be enough space for all the close channel transactions. Some
people might be able to get their refund transactions included in the
blockchain because the timeout expires.
If transactions could store enough space to be spent, then a mass channel
close would cause some very large blocks, but then they would have to be
followed by lots of tiny blocks.
The block limit would be an average not fixed per block. There would be 3
limits
Absolute hard limit (max bytes no matter what): 100MB
Hard limit (max bytes after stored bytes offset): 30MB
Soft limit (max bytes equivalents): 10MB
Blocks lager than ~32MB require a new network protocol, which makes the
hard fork even "harder". The protocol change could be "messages can now be
150MB max" though, so maybe not so complex.
>
> > This requires that transactions include scriptPubKey information when
> > broadcasting them.
>
> Brilliant! I completely missed that possibility...
>
I have written a BIP about it. It is still in the draft stage. I had a
look into writing up the code for the protocol change.
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150519/32dabf8f/attachment.html>

2023-06-07 17:34:02 CEST

- reply

📅 Original date posted:2015-05-16
📝 Original message:On Sat, May 16, 2015 at 1:22 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Some tweaks:
>
> 1) Nomenclature: call tx_size "tx_cost" and real_size "tx_bytes"?
>
Fair enough.
>
> 2) If we have a reasonable hard *byte* limit, I don't think that we need
> the MAX(). In fact, it's probably OK to go negative.
>
I agree, we want people to compress the UTXO space and a transaction with
100 inputs and one output is great.
It may have privacy problem though.
>
> 3) ... or maybe not, if any consumed UTXO was generated before the soft
> fork (reducing Tier's perverse incentive).
>
The incentive problem can be fixed by excluding UTXOs from blocks before a
certain count.
UTXOs in blocks before 375000 don't count.
>
> 4) How do we measure UTXO size? There are some constant-ish things in
> there (eg. txid as key, height, outnum, amount). Maybe just add 32
> to scriptlen?
>
They can be stored as a fixed digest. That can be any size, depending on
security requirements.
Gmaxwell's cost proposal is 3-4 bytes per UTXO change. It isn't
4*UXTO.size - 3*UTXO.size
It is only a small nudge. With only 10% of the block space to play with it
can't be massive.
This requires that transactions include scriptPubKey information when
broadcasting them.
>
> 5) Add a CHECKSIG cost. Naively, since we allow 20,000 CHECKSIGs and
> 1MB blocks, that implies a cost of 50 bytes per CHECKSIG (but counted
> correctly, unlike now).
>
> This last one implies that the initial cost limit would be 2M, but in
> practice probably somewhere in the middle.
>
> tx_cost = 50*num-CHECKSIG
> + tx_bytes
> + 4*utxo_created_size
> - 3*utxo_consumed_size
>
> > A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
> > size of 252 bytes.
>
> Now cost == 352.
>
That is to large a cost for a 10% block change. It could be included in
the block size hard fork though. I think have one combined "cost" for
transactions is good. It means much fewer spread out transaction checks.
The code for the cost formula would be in one place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/8e5f1099/attachment.html>

2023-06-07 17:34:01 CEST

- reply

📅 Original date posted:2015-05-13
📝 Original message:On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> An example would
> be tx_size = MAX( real_size >> 1, real_size + 4*utxo_created_size -
> 3*utxo_consumed_size).
This could be implemented as a soft fork too.
* 1MB hard size limit
* 900kB soft limit
S = block size
U = UTXO_adjusted_size = S + 4 * outputs - 3 * inputs
A block is valid if S < 1MB and U < 1MB
A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
size of 252 bytes.
The memory pool could be sorted by fee per adjusted_size.
Coin selection could be adjusted so it tries to have at least 2 inputs
when creating transactions, unless the input is worth more than a threshold
(say 0.001 BTC).
This is a pretty weak incentive, especially if the block size is
increased. Maybe it will cause a "nudge"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/0e8a97f2/attachment.html>

2023-06-07 17:34:00 CEST

- reply

📅 Original date posted:2015-05-09
📝 Original message:On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> RE: fixing sigop counting, and building in UTXO cost: great idea! One of
> the problems with this debate is it is easy for great ideas get lost in all
> the noise.
>
If the UTXO set cost is built in, UTXO database entries suddenly are worth
something, in addition to the bitcoin held in that entry.
A user's client might display how many they own. When sending money to a
merchant, the user might demand the merchant indicate a slot to pay to.
The user could send an ANYONE_CAN_PAY partial transaction. The transaction
would guarantee that the user has at least as many UTXOs as before.
Discussing the possibility of doing this creates an incentive to bloat the
UTXO set right now, since UTXOs would be valuable in the future.
The objective would be to make them valuable enough to encourage
conservation, but not so valuable that the UTXO contains more value than
the bitcoins in the output.
Gmaxwell's suggested "tx_size = MAX( real_size >> 1, real_size +
4*utxo_created_size - 3*utxo_consumed_size)" for a 250 byte transaction
with 1 input and 2 outputs has very little effect.
real_size + 4 * (2) - 3 * 1 = 255
That gives a 2% size penalty for adding an extra UTXO. I doubt that is
enough to change behavior.
The UTXO set growth could be limited directly. A block would be invalid if
it increases the number of UTXO entries above the charted path.
RE: a hard upper limit, with a dynamic limit under it:
>
If the block is greater than 32MB, then it means an update to how blocks
are broadcast, so that could be a reasonable hard upper limit (or maybe
31MB, or just the 20MB already suggested).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/ffd834c1/attachment.html>

2023-06-07 17:33:42 CEST

- reply

📅 Original date posted:2015-05-16
📝 Original message:On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmorse at gmail.com>
wrote:
> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block that met their own size restrictions but not the
> miners', then they would simply count it as unconfirmed.
>
In effect, there is a confirm penalty for less strict blocks. Confirms =
max(miner_confirms, merchant_confirms - 3, 0)
Merchants who don't upgrade end up having to wait longer to hit
confirmations.
If they get deep enough in the chain, though, the client should probably
> count them as being confirmed anyway, even if they don't meet the client
> nodes' expectation of the miners' block size limit. This happening probably
> just means that the client has not updated their software (or
> -minermaxblocksize configuration, depending on how it is implemented) in a
> long time.
>
That is a good idea. Any parameters that have miner/merchant differences
should be modifiable (but only upwards) in the command line.
"Why are my transactions taking longer to confirm?"
"There was a soft fork to make the block size larger and your client is
being careful. You need to add "minermaxblocksize=4MB" to your
bitcoin.conf file."
Hah, it could be called a "semi-hard fork"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/e5dd0406/attachment.html>

2023-06-07 17:33:41 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:On Fri, May 8, 2015 at 5:37 PM, Peter Todd <pete at petertodd.org> wrote:
> The soft-limit is there miners themselves produce smaller blocks; the
> soft-limit does not prevent other miners from producing larger blocks.
>
I wonder if having a "miner" flag would be good for the network.
Clients for general users and merchants would have a less strict rule than
the rule for miners. Miners who don't set their miners flag might get
orphaned off the chain.
For example, the limits could be setup as follows.
Clients: 20MB
Miners: 4MB
When in "miner mode", the client would reject 4MB blocks and wouldn't build
on them. The reference client might even track the miner and the non-miner
chain tip.
Miners would refuse to build on 5MB blocks, but merchants and general users
would accept them.
This allows the miners to soft fork the limit at some point in the future.
If 75% of miners decided to up the limit to 8MB, then all merchants and the
general users would accept the new blocks. It could follow the standard
soft fork rules.
This is a more general version of the system where miners are allowed to
vote on the block size (subject to a higher limit).
A similar system is where clients track all header trees. Your wallet
could warn you that there is an invalid tree that has > 75% of the hashing
power and you might want to upgrade.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/51802e38/attachment.html>

2023-06-07 17:33:02 CEST

- reply

📅 Original date posted:2015-05-06
📝 Original message:On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list at bluematt.me>
wrote:
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
>
Miners can always reduce the block size (if they coordinate). Increasing
the maximum block size doesn't necessarily cause an increase. A majority
of miners can soft-fork to set the limit lower than the hard limit.
Setting the hard-fork limit higher means that a soft fork can be used to
adjust the limit in the future.
The reference client would accept blocks above the soft limit for wallet
purposes, but not build on them. Blocks above the hard limit would be
rejected completely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/b5a9be4e/attachment.html>

2023-06-07 17:33:01 CEST

- reply

📅 Original date posted:2015-05-06
📝 Original message:On Wed, May 6, 2015 at 11:12 PM, Matt Corallo <bitcoin-list at bluematt.me>
wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.
Miners can already soft-fork to reduce the maximum block size. If 51% of
miners agree to a 250kB block size, then that is the maximum block size.
The question being discussed is what is the maximum block size merchants
and users will accept. This puts a reasonable limit on the maximum size
miners can increase the block size to.
In effect, the block size is set by the minimum of the miner's and the
merchants/user's size.min(miner, merchants/users).
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
>
Would you accept a rule that the maximum size is 20MB (doubling every 2
years), but that miners have an efficient method for choosing a lower size?
If miners could specify the maximum block size in their block headers, then
they could coordinate to adjust the block size. If 75% vote to lower the
size, then it is lowered and vice versa for raiding.
Every 2016 blocks, the votes are counter. If the 504th lowest of the 2016
blocks is higher than the previous size, then the size is set to that
size. Similarly, if the 504th highest is lower than the previous size, it
becomes the new size.
There could be 2 default trajectories. The reference client might always
vote to double the size every 4 years.
To handle large blocks (>32MB) requires a change to the p2p protocol
message size limits, or a way to split blocks over multiple messages.
It would be nice to add new features to any hard-fork.
I favour adding an auxiliary header. The Merkle root in the header could
be replaced with hash(merkle_root | hash(aux_header)). This is a fairly
simple change, but helps with things like commitments. One of the fields
in the auxiliary header could be an extra nonce field. This would mean
fast regeneration of the merkle root for ASIC miners. This is a pretty
simple change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150506/58ef0a86/attachment.html>

2023-06-07 17:20:11 CEST

- reply

📅 Original date posted:2014-04-25
📝 Original message:As part of the atomic cross chain system, outputs need to be hash locked.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
A user needs to provide x corresponding to hash(x) in order to spend an
output.
Under the protocol, one of the participants is required to provide the
secret number in order to spend an output. Once they do that, the other
participant can use the secret number to spend an output on the other
chain. This provides a mechanism to link the 2 chains together (in
addition to lock times). Once the first output is spent, that commits the
transfer.
This is half of the scripting operations required to implement the protocol.
The proposal is to make this an adder on to the other standard
transactions. It does a check that the hash matches, and then runs the
standard transaction as normal.
Adding the prefix to a P2SH transactions wouldn't work, since the template
wouldn't match.
A script of this form could be embedded into a P2SH output.
I think that is ok, since embedding the "password" in the hashed script
gets all the benefits.
If there is agreement, I can code up the reference implementation as a PR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/f6e19f03/attachment.html>

2023-06-07 17:20:08 CEST

- reply

📅 Original date posted:2014-04-25
📝 Original message:This is a BIP to allow the spender to choose one of multiple standard
scripts to use for spending the output.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
This is required as part of the atomic cross chain transfer protocol. It
is required so that outputs can be retrieved, if the process ends before
being committed.
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
The script allows multiple standard scripts to be included in the
scriptPubKey.
When redeeming the script the spender indicates which of the standard
scripts to use.
Only one standard script is actually executed, so the only cost is the
extra storage required.
A more ambitious change would be a soft fork like P2SH, except the spender
is allowed to select from multiple hashes. Effectively, it would be
"Multi-P2SH".
This gets much of the benefits of MAST, but it requires a formal soft fork
to implement.
If there is agreement, I can code up the reference implementation as a PR.
The multi-P2SH might actually be easier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/a77e346c/attachment.html>

2023-06-07 17:19:48 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> You can see me proposing this kind of thing in a number of places (e.g.
> http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
> only forces the subsidy today, but the same mechnism could instead
> force transactions..
Interesting. You set the share-block size to 16kB and set the share POW to
1/64 of the main target.
Each share-block would be allowed to append up to 16kB on the previous
share-block.
This would keep the bandwidth the same, but on average blocks would be only
512kB.
e.g. to get you fast confirmation.", or
> previously on BCT for the last couple years) but there are still
> limits here: If you don't follow the fast-confirmation share chain
> you cannot mine third party transactions because you'll be at risk of
> mining a double spend that gets you orphaned, or building on a prior
> block that other miners have decided is bad. This means that if the
> latency or data rate requirements of the share chain are too large
> relative to ordinary mining it may create some centralization
> pressure.
>
This effect could be reduced by having "colours" for blocks and
transactions.
The block colour would be a loop based on block height.
You could have 16 transaction "colours" based on the lowest 4 bits in the
txId.
A transaction is only valid if all inputs into the transaction are the
correct colour for that block.
This allows blocks to be created in advance. If you are processing colour
7 at the moment, you can have a colour 8 block ready.
16 colours is probably to many. It would only be necessary for things
like 1 second block rates.
The disadvantage is that wallets would have to make sure that they have
coins for each of the 16 colours.
If you spend the wrong colour, you add 16 block times of latency.
>
> That said, I think using a fast confirmation share-chain is much
> better than decreasing block times and could be a very useful tool if
> we believe that there are many applications which could be improved
> with e.g. a 30 second or 1 minute interblock time. Mostly my thinking
> has been that these retail applications really want sub-second
> confirmation, which can't reasonably be provided in this manner so I
> didn't mention it in this thread.
>
In a shop setting, you could set it up so that the person scans a QR-code
to setup a channel with the shop.
They can then scan all their stuff and by the time they have done that, the
channel would be ready.
If there was a queue, it could be done when the person enters the queue.
In fact, there could be QR-codes at multiple locations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/e2f80e85/attachment.html>

2023-06-07 17:19:48 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:An interesting experiment would be a transaction "proof of publication"
chain.
Each transaction would be added to that chain when it is received. It
could be merge mined with the main chain.
If the size was limited, then it doesn't even require spam protection.
Blocks could be "discouraged" if they have transactions which violate the
ordering in that chain. Miners could still decide which transactions they
include, but couldn't include transactions which are double spends.
The locktime/final field could be used for transactions which want to be
replaceable.
The chain could use some of the fast block proposals. For example, it
could include orphans of a block when computing the block's POW.
On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter at gmail.com> wrote:
> > Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> > the problem? If there would be a safe way for 0-confirmation
> transactions,
> > the Bitcoin blockchain wouldn't even be needed.
>
> Large scale consensus can't generally provide instantly irreversible
> transactions directly: Increasing the block speed can't help past the
> point where the time starts getting close to the network diameter...
> you simply can't tell what a consensus of a group of nodes is until
> several times the light cone that includes all of them. And if you
> start getting close to the limit you dilute the power working on the
> consensus and potentially make life easier for a large attacker.
>
> Maybe other chains with different parameters could achieve a different
> tradeoff which was better suited to low value retail transactions
> (e.g. where you want a soft confirmation fast). A choice of tradeoffs
> could be very useful, and maybe you can practically get close enough
> (e.g. would knowing you lost a zero-conf double spend within 30
> seconds 90% of the time be good enough?)... but I'm not aware of any
> silver bullet there which gives you something identical to what a
> centralized service can give you without invoking at least a little
> bit of centralization.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> 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/20140423/bf4cfe10/attachment.html>

2023-06-07 17:19:32 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:Bitcoin has various checks and balances that help keep everything honest.
Even if a pool had 60% of the hashing power, they couldn't reverse 6 blocks
without anyone noticing that it had happened.
There are sites which monitor the blocks and estimate the percentage of the
blocks found by each pool.
In a way, bitcoin doesn't depend on the majority of miners following the
protocol, it depends on miners believing that a majority of the other
miners will follow the protocol.
If a miner has 5% of the hashing power and believes that the other 95% will
follow the protocol, then the system should be set up so that it is in that
miner's interests to follow the protocol too.
This is why soft forks work. The formal process convinces all the miners
that the new rules are locked in.
In a system where miners can vote to cancel coinbases, each pool has an
incentive to vote to reject everyone else's blocks.
Pools on the receiving end will be less profitable and lose customers.
It is possible that "predatory" pools would lose hashing power as miners
switch to other pools, in protest.
The proposal allows "established" pools to vote to disallow new entrants.
They could even justify it by saying that those pools haven't invested in
"anti-double spending" infrastructure.
The proposal doesn't suddenly give the majority the ability to do it, but
it isn't clear that making the process less disruptive is a good thing.
On Wed, Apr 23, 2014 at 7:37 PM, Mike Hearn <mike at plan99.net> wrote:
> If you want to try and argue that the development list is the wrong place
> to discuss development, please do so on another thread (or your blog).
> Let's keep this thread for discussion of the original proposal - ideally,
> discussed with the dryness that a topic as nerdy as distributed consensus
> algorithms deserves ;)
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> 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/20140423/2d0343ba/attachment.html>

2023-06-07 17:18:13 CEST

- reply

📅 Original date posted:2014-04-10
📝 Original message:Error correction is an interesting suggestion.
If there was 10000 nodes and each stored 0.1% of the blocks, at random,
then the odds of a block not being stored is 45 in a million.
Blocks are stored on average 10 times, so there is already reasonable
redundancy.
With 1 million blocks, 45 would be lost in that case, even though most are
stored multiple times.
With error correction codes, the chances of blocks going missing is much
lower.
For example, if there was 32 out of 34 Reed-Solomon-like system, then 2
blocks out of 34 could be lost without any actual data loss for the network.
As a back of the envelop check, the odds of 2 missing blocks landing within
34 of another is 68/1000000. That means that the odds of 2 missing blocks
falling in the same correction section is 45 * 34 / 1000000 = 0.153%. Even
in that case, the missing blocks could be reconstructed, as long as you
know that they are missing.
The error correction code has taken it from being a near certainty that
some blocks would be lost to less than 0.153%.
A simple error correction system would just take 32 blocks in sequence and
then compute 2 extra blocks.
The extra blocks would have to be the same length as the longest block in
the 32 being corrected.
The shorter blocks would be padded with zeroes so everything is the same
size.
For each byte position in the blocks you compute the polynomial that goes
through byte (x, data(x)), for x = 0 to 31. This could be a finite field,
or just mod 257.
You can then compute the value for x=32 and x = 33. Those are the values
for the 2 extra blocks.
If mod 257 is used, then only the 2 extra blocks have to deal with symbols
from 0 to 256.
If you have 32 of the 34 blocks, you can compute the polynomial and thus
generate the 32 actual blocks.
This could be achieved by a soft fork by having a commitment every 32
blocks in the coinbase.
It makes the header chain much longer though.
Longer sections are more efficient, but need more calculations to recover
everything. You could also do interleaving to handle the case where entire
sections are missing.
On Thu, Apr 10, 2014 at 12:54 PM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 10 April 2014 07:50:55 GMT-04:00, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> >(Just be glad I'm not suggesting coding the entire blockchain with an
> >error correcting code so that it doesn't matter which subset you're
> >holding)
>
> I forgot to ask last night: if you do that, can you add new blocks to the
> chain with the encoding incrementally?
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCgA6BQJTRoZ+MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYudCAC7ImifMnLIFHv1UifV
> zRxtDkx7UxIf9dncDAcrTIyKEDhoouh0TmoZl3HKQ3KUEETAVKsMzqXLgqVe6Ezr
> ny1bm0pQlkBCZFRwuZvmB27Y3mwC8PD6rT9ywtWzFjWd8PEg6/UaM547nQPw7ir0
> 27S3XMfE/BMiQWfWnWc/nqpbmJjd8x/dM3oiTG9SVZ7iNxotxAqfnW2X5tkhJb0q
> dAV08wpu6aZ5hTyLpvDxXDFjEG119HJeLkT9QVIrg+GBG55PYORqE4gQr6uhrF4L
> fGZS2EIlbk+kAiv0EjglQfxWM7KSRegplSASiKEOuX80tqLIsEugNh1em8qvG401
> NOAS
> =CWql
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140410/1f9c48ef/attachment.html>

2023-06-07 17:17:54 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak <stick at gk2.sk> wrote:
>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>
I meant for a merchant with a server that is handing out hundreds of
addresses.
The point is to have a single system that is compatible over a large number
of systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/77da2094/attachment.html>

2023-06-07 17:17:53 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:Different users could have different gap limit requirements. 20 seems very
low as the default.
A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.
Setting the gap limit to high is just a small extra cost in that case.
Bip-32 serialization doesn't have a way of adding meta data though.
On Wed, Apr 23, 2014 at 7:18 PM, slush <slush at centrum.cz> wrote:
> For those who don't follow github pull requests regularly; there's pull
> request for BIP64 defining HD wallet structure as discussed in this thread:
>
> https://github.com/bitcoin/bips/pull/52
>
>
>
> On Wed, Apr 23, 2014 at 8:01 PM, slush <slush at centrum.cz> wrote:
>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>>>
>>> Storing the seed is superior to storing the master node already
>>> (whether coin specific or not), as it is smaller.
>>>
>>>
>> ...Except that you're loosing flexibility (serialization,
>> deserialization) which gives you BIP32 node.
>>
>> I see "bip32 seed" as some transitional, internal state from raw entropy
>> to bip32 master node and this seed should not be handled by the end user in
>> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
>> mnemonic format) can be used very widely and have no downsides against
>> using raw "bip32 seed".
>>
>>
>>>
>>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>>> *Bitcoin* improvement proposal, and not something that necessarily
>>> applies to other coins (they can adopt it of course, I don't care).
>>>
>>>
>> I also don't care too much about altcoins, but people want them so me, as
>> infrastructure developer, need to think about it. And I don't see any
>> reason for breaking compatibility between Bitcoin and other altcoins. I
>> would be happier if there will be another sentence than "Bitcoin seed", but
>> honestly, who cares. It is just some magic string for hashing the raw
>> seed...
>>
>>
>>> What I dislike is that this removes the ability of using the magic in
>>> the serialization to prevent importing a chain from the wrong coin.
>>>
>>
>> The truth is that even existing software which handle bip32 don't care
>> about 'version' at all. I think that "xpub/xprv" distinction is the only
>> useful feature of version, so user se if it stores public or private
>> information.
>>
>> But using prefixes which doesn't enforce anything is even more dangerous.
>> If somebody exports node "dogeblablabla", it creates false exceptations
>> that there's only dogecoin stored.
>>
>> Marek
>>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> 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/20140423/dd62bab3/attachment.html>

2023-06-07 17:17:42 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> You have to load headers sequantially to be able to connect them and
> determine the longest chain.
>
The isn't strictly true. If you are connected to a some honest nodes, then
you could download portions of the chain and then connect the various
sub-chains together.
The protocol doesn't support it though. There is no system to ask for
block headers for the main chain block with a given height,
Finding one high bandwidth peer to download the entire header chain
sequentially is pretty much forced. The client can switch if there is a
timeout.
Other peers could be used to parallel download the block chain while the
main chain is downloading. Even if the header download stalled, it
wouldn't be that big a deal.
> Blocks can be loaded in random order once you have their order given by
the headers.
> Computing the UTXO however will force you to at least temporarily store
the blocks unless you have plenty of RAM.
You only need to store the UTXO set, rather than the entire block chain.
It is possible to generate the UTXO set without doing any signature
verification.
A lightweight node could just verify the UTXO set and then do random
signature verifications.
The keeps disk space and CPU reasonably low. If an illegal transaction is
added to be a block, then proof could be provided for the bad transaction.
The only slightly difficult thing is confirming inflation. That can be
checked on a block by block basis when downloading the entire block chain.
> Regards,
> Tamas Blummer
> http://bitsofproof.com <http://bitsofproof.com>
On 07.04.2014, at 21:30, Paul Lyon <pmlyon at hotmail.ca> wrote:
I hope I'm not thread-jacking here, apologies if so, but that's the
approach I've taken with the node I'm working on.
Headers can be downloaded and stored in any order, it'll make sense of what
the winning chain is. Blocks don't need to be downloaded in any particular
order and they don't need to be saved to disk, the UTXO is fully
self-contained. That way the concern of storing blocks for seeding (or not)
is wholly separated from syncing the UTXO. This allows me to do the initial
blockchain sync in ~6 hours when I use my SSD. I only need enough disk
space to store the UTXO, and then whatever amount of block data the user
would want to store for the health of the network.
This project is a bitcoin learning exercise for me, so I can only hope I
don't have any critical design flaws in there. :)
------------------------------
From: tamas at bitsofproof.com
Date: Mon, 7 Apr 2014 21:20:31 +0200
To: gmaxwell at gmail.com
CC: bitcoin-development at lists.sourceforge.net
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
Once headers are loaded first there is no reason for sequential loading.
Validation has to be sequantial, but that step can be deferred until the
blocks before a point are loaded and continous.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 21:03, Gregory Maxwell <gmaxwell at gmail.com> wrote:
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <tamas at bitsofproof.com>
wrote:
therefore I guess it is more handy to return some bitmap of pruned/full
blocks than ranges.
A bitmap also means high overhead and-- if it's used to advertise
non-contiguous blocks-- poor locality, since blocks are fetched
sequentially.
------------------------------------------------------------------------------
Put Bad Developers to Shame Dominate Development with Jenkins Continuous
Integration Continuously Automate Build, Test & Deployment Start a new
project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Bitcoin-development mailing
list Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140407/391b78f4/attachment.html>

2023-06-07 17:17:40 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:On Mon, Apr 7, 2014 at 8:03 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> A bitmap also means high overhead and-- if it's used to advertise
> non-contiguous blocks-- poor locality, since blocks are fetched
> sequentially.
>
A range seems like a great compromise. Putting it in the address is also a
pretty cool.
If light nodes selected a random contiguous 1GB of the block-chain, then
they could handle most of the download overhead, rather than the full nodes.
Another way to do it would be to have something like a routing table. If a
node is queried for a block, it can reply with the IP of a node with that
block instead of sending the block.
One problem is that it means that light nodes have to accept incoming
connections. Otherwise, it would have to be routed through the network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/b5bfb780/attachment.html>