Tier Nolan [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-07-23 to 2020-08-17
💬 Posted a total of 225 messages
📚 Participated in the following categories: Bitcoin-development, ANN, BIP, BIP draft, soft/hard, bitcoin-dev, BIP-draft, BIP Proposal, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd

Profile Code

nprofile1qqsydxr0s6uhejtc9xsrrvpjp9jy6y6tjwwszceh23nlpvfk8cxcwhs54t25u

Author Public Key

npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd

Show more details

Last Notes

2023-06-09 12:47:02

- reply

📅 Original date posted:2017-02-08
📝 Original message:
On Wed, Feb 8, 2017 at 9:32 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> Tadge had an idea so we do not need any nTimeLock:
>
I think the nLocktime for TX2 is basically costless. It just prevents
channel fast initial channel close.
Once an unchanged version of TX1 is in the blockchain, all further updates
of the channel can exclude the nLocktime..
> 1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the
bounty)
This is so that Alice can unlock the bounty once the channel is setup, as a
courtesy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/67b0efe0/attachment-0001.html>

2023-06-09 12:47:01

- 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 12:47:01

- reply

📅 Original date posted:2017-02-07
📝 Original message:
On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> Good point, actually, a simpler way to do it, is for TX2 to be nTimelocked
> after bounty's expiration.
>
That works too and keeps the transaction smaller.
I think a symmetrically funded channel needs 4 1BTC outputs, so it is
pretty much two single funded channels. It would be slightly smaller than
2 transactions to open the channel.
TX1
Input
2 from Alice
2 from Bob
Output
1: (Alice + Bob) OR (Bob + AliceSecret)
1: (Alice + Bob) OR (Alice + BobSecret)
1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)
1: (Alice + timeout(now + T)) OR (Bob + BobSecret)
TX2
locktime: now + 2T
Input
TX1/0: signed by (Alice + Bob)
TX1/1: signed by (Alice + Bob)
Output
Initial channel paying Alice & Bob 1BTC each
---------------------------------------
Alice and Bob create TX1, sign it and share the result.
Alice and Bob create TX2, sign it and share the result.
Abort for those 2 steps:
* If one signs and the other doesn't then the signer should spend their
inputs to be safe.
* If TX1 is broadcast, then they can both spend their timeouts to recover
their funds, so it is safe.
Once they both have signed versions of TX1 and TX2, they should broadcast
TX1. This initializes the channel.
If TX1 is mutated, then they should both abort and spend their timeouts and
recover their funds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170207/7d562bed/attachment.html>

2023-06-09 12:47:00

- 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-09 12:46:18

- reply

📅 Original date posted:2016-05-27
📝 Original message:
Hubs on the Lightning network require a large amount of capital. If a hub
wants to be able to send 1 BTC to N customers, then it needs to create N
channels and lock 1BTC in each of them.
This creates an economy of scale effect for hubs. Hubs with more capital
can support larger channels and/or more customers. If the de facto barrier
to entry for hubs is high enough, then the number of hubs will be small,
making cartel formation easier.
With multi-party channels, a hub could share its capital between multiple
customers.
I think it should be possible to shoehorn multi-party channels as a soft
fork, but makes it harder to explain the concept. For this post, I will
assume a hard-fork and any rule change can be used.
*** Basic Multiparty Channels ***
A basic multi-party channel requires all participants to sign each state
update.
Each state update would incorporate the index number of the state. This
allows states to be ordered. They would also have a unique channel id.
Assuming everyone is honest, a channel would operate as follows.
<channel established by multiple participants and timeout agreed>
<state update 1, signed by all participants>
<state update 2, signed by all participants>
<state update M, signed by all participants>
<channel times out - closes are now allowed>
<someone publishes a state update, signed by all but signed again (twice)
by the broadcaster>
<outputs unspendable for 24 hours>
If the broadcaster didn't publish the most recent state update, then
another participant is allowed to broadcast a later update. If this is
included in a block within the 24 hour window, then it overwrites the
original state update (and starts another 24 hour timeout).
This is the main hard fork bit, the state update is a transaction that is
included in the block chain. Unlike normal transactions, state updates can
be overwritten within 24 hours. Locking the transaction outputs during
that time means that this is safe.
Since each broadcaster has to sign their broadcast, it is possible to
determine who is to blame for broadcasting an expired state update.
They could lose their contribution to the channel as with normal lightning
network channels.
This creates an incentive for all parties to broadcast only the most recent
state.
This system require signatures from all the parties for all state updates
and updates are impossible while any of the parties are offline (or
uncooperative).
*** Flexible Multiparty Channels ***
A better system is that state updates require the signatures of parties who
lose out due to the state update only. Unless a state update decreases a
participant's holdings, that participant is not required to sign the update.
For efficiency, the hub could be a special member that must sign all
updates. It is assumed that the hub is online all the time.
Until the channel times out, only the hub can broadcast the final state of
the channel. After that point, any of the participants would be allowed to
broadcast to close the channel. This prevents a participant from closing a
channel that everyone else wants to keep open.
As before the outputs from the channel would be locked for 24 hours to give
participants a chance to challenge the final state.
Participants would have the option of broadcasting the latest state that
they signed. A challenge is only allowed if the participant has less
holdings in the final state than in the latest one that they signed.
The hub could then respond with a later state that the participant signed.
If the hub broadcasts that proof of fraud, then the participant would lose
their money (or vice versa, if the hub tried to steal their money).
Since each fraud step causes a participant to be kicked from the channel,
eventually, it should settle on the actual honest final state and in most
cases, hubs would be honest anyway.
The state updates could work like a blockchain with previous pointers.
This means that if a participant signs state n, it is also signing all
states below state n.
Parties would download the entire state chain from the hub whenever they
come online and verify that it is a valid history. If the hub signs states
on more than than 1 fork, then the hub would lose its deposit.
If the hub is honest, then the close step should be reasonably fast. Fraud
claim timeouts could be handled in parallel too.
It should be possible to set things up so that the channel is mostly
eternal. Parties could be added and removed from the channel without it
having to be closed. This would require some kind of on-chain activity
though unless the withdrawal is handled by moving to another channel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160527/ce86e199/attachment.html>

2023-06-07 18:21:05

- reply

📅 Original date posted:2019-10-12
📝 Original message:On Sat, Oct 12, 2019 at 6:56 PM Joachim Strömbergson <
joachimstr at protonmail.com> wrote:
> I like the backwards syncing idea. First you provide proof of your best
> block height via coinbase, then sync backwards. It solves lots of related
> problems. You know how much you can expect from the given peer.
>
It shows you which nodes are on the same chain too.
If you have 8 peers and you ask the 8 of them for their 8 best, then they
should all agree on most of them.
You can then ask each of the 8 to start sending you headers backwards from
one of the 8 seeds.
They will all roughly split the chain into 8 equal pieces, though the split
will be based on work rather than header height.
If there is disagreement, you can give priority to the node(s) with the
lowest headers until they have completed their download.
It requires a network protocol change to allow reverse block downloads
though (and messages to indicate lowest headers etc.)
On different note, one of the problems that I haven't seen mentioned here
> yet is the timewarp attack. It is relevant to some of the proposed
> solutions. It should be possible, IIRC, for a malicious node to generate
> much longer chain with superslow timestamp increase (~5 blocks in 1 second)
> without increasing difficulty (i.e. staying at min. diff.). This could
> produce chain that is ~2500 times longer than main chain without having
> multiple branches.
>
That is a good point. It answers my question about formula for maximum
number of blocks.
5 * 60 * 60 * 24 * 365 = 157,680,000
That's around 150 million blocks per year at that rate.
I assume the 5 per second limit is that it is greater that the median of
the last 11 rather than greater or equal?
The timewarp bug can be fixed by a basic soft fork. You just need to limit
the maximum difference between the timestamp for the first header in a
period and the last header in the previous period.
An alternative would be to soft fork in a maximum block rate. In addition
to the current rules, you could limit it to a maximum of 1 block every 2
mins. That rule shouldn't activate normally.
block.height <= (block.timestamp - genesis.timestamp) / (2 mins)
It could have some weird incentives if it actually activated though.
Miners would have to shutdown mining if they were finding blocks to fast.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/557b7e19/attachment.html>

2023-06-07 18:21:04

- reply

📅 Original date posted:2019-10-15
📝 Original message:On Tue, Oct 15, 2019 at 7:29 AM Braydon Fuller via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> So I don't think you can use the height in the coinbase for that
> purpose, as it's not possible to validate it without the previous
> headers. That's common for more than just the height.
>
It is a property of blockchains that the lowest digest for a chain
represents the total chainwork.
Estimate total hash count = N * (2^256) / (Nth lowest (i.e. strongest)
digest over all headers)
To produce a fake set of 10 headers that give a higher work estimate than
the main chain would require around the same effort as went into the main
chain in the first place. You might as well completely build an
alternative chain.
Working backwards for one of those headers, you have to follow the actual
chain back to genesis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191015/449fd686/attachment.html>

2023-06-07 18:21:02

- reply

📅 Original date posted:2019-10-04
📝 Original message:Are you assuming no network protocol changes?
At root, the requirement is that peers can prove their total chain POW.
Since each block has the height in the coinbase, a peer can send a short
proof of height for a disconnected header and could assert the POW for that
header.
Each peer could send the the N strongest headers (lowest digest/most POW)
for their main chain and prove the height of each one.
The total chain work can be estimated as N times the POW for the lowest in
the list. This is an interesting property of how POW works. The 10th best
POW block will have about 10% of the total POW.
The N blocks would be spread along the chain and the peer could ask for all
headers between any 2 of them and check the different in claimed POW. If
dishonesty is discovered, the peer can be banned and all info from that
peer wiped.
You can apply the rule hierarchically. The honest peers would have a much
higher POW chain. You could ask the peer to give you the N strongest
headers between 2 headers that they gave for their best chain. You can
check that their height is between the two limits.
The peer would effectively be proving their total POW recursively.
This would require a new set of messages so you can request info about the
best chain.
It also has the nice feature that it allows you to see if multiple peers
are on the same chain, since they will have the same best blocks.
The most elegant would be something like using SNARKS to directly prove
that your chain tip has a particular POW. The download would go tip to
genesis, unlike now when it is in the other direction.
------------------------------------------------------------------------
In regard to your proposal, I think the key is to limit things by peer,
rather than globally.
The limit to header width should be split between peers. If you have N
outgoing peers, they get 1/N of your header download resources each.
You store the current best/most POW header chain and at least one
alternative chain per outgoing peer.
You could still prune old chains based on POW, but the best chain and the
current chain for each outgoing peer should not be pruned.
The security assumption is that a node is connected to at least one honest
node.
If you split resources between all peers, then it prevents the dishonest
nodes from flooding and wiping out the progress for the honest peer.
- Message Limiting -
I have the same objection here. The message limiting should be per peer.
An honest peer who has just been connected to shouldn't suffer a penalty.
Your point that it is only a few minutes anyway may make this point moot
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191005/ea973505/attachment.html>

2023-06-07 18:10:24

- 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 18:05:26

- reply

📅 Original date posted:2017-09-07
📝 Original message:You could have a timelocked transaction that has a zero value input (and
other non-zero inputs). If the SF happened, that transaction would become
unspendable.
The keys to the outputs may be lost or the co-signer may refuse to
cooperate.
There seems to be some objections to long term timelocked transactions.
If someone asked me about it, I would recommend that any timelocked
transactions should very carefully make sure that they use forms that are
popular.
I think the fairest rule would be that any change which makes some
transactions invalid should be opt-in and only apply to new transaction
version numbers.
If you create a timelocked transactions with an undefined version number,
then you have little to complain about.
If the version number is defined and in-use, then transactions should not
suddenly lose validity.
A refusal to commit to that makes long term locktime use much more risky.
On Thu, Sep 7, 2017 at 12:54 AM, CryptAxe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As long as an unspendable outputs (OP_RETURN outputs for example) with
> amount=0 are still allowed I don't see it being an issue for anything.
>
> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
>> This is not a priority, not very important either.
>> Right now it is possible to create 0-value outputs that are spendable
>> and thus stay in the utxo (potentially forever). Requiring at least 1
>> satoshi per output doesn't really do much against a spam attack to the
>> utxo, but I think it would be slightly better than the current
>> situation.
>>
>> Is there any reason or use case to keep allowing spendable outputs
>> with null amounts in them?
>>
>> If not, I'm happy to create a BIP with its code, this should be simple.
>> _______________________________________________
>> 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/20170907/d1dfecc7/attachment.html>

2023-06-07 18:05:24

- 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 18:04:28

- reply

📅 Original date posted:2017-07-14
📝 Original message:On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time. So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party. Is that accurate?
>
You would also have to ensure that everyone you give your addresses to
follows the same rule. As time passes, there would be fewer and fewer
people who have "clean" outputs.
>From the perspective of old nodes, segwit looks like lots of people are
transferring money to "anyone-can-spend" outputs. This outputs are
completely unprotected. Literally, anyone can spend them. (In practice,
miners would spend them, since why would they include a transaction that
sends "free money" to someone else).
If you run an old node, then someone could send you a transaction that only
spends segwit outputs and you would think it is a valid payment.
Imagine that there are only 3 UTXOs (Alice, Bob and Carl have all the
Bitcoins).
UTXO-1: Requires signature by Alice (legacy output)
UTXO-2: Anyone can pay (but is actually a segwit output that needs to be
signed by Bob)
UTXO-3: Anyone can pay (but is actually a segwit output that needs to be
signed by Carl)
Only Bob can spend UTXO-2, since it needs his signature.
Anyone could create a transaction that spends UTXO-2 and it would look good
to all legacy nodes. It is an "anyone can spend" output after all.
However, if they submit the transaction to the miners, then it will be
rejected, because according to the new rules, it is invalid (it needs to be
signed by Bob).
Once a soft fork goes through, then all miners will enforce the new rules.
A miner who added the transaction to one of his blocks (since it is valid
under the old rules) would find that no other miners would accept his block
and he would get no fees for that block. This means that all miners have
an incentive to upgrade once a soft fork activates.
His block would be accepted by legacy nodes, for a short while. However,
since 95% of the miners are on the main chain, their chain (which rejects
his block) would end up the longest.
If you are running a legacy client when a soft fork comes in, then you can
be tricked with "zero confirm" transactions. The transaction will look
good to you, but will be invalid under the new rules. This makes your
client think you have received (a lot of) money, but in practice, the
transaction will not be accepted by the miners.
> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx. I guess the benefit
> is that I could be certain of the remaining funds I have.
>
If you wanted, you could mark any transaction that has a segwit looking
output as "dirty" and then all of its descendants as dirty.
However, pretty quickly, only a tiny fraction of all bitcoins would be
clean.
I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
Right.
I think a reasonably compromise would be to assume that all transactions
buried more than a few hundred blocks deep are probably ok. Only segwit
looking outputs would be marked as "uncertain".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170714/ed6c4875/attachment.html>

2023-06-07 18:01:31

- reply

📅 Original date posted:2017-05-24
📝 Original message:On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
> probably the most human-readable description.
>
I guess I was looking for the detail you get in the code, but without
having to read the code.
My quick reading gives that the sidechain codes (critical hashes) are added
when a coinbase is processed.
Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
a potential critical hash.
When the block is processed, the key value pair (hash, block_height) is
added to a hash map.
The OP_BRIBE opcode checks that the given hash is in the hash map and
replaces the top element on the stack with the pass/fail result.
It doesn't even check that the height matches the current block, though
there is a comment that that is a TODO.
I agree with ZmnSCPxj, when updating a nop, you can't change the stack. It
has to fail the script or do nothing.
OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
coinbase, or cause a script failure otherwise.
Another concern is that you could have multiple bribes for the same chain
in a single coinbase. That isn't fair and arguably what the sidechain
miner is paying for is to get his hash exclusively into the block.
I would suggest that the output is
OP_RETURN <sidechain_id> <critical hash>
Then add the rule that only the first hash with a particular sidechain id
actually counts.
This forces the miner to only accept the bribe from 1 miner for each
sidechain for each block. If he tries to accept 2, then only the first one
counts.
OP_BRIBE_VERIFY could then operate as follows
<block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
This causes the script to fail if
<block height> does not match the block height, or
<critical hash> is not the hash for the sidechain with <sidechain_id>, or
there is no hash for that sidechain in the block's coinbase
If you want reduce the number of drops, you could serialize the info into a
single push.
This has the advantage that a sidechain miner only has to pay if his block
is accepted in the next bitcoin block. Since he is the only miner for that
sidechain that gets into the main bitcoin block, he is pretty much
guaranteed to form the longest chain.
Without that rule, sidechain miners could end up having to pay even though
it doesn't make their chain the longest.
How are these transactions propagated over the network? For relaying, you
could have the rule that the opcode passes as long as <block height> is
near the current block height. Maybe require that they are in the future.
They should be removed from the memory pool once the block height has
arrived, so losing miners can re-spend those outputs.
This opcode can be validated without needing to look at other blocks, which
is good for validating historical blocks.
I am still looking at the deposit/withdrawal code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170524/ac8f7126/attachment.html>

2023-06-07 18:01:31

- reply

📅 Original date posted:2017-05-24
📝 Original message:On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
> OP_BRIBE_VERIFY could then operate as follows
>
> <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> This causes the script to fail if
> <block height> does not match the block height, or
> <critical hash> is not the hash for the sidechain with <sidechain_id>, or
> there is no hash for that sidechain in the block's coinbase
>
>
I was thinking more on the process for these transactions.
I assume that the process is
- sidechain miner broadcasts transaction with OP_BRIBE output
- this transaction ends up in the memory pool of miners
- Miners add the transaction to their next block
- Miners add a transaction which spends the output to one of their own
addresses
I think you need an additional rule that OP_BRIBE checks fails unless the
output is locked 100 or more blocks.
The output script would end up something like
IF
<block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
<public key> OP_CHECKSIG
ENDIF
This output acts like "anyone can spend" for the one block height.
Otherwise, only the sidechain miner can spend the output.
This allows the sidechain miner to reclaim their coins if the transaction
ends up in a different block.
OP_BRIBE_VERIFY would have an additional rule
The script to fails if
one or more of the transaction outputs start with something other than
the template
<block height> does not match the block height, or
<critical hash> is not the hash for the sidechain with <sidechain_id>, or
there is no hash for that sidechain in the block's coinbase
The template is
<100> OP_CHECKSEQUENCE_VERIFY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170524/02094798/attachment.html>

2023-06-07 18:01:30

- reply

📅 Original date posted:2017-05-23
📝 Original message:On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> I would replace "Bitcoins you manage to steal" with "Bitcoins you manage
> to double-spend". Then, it still seems the same to me.
>
>
With double spending, you can only get ownership of coins that you owned at
some point in the past. Coins that are owned by someone else from coinbase
to their current owners cannot be stolen by a re-org (though they can be
moved around).
With BMM, you can take the entire reserve. Creating a group of double
spenders can help increase the reward.
>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in addition
> to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
>
>
That is a fair point. If sidechains are how Bitcoin is scaled, then
shaking confidence in a side-chain would shake confidence in Bitcoin's
future.
I wasn't thinking of a direct miner 51% attack. It is enough to assume
that a majority of the miners go with the highest bidder each time.
If (average fees) * (timeout) is less than the total reserves, then it is
worth it for a 3rd party to just bid for his theft fork. Miners don't have
to be assumed to be coordinating, they just have to be assumed to take the
highest bid.
Again, I don't really think it is that different. One could interchange
> "recent txns" (those which could be double-spent within 2-3 weeks) with
> "sidechain deposit tnxs".
>
It is not "recent txns", it is recent txns that you (or your group) have
the key for. No coordination is required to steal the entire reserve from
the sidechain.
Recent txns and money on the sidechain have the property that they are
riskier than money deep on the main chain. This is the inherent point
about sidechains, so maybe not that big a deal.
My concern is that you could have a situation where an attack is possible
and only need to assume that the miners are indifferent.
If the first attacker who tries it fails (say after creating a fork that is
90% of the length required, so losing a lot of money), then it would
discourage others. If he succeeds, then it weakens sidechains as a
concept and that creates the incentive for miners to see that he fails.
I wonder how the incentives work out. If a group had 25% of the money on
the sidechain, they could try to outbid the attacker.
In fact, since the attacker, by definition, creates an illegal fork, the
effect is that he reduces the block rate for the side chain (possibly to
zero, if he wins every auction). This means that there are more
transactions per block, if there is space, or more fees per transaction, if
the blocks are full.
In both cases, this pushes up the total fees per block, so he has to pay
more per block, weakening his attack. This is similar to where transaction
spam on Bitcoin is self-correcting by increasing the fees required to keep
the spam going.
Is there a description of the actual implementation you decided to go with,
other than the code?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/69551868/attachment.html>

2023-06-07 18:01:18

- reply

📅 Original date posted:2017-05-18
📝 Original message:On Thu, May 18, 2017 at 2:44 PM, Cameron Garnham via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 1. Significant deviations from the Bitcoin Security Model have been
> acknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Work
> function should have the same difficulty of producing a desired output.
>
This isn't really that clear.
Arguably as long as the effort to find a block is proportional to the block
difficulty parameter, then it isn't an exploit. It is just an optimisation.
A quantum computer, for example, could find a block with effort
proportional to the square root of the difficulty parameter, so that would
count as an attack. Though in that case, the fix would likely be to tweak
the difficulty parameter update calculation.
A better definition would be something like "when performing work, each
hash should be independent".
ASICBOOST does multiple checks in parallel, so would violate that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170518/8af10956/attachment.html>

2023-06-07 17:54:26

- reply

📅 Original date posted:2016-11-17
📝 Original message:On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <eric at voskuil.org> wrote:
> > This means that all future transactions will have different txids...
> rules do guarantee it.
>
> No, it means that the chance is small, there is a difference.
>
I think we are mostly in agreement then? It is just terminology.
In terms of discussing the BIP, barring a hash collision, it does make
duplicate txids impossible.
Given that a hash collision is so unlikely, the qualifier should be added
to those making claims that require hash collisions rather than those who
assume that they aren't possible.
You could have said "However nothing precludes different txs from having
the same hash, but it requires a hash collision".
Thinking about it, a re-org to before the enforcement height could allow
it. The checkpoints protect against that though.
> As such this is not something that a node
> can just dismiss.
The security of many parts of the system is based on hash collisions not
being possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161117/30a28347/attachment-0001.html>

2023-06-07 17:54:25

- reply

📅 Original date posted:2016-11-16
📝 Original message:On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Both of these cases resulted from exact duplicate txs, which BIP34 now
> precludes. However nothing precludes different txs from having the same
> hash.
>
The only way to have two transactions have the same txid is if their
parents are identical, since the txids of the parents are included in a
transaction.
Coinbases have no parents, so it used to be possible for two of them to be
identical.
Duplicate outputs weren't possible in the database, so the later coinbase
transaction effectively overwrote the earlier one.
The happened for two coinbases. That is what the exceptions are for.
Neither of the those coinbases were spent before the overwrite happened. I
don't even think those coinbases were spent at all.
This means that every activate coinbase transaction has a unique hash and
all new coinbases will be unique.
This means that all future transactions will have different txids.
There might not be an explicit rule that says that txids have to be unique,
but barring a break of the hash function, they rules do guarantee it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161117/55cc4f6a/attachment-0001.html>

2023-06-07 17:54:18

- 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 17:50:28

- 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 17:49:55

- reply

📅 Original date posted:2016-03-23
📝 Original message:There is probably not much loss due to per message encryption. Even if a
MITM determined that a message was an inv message (or bloom filter
message), it wouldn't be able to extract much information. Since the
hashes in those messages are fixed size, there is very little leakage.
You could make it so that the the encryption messages effectively create a
second data stream and break/weaken the link between message size and
wrapped message size. This requires state though, so there is a complexity
tradeoff.
There is no real need to include an IV, since you are including a 32 byte
context hash. The first 16 bytes of the context hash could be used as IV.
In terms of generating the context hash, it would be easier to make it
linear.
context_hash_n = SHA256(context_hash_(n-1) | message_(n-1))
As the session gets longer, both nodes would have to do more and more
hashing to compute the hash of the entire conversation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160323/64f754da/attachment.html>

2023-06-07 17:49:32

- reply

📅 Original date posted:2016-03-04
📝 Original message:An alternative soft fork would be to require that miners pay some of the
coinbase to a CLTV locked output (that is otherwise unlocked). This allows
the release of the funds to be delayed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160304/c1de9387/attachment.html>

2023-06-07 17:49:14

- reply

📅 Original date posted:2016-02-24
📝 Original message:You need more detail for it to be a BIP.
New Header
new_header.prev = hash of previous header's bitcoin header
new_header.small_nonce = 4 byte nonce
new_header.big_nonce = 8 byte nonce
new_header.... (Can contain any new fields desired)
Fake Block
block.version = 4
block.prev = new_header.prev
block.merkle = calculate_merkle(coinbase)
block.timestamp = block.getPreviousBlock().median_time_past + 1
block.bits = calculate_bits()
block.nonce = new_header.small_nonce
block.tx_count = 1
Coinbase
coinbase.version = 1
coinbase.tx_in_count = 0
coinbase.tx_out_count = 1
coinbase.tx_out[0].value = 0
coinbase.tx_out[0].pk_script = "OP_RETURN"
This is a "nuclear option" attack that knocks out the main chain. The
median time past will increase very slowly. It only needs to increase by 1
every 6th blocks. That gives an increase of 336 seconds for every
difficulty update. This will cap the update rate, so give an increase of
4X every doubling.
The new headers will end up not meeting the difficulty, so they will
presumably just repeat the last header?
If the bitcoin chain stays at constant difficulty, then each quadrupling
will take more time.
After 2 weeks: 4XDiff (2 weeks per diff period)
After 10 weeks: 16XDiff (8 weeks per diff period)
After 42 weeks: 256XDiff (32 weeks per diff period)
On Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> https://github.com/bitcoin/bips/pull/340
>
> BIP: ?
> Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
> Author: James Hilliard <james.hilliard1 at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2016-02-23
>
> ==Abstract==
>
> Use a staged hard fork to implement a headers format change that is
> merge mine incompatible along with a timewarp to kill the previous
> chain.
>
> ==Specification==
>
> We use a block version flag to activate this fork when 3900 out of the
> previous 4032 blocks have this the version flag set. This flag locks
> in both of the below stages at the same time.
>
> Merge Mine Stage: The initial hard fork is implemented using a merge
> mine which requires that the original pre-fork chain be mined with a
> generation transaction that creates no new coins in addition to not
> containing any transactions. Additionally we have a consensus rule
> that requires that ntime be manipulated on the original chain to
> artificially increase difficulty and hold back the original chain so
> that all non-upgraded clients can never catch up with current time.
> The artificial ntime is implemented as a consensus rule for blocks in
> the new chain.
>
> Headers Change Stage: This is the final stage of the hard fork where
> the header format is made incompatible with merge mining, this is
> activated ~50,000 blocks after the Merge Mine Stage and only at the
> start of the 2016 block difficulty boundary.
>
> ==Motivation==
>
> There are serious issues with pooled mining such as block withhold
> attacks that can only be fixed by making major changes to the headers
> format.
>
> There are a number of other desirable header format changes that can
> only be made in a non-merge mine compatible way.
>
> There is a high risk of there being two viable chains if we don't have
> a way to permanently disable the original chain.
>
> ==Rationale==
>
> Our solution is to use a two stage hard fork with a single lock in period.
>
> The first stage is designed to kill off the previous chain by holding
> back ntime to artificially increase network difficulty on the original
> chain to the point where it would be extremely difficult to mine the
> 2016 blocks needed to trigger a difficulty adjustment. This also makes
> it obvious to unupgraded clients that they are not syncing properly
> and need to upgrade.
>
> By locking in both stages at the same time we ensure that any clients
> merge mining are also locked in for the headers change stage so that
> the original chain is dead by the time the headers change takes place.
>
> We timewarp over a year of merge mining to massively increase the
> difficulty on the original chain to the point that it would be
> incredibly expensive to reduce the difficulty enough that the chain
> would be able to get caught up to current time.
>
> ==Backward Compatibility==
>
> This hardfork will permanently disable all nodes, both full and light,
> which do not explicitly add support for it.
> However, their security will not be compromised due to the implementation.
> To migrate, all nodes must choose to upgrade, and miners must express
> supermajority support.
>
> ==Reference Implementation==
>
> TODO
> _______________________________________________
> 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/20160224/a97dd885/attachment.html>

2023-06-07 17:49:09

- reply

📅 Original date posted:2016-02-12
📝 Original message:On Fri, Feb 12, 2016 at 5:02 AM, <jl2012 at xbt.hk> wrote:
> Seems it could be done without any new opcode:
>
The assumption was that the altcoin would only accept standard output
scripts. Alice's payment in step 2 pays to a non-standard script.
This is an improvement over the cut and choose, but it will only work for
coins which allow non-standard scripts (type 2 in the BIP).
I guess I was to focused on maintaining standard scripts on the altcoin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160212/0b4e1726/attachment.html>

2023-06-07 17:49:08

- reply

📅 Original date posted:2016-02-11
📝 Original message:There was some discussion on the bitcointalk forums about using CLTV for
cross chain transfers.
Many altcoins don't support CLTV, so transfers to those coins cannot be
made secure.
I created a protocol. It uses on cut and choose to allow commitments to
publish private keys, but it is clunky and not entirely secure.
I created a BIP draft for an opcode which would allow outputs to be locked
unless a private key was published that matches a given public key.
https://github.com/TierNolan/bips/blob/cpkv/bip-cprkv.mediawiki
<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/20160211/161c3dd9/attachment.html>

2023-06-07 17:48:52

- reply

📅 Original date posted:2016-02-07
📝 Original message:This is a specific implementation of the "nuclear option" soft fork (or
"firm-fork").
The problem with any hard-fork (like) change is that there is an incentive
to add as much as possible and then the process gets bogged down.
Since the POW is based on the header 1, you could make header 3
expandable. This would allow adding new fields later.
This could be used for other block commitments. This would save having to
make the merkle tree a sum tree immediately. At a later time, the sum-tree
root could be added. (I think you also need to commit the path to the first
entry in the sum-tree, in order to get compact proofs). There could be
separate sum-trees for each counter (sigops, block size, tx count, sighash?)
Having a dedicated hard fork and soft fork counter is a good idea. There
should also be a field for parallel soft forks. Incrementing the soft fork
counter could set the bitfield soft forks back to zero. Ideally, each soft
fork would have a yes and no bit. If > 50% vote No, then it fails adoption.
The effect of this change is that nodes react to hard forks by stalling the
chain. The hard fork counter means that the new rules could be that nodes
should do that going forward for all new hard forks.
- soft fork (bitfield or count) => warn user that a soft fork has happened
- hard fork count increase => warn user that update is required and don't
process any more blocks
This means that header3 should be kept as simple as possible.
- 2 bytes: hardfork block version
- 2 bytes: softfork block version
- 4 bytes: softfork bitfields
- 32 byte: hash(header4)
Header4 and everything else in the block could be changed when a hard fork
happens. The merged mining rules and header3 would be fixed.
I think confirmation counts should be based on even numbers, i.e. 3800 of
4000, but that is an aesthetic issue and doesn't really matter.
A section on recommendations for the different client types would be useful.
If 1000 of the last 2000 blocks are votes for a hard fork, then warn the
user that a hard fork is being considered
If 4000 of the last 4463 blocks are votes for a hard fork, then warn the
user that a hard fork is likely to occur within the next few days
If a hard fork happens:
- shut down transaction processing
- inform the user that a hard fork has happened
Non-upgraded miners could blacklist the hard forking block and keep mining
on their own chain. Their chain would never reach the threshold to trigger
the hard fork. It would max out at 4323 blocks of the last 4463.
Ironically, if users did this, it would defeat some of the benefit of using
the hard fork field.
Users should definitely be given the option of accepting or rejecting the
hard fork. Otherwise, miners can hard-fork at will, which isn't desirable.
<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/20160207/4f6fd01b/attachment.html>

2023-06-07 17:47:47

- reply

📅 Original date posted:2016-01-11
📝 Original message:On Mon, Jan 11, 2016 at 11:57 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
> else:
> script = "CHECKSIG %s OP_DROP" % (prev_hash, const_pub_key)
>
That should be
script = "%s CHECKSIG %s OP_DROP" % (const_pub_key, prev_hash)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160112/f404e9db/attachment.html>

2023-06-07 17:47:13

- reply

📅 Original date posted:2015-12-20
📝 Original message:This is essentially the "nuclear option". You are destroying the current
chain (converting it to a chain of coinbases) and using the same POW to
start the new chain. You are also giving everyone credit in the new chain
equal to their credit in the old chain.
It would be better if the current chain wasn't destroyed.
This could be achieved by adding the hash of an extended block into the
coinbase but not requiring the coinbase to be the only transaction.
The new block is the legacy block plus the associated extended block.
Users would be allowed to move money to the extended block by spending it
to a specific output template.
<public key hash> OP_1 OP_TO_EXTENDED OP_TRUE
OP_1 is the extended block index and initially, only one level is available.
This would work like P2SH. Users could spend the money on the extended
block chain exactly as they could on the main chain.
Money can be brought back the same way.
<public key hash> <txid1> <txid2> ... <txid-n> <N> OP_0 OP_UNLOCK OP_TRUE
The txids are for transactions that have been locked in root chain. The
transaction is only valid if they are all fully funded. The fee for the
transaction would be fee - (cost to fund unlocked txids). A negative fee
tx would be invalid.
This has the advantage that it keeps the main chain operating. People can
still send money with their un-upgraded clients. There is also an
incentive to move funds to the extended block(s). The new extended blocks
are more complex, but potentially have lower fees. Nobody is forced to
change. If the large blocks aren't needed, nobody will both to use them.
The rule could be
Now:
0) 1 MB
After change over
0) 1 MB
1) 2 MB
After 2 years
0) 1 MB
1) 2 MB
2) 4MB
After 4 years
0) 1 MB
1) 2 MB
2) 4MB
3) 8MB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/aba78371/attachment.html>

2023-06-07 17:47:01

- 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 17:47:01

- 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 17:44:22

- reply

📅 Original date posted:2015-11-10
📝 Original message:The network protocol is not quite consensus critical, but it is important.
Two implementations of the decompressor might not be bug for bug
compatible. This (potentially) means that a block could be designed that
won't decode properly for some version of the client but would work for
another. This would fork the network.
A "raw" network library is unlikely to have the same problem.
Rather than just compress the stream, you could compress only block
messages only. A new "cblock" message could be created that is a
compressed block. This shouldn't reduce efficiency by much.
If a client fails to decode a cblock, then it can ask for the block to be
re-sent as a standard "block" message.
This means that it is a pure performance improvement. If problems occur,
then the client can just switch back to uncompressed mode for that block.
You should look into the block relay system. This gives a larger
improvement than simply compressing the stream. The main benefit is
latency but it means that actual blocks don't have to be sent, so gives a
potential 50% compression ratio. Normally, a node receives all the
transactions and then those transactions are included later in the block.
On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> I think 25% bandwidth savings is certainly considerable, especially for
>> people running full nodes in countries like Australia where internet
>> bandwidth is lower and there are data caps.
>>
>
> This reinforces the idea that such trade-off decisions should be be local
> and negotiated between peers, not a required feature of the network P2P.
>
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
> _______________________________________________
> 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/20151110/81ba0c7c/attachment-0001.html>

2023-06-07 17:44:18

- 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 17:44:17

- 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 17:43:40

- 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 17:41:17

- reply

📅 Original date posted:2015-09-24
📝 Original message:On Thu, Sep 24, 2015 at 7:02 PM, Suhas Daftuar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> I'm proposing the addition of a new, optional p2p message to help improve
> the way blocks are announced on the network. The draft BIP is available
> here and pasted below:
> https://gist.github.com/sdaftuar/465bf008f0a4768c0def
>
> The goal of this p2p message is to facilitate nodes being able to
> optionally announce blocks with headers messages rather than with inv's,
> which is particularly beneficial since the introduction of headers-first
> download in Bitcoin Core 0.10. In particular, this allows for more
> efficient propagation of reorgs as it would eliminate a round trip in
> network communication.
>
Is there actually a requirement for the new message? New nodes could just
unilaterally switch to sending headers and current nodes would be
compatible.
It looks like the only DOS misbehaving penalty is if the header is invalid
or if the headers don't form a chain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150924/8eeade53/attachment.html>

2023-06-07 17:41:10

- reply

📅 Original date posted:2015-09-23
📝 Original message:On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Imagine miners always pre-announce the blocks they're working on to their
> peers, and peers validate those 'weak blocks' as quickly as they are able.
>
> Because weak blocks are pre-validated, when a full-difficulty block based
> on a previously announced weak block is found, block propagation should be
> insanely fast-- basically, as fast as a single packet can be relayed across
> the network the whole network could be mining on the new block.
>
> I don't see any barrier to making accepting the full-difficulty block and
> CreateNewBlock() insanely fast, and if those operations take just a
> microsecond or three, miners will have an incentive to create blocks with
> fee-paying transactions that weren't in the last block, rather than mining
> empty blocks.
>
You can create these blocks in advance too.
- receive weak block
- validate
- create child block
It becomes a pure array lookup to get the new header that builds on top of
that block. The child blocks would need to be updated as the memory pool
changes though.
> A miner could try to avoid validation work by just taking a weak block
> announced by somebody else, replacing the coinbase and re-computing the
> merkle root, and then mining. They will be at a slight disadvantage to
> fully validating miners, though, because they WOULD have to mine empty
> blocks between the time a full block is found and a fully-validating miner
> announced their next weak block.
>
This also speeds up propagation for the miner. The first weak block that
is broadcast could end up being copied by many other miners.
A miner who is copying a block could send coinbase + original header if he
hits a block. Weak blocks that are just coinbase + header could have lower
POW requirements, since they use up much less bandwidth.
Miners would mostly copy other miners once they had verified their blocks.
The IBLT system works well here. A miner could pick a weak block that is
close to what it actually wants to broadcast.
> Weak block announcements are great for the network; they give transaction
> creators a pretty good idea of whether or not their transactions are likely
> to be confirmed in the next block.
>
Aggregator nodes could offer a service to show/prove how many weak blocks
that the transaction has been accepted in.
> And if we're smart about implementing them, they shouldn't increase
> bandwidth or CPU usage significantly, because all the weak blocks at a
> given point in time are likely to contain the same transactions.
>
This assumes other compression systems for handling block propagation.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3004f4bf/attachment.html>

2023-06-07 17:41:07

- reply

📅 Original date posted:2015-09-27
📝 Original message:On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Unless the weak block transaction list can be a superset of the block
> transaction list size proportional propagation costs are not totally
> eliminated.
>
The POW threshold could be dynamic. The first weak-block that builds on a
new block could be forwarded with a smaller target.
This reduces the window size until at least one weak block is propagated.
The change in threshold could be time based (for the first 30 seconds or
so). This would cause a surge of traffic when a new block once a new block
has propagated, so perhaps not so good an idea.
> As even if the weak block criteria is MUCH lower than the block
> criteria (which would become problematic in its own right at some
> point) the network will sometimes find blocks when there hasn't been
> any weak block priming at all (e.g. all prior priming has made it into
> blocks already).
>
If there is a transaction backlog, then miners could forward merkle
branches with transactions in the memory pool with a commitment in the
coinbase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150927/a0f6ff63/attachment.html>

2023-06-07 17:40:09

- 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 17:40:07

- reply

📅 Original date posted:2015-09-17
📝 Original message:On Wed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> The exact numbers (95% vs. 75% etc) don't need to be completely specified
> to start working on an implementation. What really matters for now is
> defining the states and trigger mechanisms. I'd rather we not argue over
> the optimal values for supermajority requirement at this point.
>
The discussion was about what each state means, not the thresholds
exactly. I agree that can be set later.
On Wed, Sep 16, 2015 at 10:03 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks)
> and wait for 95% for consensus activation (which is my preference and
it's much simpler to implement).
> What are the disadvantages of my approach? What are the advantages of
yours?
I agree that miners should apply the rule from the start in their own
blocks.
*defined*
Miners set bit
Miners apply rule to their own blocks
If 75% of blocks of last 2016 have bit set, goto tentative
*tentative*
Miners set bit
Miners apply rule to their own blocks
Miners enforce rule in blocks with bit set (reject invalid blocks)
If 95% of blocks of last 2016 have bit set, goto locked-in
*locked-in*
Point of no return
Miners set bit
Miners apply rule to their own blocks
Miners enforce rule in blocks with bit set (reject invalid blocks)
After 2016 blocks goto activated
*activated*
Miners don't set bit
Reject any block that has the bit set for 10080 blocks (10 diff periods)
Reject blocks that don't follow new rule
The advantage of enforcing the rule when 75% is reached (but only for
blocks with the bit set) is that miners get early notification that they
have implemented the rule incorrectly. They might produce blocks that
they think are fine, but which aren't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150917/10045fa6/attachment.html>

2023-06-07 17:40:04

- reply

📅 Original date posted:2015-09-16
📝 Original message:On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''. Transitions are considered after each
> retarget period.
>
I think the 75% rule should be maintained. It confirms that miners who are
setting the bit are actually creating blocks that meet the new rule (though
it doesn't check if they are enforcing it).
What is the reason for aligning the updated to the difficulty window?
*defined*
Miners set bit
If 75% of blocks of last 2016 have bit set, goto tentative
*tentative*
Miners set bit
Reject blocks that have bit set that don't follow new rule
If 95% of blocks of last 2016 have bit set, goto locked-in
*locked-in*
Point of no return
Miners still set bit
Reject blocks that have bit set that don't follow new rule
After 2016 blocks goto notice
*activated*
Miners don't set bit for at least 10080 blocks
Reject blocks that don't follow new rule
'''Failure: Timeout'''
> A soft fork proposal should include a ''timeout''.
>
I think counting in blocks is easier to be exact here.
If two bits were allocated per proposal, then miners could vote against
forks to recover the bits. If 25% of the miners vote against, then that
kills it.
In the rationale, it would be useful to discuss effects on SPV clients and
buggy miners.
SPV clients should be recommended to actually monitor the version field.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/37241dd5/attachment.html>

2023-06-07 17:39:20

- reply

📅 Original date posted:2015-09-03
📝 Original message:On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 1.
>
> hardLimit floats within the range 1-32M, inclusive.
>
>
>
Does the 32MB limit actually still exist anywhere in the code? In effect,
it is re-instating a legacy limitation.
The message size limit is to minimize the storage required per peer. If a
32MB block size is required, then each network input buffer must be at
least 32MB. This makes it harder for a node to support a large number of
peers.
There is no reason why a single message is used for each block. Using the
merkleblock message (or a different dedicated message), it would be
possible to send messages which only contain part of a block and have a
limited maximum size.
This would allow receiving parts of a block from multiple sources.
This is a separate issue but should be considered if moving past 32MB block
sizes (or maybe as a later protocol change).
>
> 1. Changing hardLimit is accomplished by encoding a proposed value
> within a block's coinbase scriptSig.
> 1. Votes refer to a byte value, encoded within the pattern
> "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If
> there is more than one match with with pattern, the first match is counted.
>
> Is there a need for byte resolution? Using MB resolution would use up
much fewer bytes in the coinbase.
Even with the +/- 20% rule, miners could vote for the nearest MB. Once the
block size exceeds 5MB, then there is enough resolution anyway.
> 1. Absent/invalid votes and votes below minimum cap (1M) are counted
> as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes.
>
>
I think abstains should count for the status quo. Votes which are out of
range should be clamped.
Having said that, if core supports the change, then most miners will
probably vote one way or another.
> New hardLimit is the median of the followings:
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
I think this is unclear, though mathematically exact.
Sort the votes for the last 12,000 blocks from lowest to highest.
Blocks which don't have a vote are considered a vote for the status quo.
Votes are limited to +/- 20% of the current value. Votes that are out of
range are considered to vote for the nearest in range value.
The raise value is defined as the vote for the 2400th highest block (20th
percentile).
The lower value is defined as the vote for the 9600th highest block (80th
percentile).
If the raise value is higher than the status quo, then the new limit is set
to the raise value.
If the lower value is lower than the status quo, then the new limit is set
to the lower value.
Otherwise, the size limit is unchanged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/765fb2ef/attachment-0001.html>

2023-06-07 17:37:25

- reply

📅 Original date posted:2015-08-20
📝 Original message:The economic majority is defined as the will of those who actually use
Bitcoin as a payment system.
No matter what the miners want, if users and merchants refuse to accept
their fork, then the fork loses and cannot be considered the "true" bitcoin
fork.
The problem is that it is easy to measure a miner vote. The economic
majority is not so easy.
The relative value of two forks could be compared by adding a system
similar colored coins.
These contracts could be added with a soft fork like the P2SH one.
OP_IF
<fork_id1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script 1>
OP_EQUAL
OP_ENDIF
OP_IF
<fork_id3> OP_DROP OP_HASH160 <hash script 2> OP_EQUAL
OP_ENDIF
This works like P2SH and is template matching. You can have as many
entries as you want.
In the example, the output can be spent on fork 1 and fork 2 by the owner
of <hash script 1> and can be spent on fork 3 by the owner of <hash script
2>.
Until the deadline, the value on each fork must be preserved when spending
the output. If you provide the key(s), you are allowed to consolidate
entries. You can also consolidate multiple outputs to the same key even if
you don't have the key.
This means that split outputs are a little more hassle to use and the
transactions are larger. This doesn't matter much, since measuring the
relative value of the two sub-coins only requires some of them to be traded.
If someone wants to propose a hard fork, they create a new fork id and
deadline and release software that implements the hard fork at the given
deadline (no miner vote needed).
To prevent spam, there could be a cost to create a fork-id (BTC paid to
OP_RETURN) and the deadline could have a max time in the future (say 2
years).
After the deadline, core will allow conversion of outputs that pay to the
core fork-id (probably 1) to be converted into unencumbered outputs by the
person with the core-id script. Likewise, the fork software will allow
outputs that pay to the fork id to be converted. Legacy bitcoin that
haven't been "split" will be spendable on both sides equally.
This means that users can convert x legacy bitcoin into x fork-bitcoins and
x core-bitcoins in advance of the fork.
This means that Exchanges could support trading between the two. The side
that trades with the most value is the one that is supported by the
economic majority.
As it becomes clear which side is going to win, the price of coins on the
losing side should drop. It is unlikely that the two would stay at exactly
the same value without one side winning.
Users who want to to use the losing rules are free to do so but the
economic majority will have made its decision.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/4e500973/attachment.html>

2023-06-07 17:36:43

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 4:22 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Will the adoption of BitcoinXT lead by miners? No, it won't. Actually,
> Chinese miners who control 60% of the network has already said that they
> would not adopt XT. So they must not be the leader in this revolution.
> Again, miners need to make sure they could sell their bitcoin in a good
> price, and that's not possible without support of exchanges and investors.
>
So, the exchanges get together to "encourage" the miners to start running
bitcoin-XT. What would they do?
One scheme would be to create a taint system. All non-XT coinbases outputs
are marked as tainted. All outputs are tainted if any of the inputs into a
transaction are tainted. Tainted coins can only be un-tainted by sending
0.5% of their value to the public address of one of the participating
exchanges (or to OP_RETURN). They could slowly ratchet up the surcharge.
Exchanges in the cartel agree not to exchange tainted coins. Even if some
still do, the tainted coins are still inherently less valuable, since fewer
exchanges accept them.
Schemes like that are the main way for non-miners to flex their muscles,
even if they seem unsavory.
Taint tracking would allow merchants to participate. They could give less
credit for tainted bitcoins, even if the exchanges are trying to remain
neutral. If that happens, the exchanges could run 2 prices, BTC and
BTC-tainted.
On the other hand, implementing taint machinery is a bad thing for
fungibility.
It can also be accomplished with checkpointing. They need to create 1 big
block and then agree to checkpoint it.
A less strict rule rule could be that blocks after the first big block
count as double POW. That means that the big block chain only needs 34% of
the hashing power to win.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/5ac4a299/attachment.html>

2023-06-07 17:36:20

- 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:34:59

- reply

📅 Original date posted:2015-08-25
📝 Original message:On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Assuming a maximum of 1-year relative lock-times. But what is an
> appropriate maximum to choose? The use cases I have considered have only
> had lock times on the order of a few days to a month or so. However I would
> feel uncomfortable going less than a year for a hard maximum, and am having
> trouble thinking of any use case that would require more than a year of
> lock-time. Can anyone else think of a use case that requires >1yr relative
> lock-time?
>
>
The main advantage of relative locktime over absolute locktime is in
situations when it is not possible to determine when the clock should
start. This inherently means lower delays.
As a workaround, you could chain transactions to extend the relative
locktime.
Transaction B has to be 360 days after transaction A and then transaction C
has to be 360 days after transaction B and C must be an input into the
final transaction.
The chain could be built up with multi-sig, like the refund transaction
system, so no one person can create an alternative chain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150825/dc8e64fa/attachment.html>

2023-06-07 17:32:58

- reply

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 8:50 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> --------------------
> Voting system
>
> Single transferable vote is applied. (
> https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are
> required to rank their preference with “1”, “2”, “3”, etc, or use “N” to
> indicate rejection of a candidate.
> Vote counting starts with every voter’s first choice. The candidate with
> fewest votes is eliminated and those votes are transferred according to
> their second choice. This process repeats until only one candidate is left,
> which is the most popular candidate. The result is presented as the
> approval rate: final votes for the most popular candidate / all valid votes
>
> After the most popular candidate is determined, the whole counting process
> is repeated by eliminating this candidate, which will find the approval
> rate for the second most popular candidate. The process repeats until all
> proposals are ranked with the approval rate calculated.
>
Instant runoff voting is not a good system for finding a consensus of the
voters.
http://zesty.ca/voting/sim/
The main issue here is the "Squeezing out" of center opinions.
If the middle option is acceptable to almost everyone but is only the top
choice of 20%, then it will lose in round one and leave only extreme
options remaining.
Approval is a better system for a consensus.
Each voter can indicate which of the proposals is approved/accepted and the
option with the most support wins.
If one option has 80% support and another has 90% support, then both make a
good choice (though the 90% one has won).
Range voting allows more accuracy, if that is an issue. If voters are
honest, it allows a middle ground to be reached.
If everyone votes strategically, it becomes approval voting. With
consensus, there is an assumption that a significant fraction of the
community would be willing to be honest rather than strategic.
The outcome is possible a final decision but not a binding decision.
Voters need to recognise that failing to find a middle ground could mean
they get their way but they split the community.
Additionally, since the point is to determine parameters, you don't
necessarily need to select from discrete candidates.
- Initial new size
- Rate of increase
- Maximum size
They are just numbers. You could have votes indicate what they want, and
then use the median as the consensus option.
The exception is to have the miners choose what the size is (subject to
limits). That option is already entirely in the hands of the miners and
they could do it unilaterally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/f82d581b/attachment.html>

2023-06-07 17:31:41

- 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 17:31:41

- reply

2023-06-07 15:46:53

- reply

2023-06-07 15:41:57

- reply

📅 Original date posted:2015-07-11
📝 Original message:On Sat, Jul 11, 2015 at 1:09 PM, Nathan Wilcox <nathan at leastauthority.com>
wrote:
>
> If there's any cost to non-SPV mining, and the chance that an incoming
> block contains only valid transactions is very high, isn't there still an
> incentive to make this timeout longer and longer?
>
The benefit drops off pretty quickly as the timeout increases (and
eventually goes negative).
You could look at it that headers having 4 states.
1) Valid
2) Probably Valid
3) Probably Invalid
4) Invalid
SPV mining puts newly received headers into the "probably valid" category.
It builds empty (coinbase only) blocks on top of probably valid headers and
build empty blocks on the header.
Once it receives the full block, it can change the state to Valid. At that
point, it can build full blocks on top of the header.
As time passes without the full block being received/validated, it becomes
less and less likely that the block is actually valid.
The timeout is to recognize that fact. Making the timeout 24 hours is not
likely to give the miner much benefit over making it 1-2 minutes.
Setting the timeout to low means that the miner sometimes switches away
from a header that turns out to be valid.
Setting it to high means that the miner ends up staying to long on a header
that turns out to be invalid.
At some point, the second effect is stronger than the first effect. The
timeout needs to be high enough so switching away from valid headers is
rare but low enough so that it doesn't stay on invalid headers for ages.
If 99% of full blocks are received (and validated) within 30 seconds of the
header arriving, then it is reasonable for the miner to assume that if the
full block hasn't arrived within 60 seconds of the header arriving, then
the header is for an invalid block.
Yes. If it's rare enough, then skipping transaction validation saves more
> cost than the expected cost of mining atop an invalid block. ... but if
> everyone follows that logic, the chance is no longer rare.
>
SPV miners don't actually produce invalid blocks though (other than
building on invalid blocks). The full blocks they produce are still fully
checked blocks.
> SPV-mining is to prevent hashing hardware from having to waste power when
>> it isn't needed.
>>
>>
> It may be less of a problem if (when?) electricity costs dominate hardware
>> capital costs.
>>
>
> Oh. This is a different explanation than Peter Todd's I linked to above,
> which claimed it was network latency in receiving transactions.
>
SPV mining is mainly to protect against latency. The reason that matters
is that latency means that hashers end up building on blocks even though a
new block has been found.
You can look at it as wasting hashing power due to latency.
In the world where minting fees are very low, there is no point in SPV
mining.
I assume at the point, the memory pool/queue is a few blocks deep. This
means that the pool can create a full block without having to wait for new
transactions to be sent in.
It still needs to wait for the new full block before it knows which
transactions to remove from its memory pool.
Pools have to pay their hashers for hashing power. When minting fees are
tiny, pools only get income only from tx fees.
There is no point in creating empty blocks, since they don't pay anything.
Between when the block is found and the pool has a new block ready to mine,
there is no incentive for the pool to give out new work. The stratum
protocol could be modified so pools can say. (It might already support
this)
<Send work to hashers>
-- block is found by some other pool --
<Cancel work for miners>
-- pool builds new block --
<Send new work to hashers>
The cancel command says that the pool will not accept any of the work that
has been made obsolete.
This gives a window of 20-30 seconds after each block where the pool has
invalidated the old work, but does not send new work. Hashers' hardware
would be stalled.
On the other hand, the pool that found the block could create a new block
straight away. There is an incentive for hashers to have a connection to
multiple pools.
Pools might go pure pay per share. The protocol would say how much they
are willing to pay for a share and the local mining proxy would pick the
most profitable pool. This eliminates pools having lots of ways of saying
how they charge fees, you just connect to lots of pools and go with the one
that pays the most.
More interestingly, the average fee per byte for transactions in the memory
pool is likely to increase as time passes since the last block.
When two blocks are found very fast one after another, the second block is
likely to have lower average fees. This is because the first block would
have included most of the high value transactions and there wasn't enough
time for new ones to arrive before the second block was found.
Hashers would end up getting variable payouts based on how long since the
last block was received. If some miners increase/decrease their output
based on the fees the pools offer, then as time passes since the last
block, the hashing rate would increase. This reduces the variation in
block to block times.
For example, if there was 1.5MB of transactions in the memory pool and they
all paid the same fee per byte, then the block would be a full block at
that rate. However, there would only be 0.5MB of transactions left. This
means that the next block would be half full and only be able to pay out
50% of the fee, but the difficulty would be the same. The pay per hash
would be 50% lower. Once 0.5MB of new transactions arrive, the fee would
be back up to the same as the previous block.
If there are major SHA256 altcoins (or side chains), then miners might end
up switching between coins. The longer a coin went without a new block
being found, the more tx fees available in the memory pool, so the more
hashing power would decide to switch to that coin.
There could be a situation where adding a few more transactions to the
memory pool of a coin would cause a 100X increasing in hashing until the
block was found and then it stalling again as the hashing power switches
away. This is similar to alt coins getting blasted by coin switching pools
and then dropping to almost no power.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150711/08dc0f8c/attachment-0001.html>

2023-06-07 15:41:56

- reply

📅 Original date posted:2015-07-11
📝 Original message:On Sat, Jul 11, 2015 at 10:24 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I think it would be more rational for them to keep mining on top of the
> old block until they've fully validated the new block (which shouldn't take
> so long anyway), even if this slightly increases the orphan rate.
Increased orphan rate means that the network is (slightly) less secure.
If miners have a 5% orphan rate, then an attacker can launch a 51% attack
with 49% of the network.
It isn't a massive difference, but it is there.
As long as miners switch back to non-SPV mining after a timeout, SPV-mining
is safe for everyone.
The average cost to the miner from building on an invalid block is small,
as long as invalid blocks only happen rarely.
Miners still have an incentive to do full validation, so that they can
include transactions and get transaction fees.
SPV-mining is to prevent hashing hardware from having to waste power when
it isn't needed.
It may be less of a problem if (when?) electricity costs dominate hardware
capital costs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150711/eda24489/attachment.html>

2023-06-07 15:41:40

- reply

📅 Original date posted:2015-07-04
📝 Original message:On Sat, Jul 4, 2015 at 5:01 PM, Justus Ranvier <
justus at openbitcoinprivacyproject.org> wrote:
> How do we know if a committed UTXO set is valid? If a majority of the
> hashing power is willing to extend an invalid branch, it's reasonable to
> assume they'd be willing to commit an invalid UTXO set as well.
>
You can prove that it wasn't updated correctly.
For each transaction, the UTXO tree root before and after is committed.
You show the root before, and the root after and show that the after root
is wrong. You also need to include some merkle paths to prove the
transform.
> If items in the the proof tree are required to be sorted, then it's easy
> to proof that an item is missing.
>
Yes, you can mostly get short proofs for each step, but you have to make
sure your proofs are also provable.
It means going through everything that needs to be proved for a block to be
valid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/51ecf7e0/attachment.html>

2023-06-07 15:40:35

- 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 15:40:25

- reply

📅 Original date posted:2015-06-25
📝 Original message:It would be possible to run a simplified version of the bits proposal,
until BIP 66 locks.
It's obviously not worth it at this point though, though it could be 1-2
weeks more.
Version 2 means neither option
Version 3 means BIP 66 only
Version 4 means CLTV only
Version 5 means both
If (Version 3 + version 5) > 95%, reject 2 & 4
If (Version 4 + version 5) > 95%, reject 2 & 3
For 2 options at the same time, this isn't much extra overhead.
On Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Please do it.
> On Jun 25, 2015 3:33 PM, "Peter Todd" <pete at petertodd.org> wrote:
>
>> BIP66 adoption is quite close to 95% and will likely be enforced for all
>> blocks in a few more days; now is time to think about how CLTV will be
>> deployed, particularly given its benefits to much-needed scalability
>> solutions such as payment channels.
>>
>> While I'm both a fan and co-author of the Version bits BIP(1) proposal,
>> it hasn't been implemented yet, and the implementation will be
>> relatively complex compared to the previous soft-fork mechanism. I think
>> there is good reason to get CLTV deployed sooner, and I don't think we
>> have any lack of consensus on it. The CLTV code itself has been
>> extensively reviewed in the form of the "mempool-only" pull-req, has
>> been included in the Elements sidechain prototype by Mark Friedenbach,
>> has been running in production on Viacoin for six months, and has a few
>> working demos of its functionality implemented. It's also been famously
>> described as "What you thought nLockTime did until you actually tried to
>> use it."
>>
>> To that end I'm proposing that we simply use the existing median block
>> version mechanism previously used for the nVersion=2 and nVersion=3
>> soft-forks for CLTV. This mechanism is well-tested and understood, and
>> would allow CLTV to be easily backported to v0.10.x (even 0.9.x) with
>> little risk for rapid deployment. In the event that another soft-fork is
>> proposed prior to BIP65, nVersion=4, enforcement, we do have the option
>> of setting in motion yet another soft-fork as the median mechanism only
>> requires forks to be serialized in sequence - it does not prevent
>> multiple soft-forks from being "in-flight" at the same time.
>>
>> Thoughts? If there are no objections I'll go ahead and write that code,
>> using the same thresholds as BIP66.
>>
>> 1)
>> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>>
>> _______________________________________________
>> 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/20150626/c1658179/attachment-0001.html>

2023-06-07 15:39:53

- reply

📅 Original date posted:2015-06-22
📝 Original message:On Mon, Jun 22, 2015 at 8:32 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com
> wrote:
>
> Since it's possible that block timestamps aren't chronological in order,
> what would happen if a block following a size increase trigger is back in
> the past before the size increase? Would that block have a lower size
> restriction again? Would using block height not be a more stable number to
> work with?
>
The activation or not rule is purely timestamp based. Blocks with a
timestamp less than 1452470400 have a limit of 1MB. There could be an 8MB
block followed by a block that is limited to 1MB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/2fbf6432/attachment.html>

2023-06-07 15:39:52

- reply

📅 Original date posted:2015-06-26
📝 Original message:On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <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.
BIP 100 and 101 could be combined. Would that increase consensus?
- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/03a1d7e6/attachment.html>

2023-06-07 15:39:25

- reply

📅 Original date posted:2015-06-20
📝 Original message:I agree giving notice that the change is going to happen is critical for a
hard fork. If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).
The BIP 100 proposal is that no change will happen until a timestamp is
reached. It isn't clear exactly how it would work.
Testnet: Sep 1st 2015
Mainnet: Jan 11th 2016
It suggests 90% of 12000 blocks (~83 days).
This means that if 10800 of the last 12000 blocks are the updated version,
then the change is considered locked in.
I think having an earlier "fail" threshold would be a good idea too. This
guarantees notice.
Assuming 3 is <old rule> and 4 is <new rule>
If the median of 11 timestamp is after 1st Sep 2015 and less than 10800 of
the last 12000 blocks are version 4+, then reject version 4 blocks
If the median of 11 timestamp is after 1st Nov 2015 and at least 10800 of
the last 12000 blocks are version 4+, then reject version 3 blocks
(lock-in)
If the median of 11 timestamp is after 1st Jan 2016 and at least 10800 of
the last 12000 blocks are version 4+, the allow <new rule>
This means that if the 90% threshold is lost at any time between 1st Sep
and 1st Nov, then the fork is rejected. Otherwise, after the 1st Nov, it
is locked in, but the new rules don't activate until 1st Jan.
For block size, miners could still soft fork back to 1MB after 1st Nov, it
there is a user/merchant revolt (maybe that would be version 5 blocks).
On Sat, Jun 20, 2015 at 6:13 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150620/564e4909/attachment.html>

2023-06-07 15:37:03

- reply

📅 Original date posted:2015-06-09
📝 Original message:On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that are part of long chains of unconfirmed transactions.
> 3. Allow blocks to grow in size in times of high transaction demand.
>
>
I think 2 should just be fee per kB. If the pool is full and a transaction
arrives, it has to have a fee per kB that is higher than the lowest
transaction in the pool.
The effect is that the fee per kB threshold for getting a transaction into
the memory pool increases as the attack proceeds. This means that the cost
to maintain the attack increases.
With replace by fee, the new transaction would have to have a fee that is
more than a fixed amount more than the lowest already in the pool. I think
the replace by fee code already does this. This prevents transactions with
fees that increase by 1 Satoshi at a time being relayed.
For allowing large blocks when block space is in high demand, you could
limit the average block size.
If the average was set to 1MB, the rule could be that blocks must be 2MB or
lower and the total size of the a block and the previous 99 must be 100MB
or lower. This gives an average of 1MB per block, but allows bursts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/5034b5a7/attachment.html>

2023-06-07 15:36:27

- reply

📅 Original date posted:2015-06-02
📝 Original message:I am glad to see the transaction version number increase. The commit
doesn't update the default transaction version though. The node would
still produce version 1 transactions.
Does the reference client already produce transactions with final sequence
numbers? If so, then they will be valid version 2 transactions. If it
sets the sequence to all zeros, then it won't trigger the new code either.
I think simply bumping the default version number to 2 would be safe.
For the timestamp locktime, median block time would be better than raw
block time. Median time is the median timestamp of the previous 11
blocks. This reduces the incentive to mess with the timestamp. Median
time is earlier than block time, but since things are relative, it should
balance out.
Miners have around 2 hours worth of flexibility when setting the
timestamps, so it may not be that big a deal.
On Tue, Jun 2, 2015 at 5:34 AM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right
> before, and then check that the input spending the prevout has nSequence
> corresponds to at least the sequence specified by the stack value. Good
> idea! Keeps the script code from depending on external chain specific data,
> which is nice.
>
> Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
> one for OP_CHECKSEQUENCEVERIFY. Very complementary.
>
> Best,
> Stephen
>
>
> On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> You are correct! I am maintaining a 'checksequenceverify' branch in my
>> git repository as well, an OP_RCLTV using sequence numbers:
>>
>> https://github.com/maaku/bitcoin/tree/checksequenceverify
>>
>> Most of the interesting use cases for relative lock-time require an RCLTV
>> opcode. What is interesting about this architecture is that it possible to
>> cleanly separate the relative lock-time (sequence numbers) from the RCLTV
>> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
>> CLTV, the CSV opcode only checks transaction data and requires no
>> contextual knowledge about block headers, a weakness of the other RCLTV
>> proposals that violate the clean separation between libscript and
>> libconsensus. In a similar way, this BIP proposal only touches the
>> transaction validation logic without any impact to script.
>>
>> I would like to propose an additional BIP covering the
>> CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one
>> thing at a time.
>>
>> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <
>> stephencalebmorse at gmail.com> wrote:
>>
>>> Hi Mark,
>>>
>>> Overall, I like this idea in every way except for one: unless I am
>>> missing something, we may still need an OP_RCLTV even with this being
>>> implemented.
>>>
>>> In use cases such as micropayment channels where the funds are locked up
>>> by multiple parties, the enforcement of the relative locktime can be done
>>> by the first-signing party. So, while your solution would probably work in
>>> cases like this, where multiple signing parties are involved, there may be
>>> other, seen or unforeseen, use cases that require putting the relative
>>> locktime right into the spending contract (the scriptPubKey itself).
>>> When there is only one signer, there's nothing that enforces using an
>>> nSequence and nVersion=2 that would prevent spending the output until a
>>> certain time.
>>>
>>> I hope this is received as constructive criticism, I do think this is an
>>> innovative idea. In my view, though, it seems to be less fully-featured
>>> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
>>> obviously that it saves transaction space by repurposing unused space, and
>>> would likely work for most cases where an OP_RCLTV would be needed.
>>>
>>> Best,
>>> Stephen
>>>
>>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark at friedenbach.org>
>>> wrote:
>>>
>>>> I have written a reference implementation and BIP draft for a soft-fork
>>>> change to the consensus-enforced behaviour of sequence numbers for the
>>>> purpose of supporting transaction replacement via per-input relative
>>>> lock-times. This proposal was previously discussed on the mailing list in
>>>> the following thread:
>>>>
>>>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>>>
>>>> In short summary, this proposal seeks to enable safe transaction
>>>> replacement by re-purposing the nSequence field of a transaction input to
>>>> be a consensus-enforced relative lock-time.
>>>>
>>>> The advantages of this approach is that it makes use of the full range
>>>> of the 32-bit sequence number which until now has rarely been used for
>>>> anything other than a boolean control over absolute nLockTime, and it does
>>>> so in a way that is semantically compatible with the originally envisioned
>>>> use of sequence numbers for fast mempool transaction replacement.
>>>>
>>>> The disadvantages are that external constraints often prevent the full
>>>> range of sequence numbers from being used when interpreted as a relative
>>>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>>>> use in other contexts. The latter point has been partially addressed by
>>>> having the relative lock-time semantics be enforced only if the
>>>> most-significant bit of nSequence is set. This preserves 31 bits for
>>>> alternative use when relative lock-times are not required.
>>>>
>>>> The BIP draft can be found at the following gist:
>>>>
>>>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>>>
>>>> The reference implementation is available at the following git
>>>> repository:
>>>>
>>>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>>>
>>>> I request that the BIP editor please assign a BIP number for this work.
>>>>
>>>> Sincerely,
>>>> Mark Friedenbach
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150602/b83d303f/attachment.html>

2023-06-07 15:35:51

- reply

📅 Original date posted:2015-05-28
📝 Original message:On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete at petertodd.org> wrote:
> For that matter, we probably don't want to treat this as a *version*
> change, but rather a *feature* flag.
I think it is still a version change. At the moment, the 4 bytes refer to
the sequence number and afterwards they mean something else.
For relative locktime verify, I think most use cases could be block count
based and don't need to be able to count very high.
I think the main benefit is that protocols can have one party trigger a
step while giving the other party guaranteed time to respond.
*Fast Channel Close*
This assumes that malleability is fixed.
Alice creates
TXA:
output (x) to [multisig A1 & B1]
Refund:
input TXA (signed by Alice)
Output [(A2 & relative_check_locktime(150)) OR (multisig A3 & B2)]
Alice sends Refund to Bob
Bob signs it and sends it back to Alice
Alice verifies the signature, adds her own and sends it to Bob.
She broadcasts TXA (would wait until Bob confirms acceptance).
This means that both Alice and Bob have the refund transaction and can use
it to close the channel (assuming TXA is not mutated).
Alice can send money to Bob by creating a transaction which spends the
output of the refund transaction (splitting the output x-b for Alice and b
for Bob), signing it and sending it to Bob.
Alice can force Bob to close the channel by broadcasting the refund
transaction. 150 blocks later, she gets the channel deposit if he doesn't
act.
If she had sent some money to Bob, he has 150 blocks to sign the
transaction that pays him the most money and broadcast it. Alice gets the
remainder of the deposit.
Alice cannot broadcast earlier version, since Bob doesn't send her the
signed versions.
This means that the channel doesn't need a defined end date. Either party
can close the channel whenever they want.
TXA could be protected against malleability by adding a locktime path.
This would only be for use if the transaction is mutated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/c68865b7/attachment.html>

2023-06-07 15:35:48

- reply

📅 Original date posted:2015-05-27
📝 Original message:This could cause legacy transactions to become unspendable.
A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.
Legacy transactions should not have the rule applied to them.
On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete at petertodd.org> wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
>
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced. A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).
>
> It makes sequence numbers work exactly like you'd expect-- within the
> bounds of whats possible in a decentralized system. At the same time,
> all it is ... is relative nlocktime.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150527/e68c2a37/attachment.html>

2023-06-07 15:35:45

- reply

📅 Original date posted:2015-05-27
📝 Original message:I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The deadline could be matched to a "start-line". The definition would then
be something like
BIP 105
Start block: 325000
End block: 350000
Activation: 750 of 1000
Implication: 950 of 1000
Bit: 9
This would allow creation of a simple table of known BIPs. It also keeps
multiple users of the bit as strictly separate.
The alternative to the start time is that it is set equal to the deadline
or implication time of the previous user of the bit.
Was the intention to change the 95% rule. You need 750 of the last 1000 to
activate and then must wait at least 1000 for implication?
On Wed, May 27, 2015 at 4:51 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> It would also help to see the actual code changes required, which I'm sure
> will be much shorter than the explanation itself.
> On May 27, 2015 5:47 AM, "Luke Dashjr" <luke at dashjr.org> wrote:
>
>> On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
>> > Feel free to comment. As the gist does not support notifying
>> participants
>> > of new comments, I would suggest using the mailing list instead.
>>
>> I suggest adding a section describing how this interacts with and changes
>> GBT.
>>
>> Currently, the client tells the server what the highest block version it
>> supports is, and the server indicates a block version to use in its
>> template,
>> as well as optional instructions for the client to forcefully use this
>> version
>> despite its own maximum version number. Making the version a bitfield
>> contradicts the increment-only assumption of this design, and since GBT
>> clients are not aware of overall network consensus state, reused bits can
>> easily become confused. I suggest, therefore, that GBT clients should
>> indicate
>> (instead of a maximum supported version number) a list of softforks by
>> identifier keyword, and the GBT server respond with a template indicating:
>> - An object of softfork keywords to bit values, that the server will
>> accept.
>> - The version number, as presently conveyed, indicating the preferred
>> softfork
>> flags.
>>
>> Does this sound reasonable, and/or am I missing anything else?
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150527/cd5723c3/attachment.html>

2023-06-07 15:35:45

- reply

📅 Original date posted:2015-05-27
📝 Original message:On Wed, May 27, 2015 at 11:15 AM, Peter Todd <pete at petertodd.org> wrote:
> The median time mechanism is basically a way for hashing power to show
> what time they think it is. Equally, the nVersion soft-fork mechanism is
> a way for hashing power to show what features they want to support.
>
>
Fair enough. It means slightly more processing, but the median time could
be cached in the header index, so no big deal.
Block counts are inconvenient for planning, as there's no guarantee
> they'll actually happen in any particular time frame, forward and back.
>
I don't think the deadline needs to be set that accurately. A roughly 6
month deadline should be fine, but as you say a majority of miners is
needed to abuse the median time and it is already a miner poll.
Perhaps the number of blocks used in the median could be increased to
reduce "noise".
The median time could be median of the last 144 blocks plus 12 hours.
> If you assume no large reorganizations, your table of known BIPs can
> just as easily be a list of block heights even if the median time
> mechanism is used.
>
I think it makes it easier to write the code. It reduced the state that
needs to be stored per BIP. You don't need to check if the previous bips
were all accepted.
Each bit is assigned to a particular BIP for a particular range of times
(or blocks).
If block numbers were used for the deadline, you just need to check the
block index for the deadline block.
enum {
BIP_INACTIVE = 0,
BIP_ACTIVE,
BIP_LOCKED
BIP_INVALID_BLOCK,
}
int GetBIPState(block, bip)
{
if (block.height == bip.deadline) // Bit must be set to match
locked/unlocked at deadline
{
int bipState = check_supermajority(...);
if (bipState == BIP_LOCKED && (block.nVersion & bip.bit)
return BIP_LOCKED;
if (bipState != BIP_LOCKED && (block.nVersion & (~bip.bit)))
return BIP_INACTIVE;
return BIP_INVALID_BLOCK;
}
if (block.height > deadline) // Look at the deadline block to determine
if the BIP is locked
return (block_index[deadline].nVersion & bip_bit) != 0 ? BIP_LOCKED
: BIP_INACTIVE;
if (block.height < startline + I) // BIP cannot activate/lock until
startline + implicit window size
return INACTIVE;
return check_supermajority(....) // Check supermajority of bit
}
The block at height deadline would indicate if the BIP was locked in.
Block time could still be used as long as the block height was set after
that. The deadline_time could be in six months. The startline height
could be the current block height and the deadline_height could be
startline + 35000.
The gives roughly
start time = now
deadline time = now + six months
deadline height = now + eight months
The deadline height is the block height when the bit is returned to the
pool but the deadline time is when the BIP has to be accepted.
It also helps with the warning system. For each block height, there is a
set of known BIP bits that are allowed. Once the final deadline is passed,
the expected mask is zeros.
On Wed, May 27, 2015 at 11:15 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan at gmail.com> wrote:
>
> > Was the intention to change the 95% rule. You need 750 of the last 1000
> to activate and then must wait at least 1000 for implication?
>
> You need 75% to start applying it, 95% to start rejecting blocks that
> don't apply it.
>
I think the phrasing is ambiguous. I was just asking for clarification.
"Whenever I out of any W *subsequent* blocks (regardless of the block
itself) have bit B set,"
That suggests that the I of W blocks for the 95% rule must happen after
activation. This makes the rule checking harder. Easier to use the
current system, where blocks that were part of the 750 rule also count
towards the 95% rule.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150527/90a022e8/attachment.html>

2023-06-07 15:35:16

- reply

📅 Original date posted:2015-05-19
📝 Original message:On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
decker.christian at gmail.com> wrote:
> Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
> in both proposals. If we can avoid it I'd like not to have one
> transaction hashed one way and other transactions in another way.
>
The normalized TXID cannot depend on height for other transactions.
Otherwise, it gets mutated when been added to the chain, depending on
height.
An option would be that the height is included in the scriptSig for all
transactions, but for non-coinbase transctions, the height used is zero.
I think if height has to be an input into the normalized txid function, the
specifics of inclusion don't matter.
The previous txid for coinbases are required to be all zeros, so the
normalized txid could be to add the height to the txids of all inputs.
Again, non-coinbase transactions would have heights of zero.
> Is there a specific reason why that was not chosen at the time?
>
I assumed that since the scriptSig in the coinbase is specifically intended
to be "random" bytes/extra nonce, so putting a restriction on it was
guaranteed to be backward compatible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150519/acacf82f/attachment.html>

2023-06-07 15:35:15

- reply

📅 Original date posted:2015-05-16
📝 Original message:On Sat, May 16, 2015 at 4:58 AM, Stephen <stephencalebmorse at gmail.com>
wrote:
> We should make sure to consider how BIP34 affects normalized transaction
> ids, since the height of the block is included in the scriptSig ensuring
> that the txid will be different. We wouldn't want to enable replay attacks
> in the form of spending coinbase outputs in the same way they were spent
> from a previous block.
>
> So maybe normalized txids should strip the scriptSigs of all transactions
> except for coinbase transactions? This seems to make sense, since coinbase
> transactions are inherently not malleable anyway.
>
That is a good point. Since the point is the change is to use good
practice right back until the genesis block, maybe the scriptSig for
coinbases could be replaced by the height expressed as a varint. That
means that all coinbases get a unique normalized txid. The coinbases with
duplicate txids still wouldn't be spendable though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/3f138563/attachment.html>

2023-06-07 15:35:14

- reply

📅 Original date posted:2015-05-15
📝 Original message:On Fri, May 15, 2015 at 10:54 AM, s7r <s7r at sky-ip.org> wrote:
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
>
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so mutations of the signature don't
cause the normalized txid to change.
If the refund transaction refers to the parent using the normalised txid,
then it doesn't matter if the parent has a mutated signature. The
normalized transaction ignores the mutation.
If the parent is mutated, then the refund doesn't even have to be modified,
it still refers to it.
If you want a multi-level refund transaction, then all refund transactions
must use the normalized txids to refer to their parents. The "root"
transaction is submitted to the blockchain and locked down.
> b) replays
>
If there are 2 transactions which are mutations of each other, then only
one can be added to the block chain, since the other is a double spend.
The normalized txid refers to all of them, rather than a specific
transaction.
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>
Mutation is only a problem if it occurs after signing. The signature signs
everything except the signature itself.
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays.
Correct, but normalized txids are safe against replays, so are better.
I think the new signature opcode fixes things too. The question is hard
fork but clean solution vs a soft fork but a little more hassle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150515/5b2b0e9e/attachment.html>

2023-06-07 15:35:12

- reply

📅 Original date posted:2015-05-13
📝 Original message:On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
>
> This was what I was suggesting all along, sorry if I wasn't clear.
>
>
That's great. So, basically the multi-level refund problem is solved by
this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/9199160d/attachment.html>

2023-06-07 15:35:07

- reply

📅 Original date posted:2015-05-13
📝 Original message:On Wed, May 13, 2015 at 4:24 PM, Christian Decker <
decker.christian at gmail.com> wrote
> It does and I should have mentioned it in the draft, according to my
> calculations a mapping legacy ID -> normalized ID is about 256 MB in size,
> or at least it was at height 330'000, things might have changed a bit and
> I'll recompute that. I omitted the deprecation of legacy IDs on purpose
> since we don't know whether we will migrate completely or leave keep both
> options viable.
>
There are around 20 million UTXOs. At 2*32 bytes per entry, that is more
than 1GB. There are more UTXOs than transactions, but 256MB seems a little
low.
I think both IDs can be used in the merkle tree, since we lookup an ID in
> both indices we can use both to address them and we will find them either
> way.
>
The id that is used to sign should be used in the merkle tree. The hard
fork should simply be to allow transactions that use the normalized
transaction hash.
> As for the opcodes I'll have to check, but I currently don't see how they
> could be affected.
>
Agreed, the transaction is simply changed and all the standard rules apply.
> We can certainly split the proposal should it get too large, for now it
> seems manageable, since opcodes are not affected.
>
Right it is just a database update. The undo info also needs to be changed
so that both txids are included.
> Bloom-filtering is resolved by adding the normalized transaction IDs and
> checking for both IDs in the filter.
>
Yeah, if a transaction spends with a legacy txid, it should still match if
the normalized txid is included in the filter.
> Since you mention bundling the change with other changes that require a
hard-fork it might be a good idea to build a separate proposal for a
generic hard-fork rollout mechanism.
That would be useful. On the other hand, we don't want to make them to
easy.
I think this is a good choice for a hard fork test, since it is
uncontroversial. With a time machine, it would have been done this way at
the start.
What about the following:
The reference client is updated so that it uses version 2 transactions by
default (but it can be changed by user). A pop-up could appear for the GUI.
There is no other change.
All transactions in blocks 375000 to 385000 are considered votes and
weighted by bitcoin days destroyed (max 60 days).
If > 75% of the transactions by weight are version 2, then the community
are considered to support the hard fork.
There would need to be a way to protect against miners censoring
transactions/votes.
Users could submit their transactions directly to a p2p tallying system.
The coin would be aged based on the age in block 375000 unless included in
the blockchain. These votes don't need to be ordered and multiple votes
for the same coin would only count once.
In fact, votes could just be based on holding in block X.
This is an opinion poll rather than a referendum though.
Assuming support of the community, the hard fork can then proceed in a
similar way to the way a soft fork does.
Devs update the reference client to produce version 4 blocks and version 3
transactions. Miners could watch version 3 transactions to gauge user
interest and use that to help decide if they should update.
If 750 of the last 1000 blocks are version 4 or higher, reject blocks with
transactions of less than version 3 in version 4 blocks
This means that legacy clients will be slow to confirm their
transactions, since their transactions cannot go into version 4 blocks.
This is encouragement to upgrade.
If 950 of the last 1000 blocks are version 4 or higher, reject blocks with
transactions of less than version 3 in all blocks
This means that legacy nodes can no longer send transactions but can
still receive. Transactions received from other legacy nodes would remain
unconfirmed.
If 990 of the last 1000 blocks are version 4 or higher, reject version 3 or
lower blocks
This is the point of no return. Rejecting version 3 blocks means that
the next rule is guaranteed to activate within the next 2016 blocks.
Legacy nodes remain on the main chain, but cannot send. Miners mining with
legacy clients are (soft) forked off the chain.
If 1000 of the last 1000 blocks are version 4 or higher and the difficulty
retarget has just happened, activate hard fork rule
This hard forks legacy nodes off the chain. 99% of miners support this
change and users have been encouraged to update. The block rate for the
non-forked chain is ast most 1% of normal. Blocks happen every 16 hours.
By timing activation after a difficulty retarget, it makes it harder for
the other fork to adapt to the reduced hash rate.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/11fbf72e/attachment.html>

2023-06-07 15:35:06

- reply

📅 Original date posted:2015-05-13
📝 Original message:I think this is a good way to handle things, but as you say, it is a hard
fork.
CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.
This has the effect of doubling the size of the UTXO database. At minimum,
there needs to be a legacy txid to normalized txid map in the database.
An addition to the BIP would eliminate the need for the 2nd index. You
could require a SPV proof of the spending transaction to be included with
legacy transactions. This would allow clients to verify that the
normalized txid matched the legacy id.
The OutPoint would be {LegacyId | SPV Proof to spending tx | spending tx |
index}. This allows a legacy transaction to be upgraded. OutPoints which
use a normalized txid don't need the SPV proof.
The hard fork would be followed by a transitional period, in which both
txids could be used. Afterwards, legacy transactions have to have the SPV
proof added. This means that old transactions with locktimes years in the
future can be upgraded for spending, without nodes needing to maintain two
indexes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/84f2cb0a/attachment.html>

2023-06-07 15:35:00

- reply

📅 Original date posted:2015-05-12
📝 Original message:On Tue, May 12, 2015 at 6:16 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Lots of people are tossing around ideas for partial archival nodes that
> would store a subset of blocks, such that collectively the whole
> blockchain would be available even if no one node had the entire chain.
>
A compact way to describe which blocks are stored helps to mitigate against
fingerprint attacks.
It also means that a node could compactly indicate which blocks it stores
with service bits.
The node could pick two numbers
W = window = a power of 2
P = position = random value less than W
The node would store all blocks with a height of P mod W. The block hash
could be used too.
This has the nice feature that the node can throw away half of its data and
still represent what is stored.
W_new = W * 2
P_new = (random_bool()) ? P + W/2 : P;
Half of the stored blocks would match P_new mod W_new and the other half
could be deleted. This means that the store would use up between 50% and
100% of the allocated size.
Another benefit is that it increases the probability that at least someone
has every block.
If N nodes each store 1% of the blocks, then the odds of a block being
stored is pow(0.99, N). For 1000 nodes, that gives odds of 1 in 23,164
that a block will be missing. That means that around 13 out of 300,000
blocks would be missing. There would likely be more nodes than that, and
also storage nodes, so it is not a major risk.
If everyone is storing 1% of blocks, then they would set W to 128. As long
as all of the 128 buckets is covered by some nodes, then all blocks are
stored. With 1000 nodes, that gives odds of 0.6% that at least one bucket
will be missed. That is better than around 13 blocks being missing.
Nodes could inform peers of their W and P parameters on connection. The
version message could be amended or a "getparams" message of some kind
could be added.
W could be encoded with 4 bits and P could be encoded with 16 bits, for 20
in total. W = 1 << bits[19:16] and P = bits[14:0]. That gives a maximum W
of 32768, which is likely to many bits for P.
Initial download would be harder, since new nodes would have to connect to
at least 100 different nodes. They could download from random nodes, and
just download the ones they are missing from storage nodes. Even storage
nodes could have a range of W values.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/52cee4d6/attachment.html>

2023-06-07 15:34:14

- reply

📅 Original date posted:2015-05-29
📝 Original message:On Fri, May 29, 2015 at 5:39 PM, Raystonn . <raystonn at hotmail.com> wrote:
> Regarding Tier’s proposal: The lower security you mention for extended
> blocks would delay, possibly forever, the larger blocks maximum block size
> that we want for the entire network. That doesn’t sound like an optimal
> solution.
>
I don't think so. The lower security is the potential centralisation
risk. If you have your money in the "root" chain, then you can watch it.
You can probably also watch it in a 20MB chain.
Full nodes would still verify the entire block (root + extended). It is a
"nuclear option", since you can make any changes you want to the rules for
the extended chain. The only safe guard is that people have to voluntarly
transfer coins to the extended block.
The extended block might have 10-15% of the total bitcoins, but still be
useful, since they would be the ones that move the most. If you want to
store your coins long term, you move them back to the root block where you
can watch them more closely.
It does make things more complex though. Wallets would have to list 2
balances.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/27a2d71c/attachment.html>

2023-06-07 15:34:02

- 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 15:34:02

- 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 15:34:01

- 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 15:33:51

- reply

📅 Original date posted:2015-05-08
📝 Original message:Just to clarify the process.
Pledgers create transactions using the following template and broadcast
them. The p2p protocol could be modified to allow this, or it could be a
separate system.
*Input: 0.01 BTC*
*Signed with SIGHASH_ANYONE_CAN_PAY*
*Output 50BTC*
*Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE*
*Output 0.01BTC*
*Paid to OP_TRUE*
This transaction is invalid, since the inputs don't pay for the output.
The advantage of the sighash "anyone can pay" field is that other people
can add additional inputs without making the signature invalid. Normally,
any change to the transaction would make a signature invalid.
Eventually, enough other users have added pledges and a valid transaction
can be broadcast.
*Input: 0.01 BTC*
*Signed with SIGHASH_ANYONE_CAN_PAY*
*Input: 1.2 BTCSigned with SIGHASH_ANYONE_CAN_PAY*
*Input: 5 BTCSigned with SIGHASH_ANYONE_CAN_PAY*
*<etc>*
*Input: 1.3 BTCSigned with SIGHASH_ANYONE_CAN_PAYOutput 50BTC*
*Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE*
*Output 0.01BTC**Paid to OP_TRUE*
This transaction can be submitted to the main network. Once it is included
into the blockchain, it is locked in.
In this example, it might be included in block 999,500. The 0.01BTC output
(and any excess over 50BTC) can be collected by the block 999,500 miner.
The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be
spent until block 1 million. Once block 1 million arrives, the output is
completely unprotected. This means that the miner who mines block 1
million can simply take it, by including his own transaction that sends it
to an address he controls. It would be irrational to include somebody
else's transaction which spent it.
If by block 999,900, the transaction hasn't been completed (due to not
enough pledgers), the pledgers can spend the coin(s) that they were going
to use for their pledge. This invalidates those inputs and effectively
withdraws from the pledge.
On Fri, May 8, 2015 at 11:01 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> 2. "A merchant wants to cause block number 1 million to effectively
> have a minting fee of 50BTC." - why should he do that? That's the
> entire tragedy of the commons problem, no?
>
No, the pledger is saying that he will only pay 0.01BTC if the miner gets a
reward of 50BTC.
Imagine a group of 1000 people who want to make a donation of 50BTC to
something. They all way that they will donate 0.05BTC, but only if
everyone else donates.
It still isn't perfect. Everyone has an incentive to wait until the last
minute to pledge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/9fcdc606/attachment.html>

2023-06-07 15:33:50

- reply

📅 Original date posted:2015-05-07
📝 Original message:One of the suggestions to avoid the problem of fees going to zero is
assurance contracts. This lets users (perhaps large merchants or
exchanges) pay to support the network. If insufficient people pay for the
contract, then it fails.
Mike Hearn suggests one way of achieving it, but it doesn't actually create
an assurance contract. Miners can exploit the system to convert the
pledges into donations.
https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770
Consider a situation in the future where the minting fee has dropped to
almost zero. A merchant wants to cause block number 1 million to
effectively have a minting fee of 50BTC.
He creates a transaction with one input (0.1BTC) and one output (50BTC) and
signs it using SIGHASH_ANYONE_CAN_PAY. The output pays to OP_TRUE. This
means that anyone can spend it. The miner who includes the transaction
will send it to an address he controls (or pay to fee). The transaction
has a locktime of 1 million, so that it cannot be included before that
point.
This transaction cannot be included in a block, since the inputs are lower
than the outputs. The SIGHASH_ANYONE_CAN_PAY field mean that others can
pledge additional funds. They add more input to add more money and the
same sighash.
There would need to be some kind of notice boeard system for these pledges,
but if enough pledge, then a valid transaction can be created. It is in
miner's interests to maintain such a notice board.
The problem is that it counts as a pure donation. Even if only 10BTC has
been pledged, a miner can just add 40BTC of his own money and finish the
transaction. He nets the 10BTC of the pledges if he wins the block. If he
loses, nobody sees his 40BTC transaction. The only risk is if his block is
orphaned and somehow the miner who mines the winning block gets his 40BTC
transaction into his block.
The assurance contract was supposed to mean "If the effective minting fee
for block 1 million is 50 BTC, then I will pay 0.1BTC". By adding his
40BTC to the transaction the miner converts it to a pure donation.
The key point is that *other* miners don't get 50BTC reward if they find
the block, so it doesn't push up the total hashing power being committed to
the blockchain, that a 50BTC minting fee would achieve. This is the whole
point of the assurance contract.
OP_CHECKLOCKTIMEVERIFY could be used to solve the problem.
Instead of paying to OP_TRUE, the transaction should pay 50 BTC to "<1
million> OP_CHECKLOCKTIMEVERIFY OP_TRUE" and 0.01BTC to "OP_TRUE".
This means that the transaction could be included into a block well in
advance of the 1 million block point. Once block 1 million arrives, any
miner would be able to spend the 50 BTC. The 0.01BTC is the fee for the
block the transaction is included in.
If the contract hasn't been included in a block well in advance, pledgers
would be recommended to spend their pledged input,
It can be used to pledge to many blocks at once. The transaction could pay
out to lots of 50BTC outputs but with the locktime increasing by for each
output.
For high value transactions, it isn't just the POW of the next block that
matters but all the blocks that are built on top of it.
A pledger might want to say "I will pay 1BTC if the next 100 blocks all
have at least an effective minting fee of 50BTC"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/fad4c3c9/attachment.html>

2023-06-07 15:33:42

- 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 15:33:42

- reply

📅 Original date posted:2015-05-16
📝 Original message:On Sat, May 9, 2015 at 4:08 AM, Peter Todd <pete at petertodd.org> wrote:
> > I wonder if having a "miner" flag would be good for the network.
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
To mitigate against this, two chaintips could be tracked. The miner tip
and the client tip.
Miners would build on the miner tip. When performing client services, like
wallets, they would use the client tip.
The client would act exactly the same as any node, the only change would be
that it gives miner work based on the mining tip.
If the two tips end up significantly forking, there would be a warning to
the miner and perhaps eventually refuse to give out new work.
That would happen when there was a miner level hard-fork.
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>
To launch that attack, you need to produce fake blocks. That is
expensive.
Stephen Cale's suggestion to wait more than one block before counting a
transaction as confirmed would also help mitigate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/ef7854ef/attachment.html>

2023-06-07 15:33:41

- 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 15:33:36

- reply

📅 Original date posted:2015-05-07
📝 Original message:In terms of miners, a strong supermajority is arguably sufficient, even 75%
would be enough.
The near total consensus required is merchants and users. If (almost) all
merchants and users updated and only 75% of the miners updated, then that
would give a successful hard-fork.
On the other hand, if 99.99% of the miners updated and only 75% of
merchants and 75% of users updated, then that would be a serioud split of
the network.
The advantage of strong miner support is that it effectively kills the fork
that follows the old rules. The 25% of merchants and users sees a
blockchain stall.
Miners are likely to switch to the fork that is worth the most. A mining
pool could even give 2 different sub-domains. A hasher can pick which
rule-set to follow. Most likely, they would converge on the fork which
paid the most, but the old ruleset would likely still have some hashing
power and would eventually re-target.
On Thu, May 7, 2015 at 9:00 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> I'd love to have more discussion of exactly how a hard fork should be
> implemented. I think it might actually be of some value to have rough
> consensus on that before we get too bogged down with exactly what the
> proposed hard fork should do. After all, how can we debate whether a
> particular hard fork proposal has consensus if we haven't even decided
> what level of supermajority is needed to establish consensus?
>
> For instance, back in 2012 Gavin was proposing, effectively, that a
> hard fork should require a supermajority of 99% of miners in order to
> succeed:
>
> https://gist.github.com/gavinandresen/2355445
>
> More recently, Gavin has proposed that a supermoajority of only 80% of
> miners should be needed in order to trigger the hard fork.
>
>
> http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html
>
> Just now, on this list (see attached message) Gavin seems to be
> aluding to some mechanism for a hard fork which involves consensus of
> full nodes, and then a soft fork preceeding the hard fork, which I'd
> love to see a full explanation of.
>
> FWIW, I think 80% is far too low to establish consensus for a hard
> fork. I think the supermajority of miners should be sufficiently
> large that the rump doesn't constitute a viable coin. If you don't
> have that very strong level of consensus then you risk forking Bitcoin
> into two competing coins (and I believe we already have one exchange
> promissing to trade both forks as long as the blockchains are alive).
>
> As a starting point, I think 35/36th of miners (approximately 97.2%)
> is the minimum I would be comfortable with. It means that the rump
> coin will initially have an average confirmation time of 6 hours
> (until difficulty, very slowly, adjusts) which is probably far enough
> from viable that the majority of holdouts will quickly desert it too.
>
> Thoughs?
>
> roy
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/a5867f38/attachment.html>

2023-06-07 15:33:02

- 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 15:33:01

- 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 15:20:06

- reply

📅 Original date posted:2014-04-26
📝 Original message:Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses could be anything.
On Sat, Apr 26, 2014 at 11:36 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
> I totally agree with gmaxwell here. The cost of interoperability is too
> high. It would force us to freeze all features, and to require a broad
> consensus everytime we want to add something new.
>
> In addition, some partial level of compatibility would probably lead to
> users not able to recover all their funds when they enter their seed in
> another wallet. That is not acceptable, and should be avoided.
>
>
>
>
> Le 25/04/2014 17:46, Gregory Maxwell a écrit :
> >
> > I don't believe that wallet interoperability at this level is possible
> > in general except as an explicit compatibility feature. I also don't
> > believe that it is a huge loss that it is so.
> >
> > The structure of the derivation defines and constrains functionality.
> > You cannot be structure compatible unless you have the same features
> > and behavior with respect to key management. To that extent that
> > wallets have the same features, I agree its better if they are
> > compatible— but unless they are dead software they likely won't keep
> > the same features for long.
> >
> > Even if their key management were compatible there are many other
> > things that go into making a wallet portable between systems; the
> > handling of private keys is just one part: a complete wallet will
> > have other (again, functionality specific) metadata.
> >
> > I agree that it would be it would be possible to support a
> > compatibility mode where a wallet has just a subset of features which
> > works when loaded into different systems, but I'm somewhat doubtful
> > that it would be widely used. The decision to use that mode comes at
> > the wrong time— when you start, not when you need the features you
> > chose to disable or when you want to switch programs. But the obvious
> > thing to do there is to just specify that a linear chain with no
> > further branching is that mode: then that will be the same mode you
> > use when someone gives you a master public key and asks you to use it
> > for reoccurring changes— so at least the software will get used.
> >
> > Compatibility for something like a recovery tool is another matter,
> > and BIP32 probably defines enough there that with a bit of extra data
> > about how the real wallet worked that recovery can be successful.
> >
> > Calling it "vendor lock in" sounds overblown to me. If someone wants
> > to change wallets they can transfer the funds— manual handling of
> > private keys is seldom advisable, and as is they're going to lose
> > their metadata in any case. No one expects to switch banks and to
> > keep their account records at the new bank. And while less than
> > perfect, the price of heavily constraining functionality in order to
> > get another result is just too high.
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
> ------------------------------------------------------------------------------
> 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/20140426/2f2a8298/attachment.html>

2023-06-07 15:19:11

- reply

📅 Original date posted:2014-04-21
📝 Original message:On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd <pete at petertodd.org> wrote:
> Of course, in reality smaller miners can just mine on top of block headers
> and include no transactions and do no validation, but that is extremely
> harmful to the security of Bitcoin.
>
I don't think it reduces security much. It is extremely unlikely that
someone would publish an invalid block, since they would waste their POW.
Presuming that new headers are correct is reasonable, as long as you check
the full block within a few minutes of receiving the header.
If anything, it increases security, since less hashing power is wasted
while the full block is broadcast.
Block propagation could take the form
- broadcast new header
- all miners switch to mining empty blocks
- broadcast new block
- miners update to a block with transactions
If the block doesn't arrive within a timeout, then the miner could switch
back to the old block.
This would mean that a few percent of empty blocks end up in the
blockchain, but that doesn't do any harm.
It is only harmful, if it is used as a DOS attack on the network.
The empty blocks will only occur when 2 blocks are found in quick
succession, so it doesn't have much affect on average time until 1
confirm. Empty blocks are just as good for providing 1 of the 6 confirms
needed too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/b5fe8aad/attachment.html>

2023-06-07 15:17:53

- 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 15:17:42

- 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 15:17:40

- 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>

2023-06-07 15:11:05

- reply

📅 Original date posted:2013-12-24
📝 Original message:On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman <jeremy at taplink.co> wrote:
> Are there any past instances of applications hijacking or interfacing with
> the exiting p2p messages, or abusing 'getaddr' functionality? Are there
> any guidelines on this, or should there be?
>
>
There was a BIP by Stefan Thomas for adding custom services to the
protocol. Discovery would be helpful here too. If this was added, it
wouldn't be intended for use in a hostile way though.
This one was the custom services BIP. It defines a change to the version
message and also custom sub-commands.
https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki
This one discusses how network discovery should be handles.
https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131224/b35e78a0/attachment.html>

2023-06-07 15:05:04

- reply

📅 Original date posted:2013-07-24
📝 Original message:On Wed, Jul 24, 2013 at 10:42 AM, Peter Todd <pete at petertodd.org> wrote:
> Please provide equations and data justifying the 'magic constants' in
> this proposal.
>
The are a range of workable values. Ideally, there would first need to be
agreement on the general principle.
Distributing headers with 1/64 of the standard POW means that a header
would be broadcast approximately once every 9 seconds (assuming a 10 minute
block time). This was picked because sending 80 byte headers every 9
seconds shouldn't represent much load on the network.
The second magic number is how much credit to give for mini-headers.
Setting it at 1/16 means that the headers will be worth around 4 times as
much as a block (since there would be around 63 low POW headers for each
full POW one).
This creates an incentive for miners to take headers into account. If all
the headers were worth less than a full block, then a fork which was losing
would suddenly be winning if a block is found. A fork will only become the
main chain due to a new block, if it is within 16 mini-confirms.
Miners don't have to mine against the absolute best fork, but they do need
to make sure they stay within 16 of the best one (so if they find a block,
that block would be considered part of the main chain). Some hysteresis
might be helpful. The rule could be to only switch unless the current fork
is losing by at least 4 mini-confirms.
In most cases, this won't be a problem, since orphans don't happen that
often anyway.
Since it isn't a chain, this doesn't give the full benefits of a 9 second
block, but it should bring things to consensus faster. 6 full confirms
would be much more secure against random and hostile reversals.
It doesn't have the risks of 9 second blocks in causing network collapse,
since it isn't a chain, the headers are short, and there is no
confirmations of the required (other than checking the hash).
Each "mini" confirms adds to the strength of leaf blocks of the tree. If
there is a tie, and 20% of the network is mining one block and 80% is
mining the other, the mining power of the network will be split until the
next block arrives.
With mini confirms, the entire network is aware of the 2 blocks (since the
headers would be forwarded) and the mini-confirms would show which one has
majority hashing power.
The least risk option would be to make them purely advisory. The proposal
takes it further than that.
The proposal means that if the network is split 80/20, then miners should
stick with the 80% fork, even if the 20% fork wins the race for the next
block.
Winning a few rounds is easier than wining many rounds worth of
mini-confirms.
The key is that as long as the honest miners stay on the main chain, they
will eventually overwhelm any rewrite attack with less than 50% of the
mining power. This is a system to agree on what is the main chain in the
face of a re-write attack.
>
> Currently we do not relay blocks to peers if they conflict with blocks
> in the best known chain. What changes exactly are you proposing to that
> behavior?
>
The (sub) proposal is that headers would still be broadcast. The blocks
would not be forwarded.
If a header extends the header tree, meets full POW and is "near" the end
of the chain, then it is broadcast. This means that all nodes will have
the entire header tree, including orphans.
The full blocks would only be sent if they extend the main chain.
Second, if a header builds on a header that is in the header tree, then it
is broadcast, even if it doesn't meet full POW (only 1/64 required). This
gives information on which fork is getting the most power.
It gives information about potential "consensus loss" forks, where a
significant number of miners are following an alternative chain.
In fact, this is probably worth doing as an initial step.
A warning could be displayed on the client if a fork is getting more than
15% of the hashing power.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130724/bbae3ccf/attachment.html>

2023-06-07 15:05:03

- reply

📅 Original date posted:2013-07-23
📝 Original message:I was thinking about a change to the rules for distinguishing between forks
and maybe a BIP..
*Summary*
- Low POW headers should be broadcast by the network
If a header has more than 1/64 of the POW of a block, it should be
broadcast. This provides information on which fork is getting most of the
hashing power.
- Miners should use the header information to decide on longest chain
The fork selection rule for miners should be biased towards staying on the
fork that has the most hashing power.
This means that they might keep hashing on a fork that is 1-2 blocks
shorter.
If most miners follow the rule, then it is the best strategy for other
miners to also follow this rule.
- Advantages
This lowers the probability of natural and malicious reversals.
*Distributing low POW headers*
First block header messages that have more than 1/64 of the standard POW
requirements would be forwarded.
This means the client needs to maintain a short term view of the entire
header tree.
if (header extends header tree) {
if (header meets full POW) {
add to header tree;
forward to peers;
check if any blocks in storage now extend the header tree
} else {
if (header meets POW / 64) {
forward to peers;
}
} else {
if (header meets POW) {
add to orphan header storage
}
}
The storage could be limited and headers could be discarded after a while.
This has the extra advantage that it informs clients of forks that are
receiving hashing power.
This could be linked to a protocol version to prevent disconnects due to
invalid header messages.
*Determining the longest chain*
Each link would get extra credit for headers received.
Assume there are 2 forks starting at block A as the fork point.
A(63) <- B(72) <- C(37) <- D(58)
and
A(63) <- B'(6) <- C'(9) <- D'(4) <- E(7) <- F(6)
The numbers in brackets are the number of low POW headers received that
have those blocks as parent.
The new rule is that the POW for a block is equal to
POW * (1 + (headers / 16))
Only headers within <some threshold> of the end of the (shorter) chain
count. However, in most cases, that doesn't matter since the fork point
will act as the start point. As long as miners keep headers for 30-40
blocks, they will likely have all headers back to any reasonable fork point.
This means that the top fork is considered longer, since it has much more
headers, even though it has 2 less blocks.
If 75% of the miners follow this rule, then the top fork will eventually
catch up and win, so it is in the interests of the other 25% to follow the
rule too.
Even if there isn't complete agreement on headers received, the fork that
is getting the most hashing will naturally gain most of the headers, so
ties will be broken quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/8f153275/attachment.html>