s7r [ARCHIVE]

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

Public Key

npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h

Profile Code

nprofile1qqsfg724xqdgspg9fjxk5ty6c24lq7n6rr62xwc22uazw7rgxq548vgc490pp

Author Public Key

npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h

Show more details

Last Notes

2023-06-09 12:56:22

- reply

📅 Original date posted:2019-10-02
📝 Original message:
Anthony Towns via bitcoin-dev wrote:
[SNIP]
>
> My thinking at the moment (subject to change!) is:
>
> * anyprevout signatures make the address you're signing for less safe,
> which may cause you to lose funds when additional coins are sent to
> the same address; this can be avoided if handled with care (or if you
> don't care about losing funds in the event of address reuse)
>
It's not necessarily like this. Address re-use is many times OUTSIDE the
control of the address owner. Say I give my address to a counterparty.
They send me a transaction which I successfully spend. So far so good.
After that, I have no control over that counterparty. If they decide to
re-use that address, it does not mean I wanted to re-use it and it also
does not mean that I don't care about those funds being lost.
This could create a lot of problems in the industry and I think it
should be avoided. Address re-use has been strongly discouraged ever
since I can remember, and all (proper) wallet implementations try as
hard as possible to enforce it, but it's not always possible. A
counterparty that decides to re-use an address, either accidentally or
not, is not under the control of the user who handed out the address in
the first place.
There are also a lot of use cases with P2SH addresses that are some
smart contracts particularly designed to be re-used multiple times over
time.
My 2 cents are that this is not a good way to go. If you try to index
the entire blockchain until now you'll see that address re-use is more
common than we'd want it to be and there's no clear way to prevent this
from further happening without hurting the economic interests of the users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191002/282e8910/attachment-0001.sig>

2023-06-07 22:57:46

- reply

📅 Original date posted:2021-08-08
📝 Original message:raymo via bitcoin-dev wrote:
TL,DR: you were explained by ZmnSCPxj why this protocol will not work.
The possibility for just one party to sign will not work. I will explain
again why but in much more simpler description.
> Check out this simple transaction to learn more about how the system
> works.
> Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So,
> she can spend it by create a transaction and sign it and broadcast it to
> Bitcoin network.
> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000
> Satoshi from Alice in exchange.
> Alice gets this 5$ and prepare a Main transaction that represents this
> liability of Alice to Bob.
>
> Main Transaction (20,000 Sat input):
> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob
> has to pay 3,000 as BTC fee)
> * Alice (issuer): 6,000 Sat
> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
> This is a valid transaction and both Bob and/or Alice can send it to
> Bitcoin network, but none of them are interested in doing so. Because
> they will lose 5,000 Satoshi of their own money as Bitcoin transaction
> fee.
>
> Alongside this transaction Alice (the issuer) has to create the
> Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will
> not consider the deal completed. The Guarantee Transaction is another
> valid Bitcoin transaction. It is created based on Main Transaction and
> will cut a part of Bob and Alice money in favor of transaction fee.
>
> Guarantee Transaction (20,000 Sat input):
> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat
> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat
> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from
> Bob) + 3,480 (from Al-ice) = 15,739 Sat
>
> The Guarantee Transaction applies when the issuer does not live up to
> its promise and intends to spend the promised UTXO(s) in a way other
> than that agreed upon. We already knew the fact that Sabu is not a
> custodial solution, neither a M of N signature schema. As a result, the
> UTXO owner always can spend the already promised UTXO(s) in Sabu
> protocol or out of Sabu on Bitcoin blockchain, Contrary to what was
> promised.
> When the Alice (issuer) breaks such a promise and sends the fraudulent
> transaction to the Bitcoin network, Bob's wallet realizes that she
> (issuer) is spending the promised UTXO(s) and it sends the Guarantee
> Transaction(s) to the network as a last resort. The miners will face two
> (or more) transactions which are spending same UTXO(s), but one of them
> is paying notably higher Bitcoin transaction fee, thus they chose the
> highest fee payer transaction, which is the Guarantee Transaction. The
> miner will put the Guarantee Transaction in next block and reject the
> rest double-spend transactions. Certainly, poor Bob cannot recoup all
> his Satoshis. But he can retrieve a portion of his money and forces
> Alice to lose some of her money as well. tit for tat!
> Because of this mechanism, the issuer will try to not cheat on creditor.
>
> By the way there are some attacks that have very small chance to succeed
> but the risk to reward ratio for these scenarios are too high to be
> considered as a real possible attack threat. I will review them a little
> later in this post.
>
>
You said that the guarantee transaction is created based on Main
Transaction, how do you mean? If it is a child transaction of the Main
Transaction it already doesn't work because Alice needs to broadcast the
*Main Transaction* to the blockchain in order for the Guarantee
transaction to be accepted, and of she does this, Bob doesn't care
because the transaction pays to him already the correct agreed amount.
If you did not mean this, still it won't work, because
Simple:
1. Alice will create transaction #3, or call it Sabu-killing-transaction
(20,000 Sat input):
* Alice (issuer): 15,000 Sat
* BTC Fee: 5,000 Sat
PERIOD.
When Bob tries to broadcast the "guarantee transaction" he will get an
error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The much
larger fee in the guarantee transaction will not matter. You have to
assume a miner will violate the Bitcoin protocol and somehow drop
Sabu-killing-transaction from mempool and consider the Guarantee
transaction only. This is very unlikely to happen and you might also
need connection direct with the miners because most full nodes will not
even accept the Guarantee transaction to their mempools in order to
further broadcast it until it reaches the miners.
With the simple attack described above Alice's chance to fraud Bob are,
from my point of view, 99%.
(the only way to replace a transaction is Replace-By-Fee but this
implies the transaction that IS TO BE REPLACED has a certain flag set,
and it is optional).
Given the Sabu-Killing-transaction comes first, Alice will of course
create it without this flag set so even if you add to Sabu the
requirement of RBF enabled to the Guarantee transaction it will not
work, because it's the other way around.
The second question is just for an observation that it has no real
benefits over Lightning even if #1 wasn't true:
2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he
is connected to the internet, otherwise if he loses connection to the
internet or energy supply, Alice attack will succeed entirely with 100%
chances. So this means Bob needs to always be online like forever and ever.
The 3rd one is hypothetical and you don't even have to answer it:
3. How does Bob (first creditor) spend the coins received / how does Bob
become an issuer himself in relation to Dave (another creditor)? What
happens if Alice tries to fraud Bob after Bob spent its Sabu credit to
Dave? Dave has to hold all parent "guarantee transactions" and watch the
network for any potential fraudulent transactions that cancels his credit?

2023-06-07 22:57:38

- reply

📅 Original date posted:2021-08-04
📝 Original message:ic via bitcoin-dev wrote:
> Hi,
>
>> On 4 Aug 2021, at 12:30, Justin Valceanu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I have created a new Romanian wordlist for Bip-0039;
>> Requesting permission to push to github the attached modified files.
>
> Although I don’t think it ’s hard requirement, it would be great if the words could be uniquely identified using the first 4 letters (most metal backup “plates” only have space for 4 letters).
>
> I see several occurrences of conflicting words in the first page alone.
>
> ++ ic
>
I am +1 on the unique identification using the first 4 letters, makes it
easy for restoring from seed on mobile wallets. Don't know if this is
really a blocker but since RO is a rich enough language in terms of
words, this shouldn't be too hard.
Also, world list is not acceptable in this form. it should be revised by
someone with knowledge in Romanian lexical area, I just briefly reviewed
and:
- _adesiv_ shouldn't be *adeziv* ?
- _walkman_ - this is not a Romanian word, while it is of course
sometimes used in Romania.
- _web_ - this is not a Romanian word, while it is of course sometimes
used in Romania.
- _yachting_ - this is not a Romanian word and it most certainly not
used in Romania :)) Why not use *navigatie* or something?
- _topmodel_ - it's two words merged in one
- _acvatic_ and _acvaplanare_ - they are both independent words but very
close to each other while one is an adjective and one substantive. These
two for example break the "no confusing words" spec.
I didn't review the entire word list and no sense to make this message
too long, but I'm sure you see the point. Word list needs changes,
please correct.

2023-06-07 18:21:44

- reply

📅 Original date posted:2019-11-17
📝 Original message:Mr. Lee Chiffre via bitcoin-dev wrote:
> Right now bitcoin client core supports use of tor hidden service. It
> supports v2 hidden service. I am in progress of creating a new bitcoin
> node which will use v3 hidden service instead of v2. I am looking at
> bitcoin core and btcd to use. Do any of these or current node software
> support the v3 onion addresses for the node address? What about I2P
> addresses? If not what will it take to get it to support the longer
> addresses that is used by i2p and tor v3?
>
>
Hello,
Yes, that is correct. Currently at present moment only v2 onion services
are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p
protocol, so it requires a rework of the p2p protocol. v3 onion services
are whole ed25519 public keys, base32 encoded with .onion at the end.
Same reason applies to I2P 'address types' as well. However, I am not an
expert in I2P and don't actually know how many bitcoin full nodes might
exist in I2P.
See:
https://github.com/bitcoin/bitcoin/issues/9214
https://github.com/bitcoin/bitcoin/issues/2091
For the default `ADD_ONION` feature, the onion service key was
downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure
the feature still works out of the box:
https://github.com/bitcoin/bitcoin/pull/9234
If you want a Tor only full node, you are best to use v2 onion services
for now. Why do you need the bitcoin node to explicitly have a v3 onion
address? You can have a service that is accessible to the general public
as a v3 onion service, and in the back uses a bitcoin full node that
uses v2 onion service to talk to other nodes. The v2 onion service
bitcoin network is extended fairly.
You can use in the same torrc (Tor configuration file), implicitly same
Tor process/daemon simultaneously v2 and v3 onion services by setting
HiddenServiceVersion parameter after every HiddenServiceDir parameter.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191117/5a13ed1e/attachment.sig>

2023-06-07 18:20:48

- reply

📅 Original date posted:2019-10-02
📝 Original message:Anthony Towns via bitcoin-dev wrote:
[SNIP]
>
> My thinking at the moment (subject to change!) is:
>
> * anyprevout signatures make the address you're signing for less safe,
> which may cause you to lose funds when additional coins are sent to
> the same address; this can be avoided if handled with care (or if you
> don't care about losing funds in the event of address reuse)
>
It's not necessarily like this. Address re-use is many times OUTSIDE the
control of the address owner. Say I give my address to a counterparty.
They send me a transaction which I successfully spend. So far so good.
After that, I have no control over that counterparty. If they decide to
re-use that address, it does not mean I wanted to re-use it and it also
does not mean that I don't care about those funds being lost.
This could create a lot of problems in the industry and I think it
should be avoided. Address re-use has been strongly discouraged ever
since I can remember, and all (proper) wallet implementations try as
hard as possible to enforce it, but it's not always possible. A
counterparty that decides to re-use an address, either accidentally or
not, is not under the control of the user who handed out the address in
the first place.
There are also a lot of use cases with P2SH addresses that are some
smart contracts particularly designed to be re-used multiple times over
time.
My 2 cents are that this is not a good way to go. If you try to index
the entire blockchain until now you'll see that address re-use is more
common than we'd want it to be and there's no clear way to prevent this
from further happening without hurting the economic interests of the users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191002/282e8910/attachment.sig>

2023-06-07 17:54:51

- reply

📅 Original date posted:2016-12-11
📝 Original message:Andrew Johnson wrote:
> "You miss something obvious that makes this attack actually free of cost.
> Nothing will "cost them more in transaction fees". A miner can create
> thousands of transactions paying to himself, and not broadcast them to
> the network, but hold them and include them in the blocks he mines. The
> fees are collected by him because transactions are included in a block
> that he mined and the left amount is in another wallet of the same
> person. Repeat this continuously to fill blocks."
>
> This is easily detectable as long as the network isn't heavily
> partitioned(which is an assumption we make today in order for
> transaction propagation to work reliably as well as for xThin and
> CompactBlocks to work effectively to reduce block transmission time).
> Other miners would have an incentive to intentionally orphan blocks that
> contained a large number of transactions that their nodes were unaware of.
>
> I don't think this sort of attack would last long. Even later when
> subsidies are drastically reduced, you would still lose out on
> significant genuine fee revenue if your orphan rate increased even
> 10%(one out of ten of your poison blocks intentionally orphaned by
> another miner).
>
I disagree.
I didn't say this is impossible to detect, but it is hard to act against
it. One miner orphaning the block intentionally is very unlikely if that
miner acts rationally. It would only make sense if 51% of the hash rate
would intentionally orphan it. Otherwise the miner who intentionally
orphans a valid block, let's say block X, has to continue to mine one in
its place on top of block X-1, and by the time he finds one:
a) his block X' is rejected by other miners because they already have a
valid block X on top of which they already started to mine;
b) block X+1 was already found and broadcasted, so the miner who
orphaned X intentionally is on the shorter chain ignored by the network.
So, one miner cannot do anything about it. Even a pool cannot do
anything about it, because the loss is greater. You need 51% of the hash
rate to intentionally orphan it, and all the miners forming 51% need to
be colluding and know for sure that every one will intentionally orphan
the said block, otherwise there's a huge risk of loss for who does it.
Nobody would gamble to do this (I am not sure if gambling is the right
word, since the loss is 100% sure here). But, we are not discussing 51%
attacks because those are a different topic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161212/952907bb/attachment.sig>

2023-06-07 17:54:48

- reply

📅 Original date posted:2016-12-11
📝 Original message:t. khan wrote:
> Miners 'gaming' the Block75 system -
> There is no financial incentive for miners to attempt to game the
> Block75 system. Even if it were attempted and assuming the goal was to
> create bigger blocks, the maximum possible increase would be 25% over
> the previous block size. And, that size would only last for two weeks
> before readjusting down. It would cost them more in transaction fees to
> stuff the network than they could ever make up. To game the system,
> they'd have to game it forever with no possibility of profit.
>
This is an incentive, if few miners agree to create a large conglomerate
that will ultimately control the network.
You miss something obvious that makes this attack actually free of cost.
Nothing will "cost them more in transaction fees". A miner can create
thousands of transactions paying to himself, and not broadcast them to
the network, but hold them and include them in the blocks he mines. The
fees are collected by him because transactions are included in a block
that he mined and the left amount is in another wallet of the same
person. Repeat this continuously to fill blocks.
> Blocks would get too big -
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, the
> incremental adjustments made by Block75 (especially in combination with
> SegWit) wouldn't break anyone's connection or result in significantly
> more orphaned blocks.
>
Topology and bandwidth speed / hash rate of the network cannot be
controlled - if we make assumptions about these it might have terrible
consequences.
Even if we take in consideration that bandwidth will only grow and disk
space will only cost less (which is not something we can safely assume,
by the way) the hard limit max. block size cannot grow to unlimited
value (even if the growth happens over time). There is also a validation
cost in time for each block, for the health of the network any node
should be able to download _and_ validate a block, before next block
gets mined.
You said in another post that a permanent solution is preferred, rather
than kicking the can down the road. I fully agree, as well as many
others reading this list, but the permanent solution doesn't necessarily
have to be increasing the max block size dynamically.
If you think about it the other way around, dynamically growing the max
block size is also kicking the can down the road ... just without having
to touch it and get dust on the boot ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/6af3a1eb/attachment-0001.sig>

2023-06-07 17:54:46

- reply

📅 Original date posted:2016-12-10
📝 Original message:t. khan via bitcoin-dev wrote:
> BIP Proposal - Managing Bitcoin’s block size the same way we do
> difficulty (aka Block75)
>
> The every two-week adjustment of difficulty has proven to be a
> reasonably effective and predictable way of managing how quickly blocks
> are mined. Bitcoin needs a reasonably effective and predictable way of
> managing the maximum block size.
>
> It’s clear at this point that human beings should not be involved in the
> determination of max block size, just as they’re not involved in
> deciding the difficulty.
>
> Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
> passing the decision to miners/pool operators, the max block size should
> be adjusted every two weeks (2016 blocks) using a system similar to how
> difficulty is calculated.
>
> Put another way: let’s stop thinking about what the max block size
> should be and start thinking about how full we want the average block to
> be regardless of size. Over the last year, we’ve had averages of 75% or
> higher, so aiming for 75% full seems reasonable, hence naming this
> concept ‘Block75’.
>
> The target capacity over 2016 blocks would be 75%. If the last 2016
> blocks are more than 75% full, add the difference to the max block size.
> Like this:
>
> MAX_BLOCK_BASE_SIZE = 1000000
> TARGET_CAPACITY = 750000
> AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> TARGET_CAPACITY
>
> To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
>
> For example, if the last 2016 blocks are 85% full (average block is 850
> KB), add 10% to the max block size. The new max block size would be
> 1,100 KB until the next 2016 blocks are mined, then reset and
> recalculate. The 1,000,000 byte limit that exists currently would
> remain, but would effectively be the minimum max block size.
>
> Another two weeks goes by, the last 2016 blocks are again 85% full, but
> now that means they average 935 KB out of the 1,100 KB max block size.
> This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
> that to make the new max block size of 1,185 KB.
>
> Another two weeks passes. This time, the average block is 1,050 KB. The
> new max block size is calculated to 1,300 KB (as blocks were 105% full,
> minus the 75% capacity target, so 30% added to max block size).
>
> Repeat every 2016 blocks, forever.
>
> If Block75 had been applied at the difficulty adjustment on November
> 18th, the max block size would have been 1,080KB, as the average block
> during that period was 83% full, so 8% is added to the 1,000KB limit.
> The current size, after the December 2nd adjustment would be 1,150K.
>
> Block75 would allow the max block size to grow (or shrink) in response
> to transaction volume, and does so predictably, reasonably quickly, and
> in a method that prevents wild swings in block size or transaction fees.
> It attempts to keep blocks at 75% total capacity over each two week
> period, the same way difficulty tries to keep blocks mined every ten
> minutes. It also keeps blocks as small as possible.
>
> Thoughts?
>
> -t.k.
>
I like the idea. It is good wrt growing the max. block size
automatically without human action, but the main problem (or question)
is not how to grow this number, it is what number can the network
handle, considering both miners and users. While disk space requirements
might not be a big problem, block propagation time is. The time required
for a block to propagate in the network (or at least to all the miners)
is directly dependent of its size. If blocks take too much time to
propagate in the network, the orphan rate will increase in unpredictable
ways. For example if the internet speed in China is worse than in
Europe, and miners in China have more than 50% of the hashing power,
blocks mined by European miners might get orphaned.
The system as described can also be gamed, by filling the network with
transactions. Miners have the monetary interest to include as many
transactions as possible in a block in order to collect the fees.
Regardless how you think about it, there has to be a maximum block size
that the network will allow as a consensus rule. Increasing it
dynamically based on transaction volume will reach a point where the
number got big enough that it broke things. Bitcoin, because its
fundamental design, can scale by using offchain solutions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/c231038d/attachment.sig>

2023-06-07 17:52:12

- reply

📅 Original date posted:2016-08-06
📝 Original message:Hi,
I can clearly see some advantages for such a feature, but it's kind of
in conflict with Bitcoin's fundamental design. This design might be
problematic when it comes to hacks/thefts, but it's what gives Bitcoin
strength and make it differentiate from other currencies:
* reversal of transactions is impossible
* keep private keys private and safe. Lose them, it's like losing cash,
you can just forget about it.
* while we try hard to make 0-conf as safe as possible (if there's no
RBF flag on the transaction), we make it almost impossible or very very
expensive to reverse a confirmed transaction.
Also, we don't have a clear way to properly decide a good settlement
period length. It doesn't fix the problem any more than nLockTime fixes
it -- you can't know ahead of time when a withdraw needs to be made.
Fair enough, but even if the withdraw is made with a settlement layer,
will the user be able to spend it further immediately? Who will accept
such an input and treat it as a payment if it can be reversed during the
settlement layer? So, if you can't know ahead of time when a withdraw
needs to be made (nLockTime) how can you know ahead of time+settlement
period when a transaction needs to be declared irrevocable?
The linked page describes that merchants will never accept payments from
'vaults', and it will take 24 hours for coins to be irreversible moved
outside the 'vault'. This covers the part "is the user able to spend a
transaction with settlement layer" but it has security properties equal
to nLockTime = 24 hours - you can't benefit and use the coins
immediately and in 24 hours price might go up or down in an undesirable
way for a certain user. It however raises a lot of other questions: what
if the attacker manages to steal both the private key and vault key (we
have strong reasons to assume this can happen: if you can't keep a
private key safe, why would you be able to keep the vault key any
safer?) and starts a race with the actual user to unlock and lock back
the vault?
I think this is a wrong approach. hacks and big losses are sad, but all
the time users / exchanges are to blame for wrong implementations or
terrible security practices.
Thanks!
On 8/3/2016 9:16 PM, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?
>
> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a
> transaction's progress was publicly visible so transparent fraud
> prevention and auditing would become possible by anyone.
>
> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism; Nlocktimed TXs won't work
> for this since you can't know ahead of time when and where a withdrawal
> needs to be made, plus there's still the potential for key
> mismanagement; Similar problems with OP_CHECKLOCKTIMEVERIFY apply too –
> unless you keep a private key around on the server which would defeat
> the purpose. The main use case here, would be specifically to improve
> centralized exchange security by making it impossible for a hot wallet
> to be raided all at once.
>
> Thoughts?
>
> Some existing background:
>
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
>
> roberts.pm/timechain <http://roberts.pm/timechain> -- My original paper
> written in 2015 which proposed a similar idea for secure wallet design
> but implemented using time-locked ECDSA keys. Obviously a blockchain
> would work better for this.
>
> Other -- if the idea has already been brought up by other people, I
> apologize.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160806/e7d9caab/attachment.sig>

2023-06-07 17:51:24

- reply

📅 Original date posted:2016-06-23
📝 Original message:On 6/23/2016 1:56 PM, Peter Todd via bitcoin-dev wrote:
>>
>> I don’t know if you are opposed to organizations that have AML requirements
>> from using the bitcoin blockchain, but if you aren’t, why wouldn’t you
>> prefer an open source, open standards based solution to exclusionary,
>> proprietary ones?
>
> In some (most?) countries, it is illegal to offer telecoms services without
> wiretap facilities. Does that mean Tor builds into its software "open source"
> "open standards" wiretapping functionality? No. And interestingly, people
> trying to add support for that stuff is actually a thing that keeps happening
> in the Tor community...
>
> In any case, I'd strongly argue that we remove BIP75 from the bips repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin developers
> to willingly participate in AML/KYC, just the same way as it's bad for Tor to
> add wiretapping functionality, and W3C to support DRM tech. The minor tactical
> wins you'll get our of this aren't worth it.
>
Exactly!
Totally agree with Peter Todd. There's absolutely no gain for Bitcoin to
willingly participate in AML/KYC. Plus this might come with strings
attached: for example when running a Tor relay in some countries if you
interfere with the traffic (censor, limit, filter, etc.) you become
responsible for it, while when you only relay anonymous traffic without
interfering or having the possibility to do so (installing certain
tools, using a modified Tor which allows you to do so, etc.) you cannot
be held responsible for the traffic.
Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
expectations from _all_ users from authorities. Companies or individuals
who want and/or need AML/KYC can find ways and do it at their side
isolated from the entire network, and the solutions shouldn't come from
upstream. AML/KYC/<insert other regulation here> differ from country to
country and will be hard to implement in a global consensus network even
if it would be worth it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/3541af5b/attachment.sig>

2023-06-07 17:46:17

- reply

📅 Original date posted:2015-12-20
📝 Original message:What will be the actual effect over wallets?
Say I have the private key for a dormant UTXO older than the
consensus-critical maximum UTXO age. The UTXO is not part of the cache.
So I setup a full node and import my old private key (wallet.dat). Will
I even see the correct balance (where will it get if from, since it's
dropped from the cache), or it will show me a 0 balance?
If I can see the correct balance, where can I get the proof I need and
what ensures I'll always be able to get that proof?
On 12/20/2015 1:34 PM, Jeff Garzik via bitcoin-dev wrote:
> On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.
>
>
> Yes, this is almost what -has- to happen in the long term.
>
> Ideally we should start having wallets generate those proofs now, and
> then introduce the max-age as a second step as a planned hard fork a
> couple years down the line.
>
> However,
> 1) There is also the open question of "grandfathered" UTXOs - for those
> wallets generated in 2009, buried in a landfill and then dug out 10
> years ago
>
> 2) This reverses the useful minimization attribute of HD wallets - "just
> backup the seed"
>
>

2023-06-07 17:44:08

- reply

📅 Original date posted:2015-11-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Right. Wallets are covering malleability in acceptable ways. Normal
user to user payments aren't (or at least shouldn't be) affected by
malleability.
Problems appear in second level and third level malleability, when
Alice sends txB to Bob which spends from txA which is unconfirmed. If
txA changes txid, txB becomes useless and invalidates Alice's payment.
Looking at scriptPubKeys instead of transaction IDs doesn't help in
this context.
This is the reason why some type of contracts are not workable or not
100% safe. One can't pre-sign a refund transaction with an nLockTime
in the future: the payer will provide the funding transaction ID from
which the refund tx will spend, but if the transaction ID of the
funding transaction is affected by malleability (third party
malleability, since the signer doesn't have interest to do so) the
refund tx becomes useless.
On 11/5/2015 10:25 PM, Jorge Timón via bitcoin-dev wrote:
> On Thu, Nov 5, 2015 at 8:36 PM, Luke Dashjr <luke at dashjr.org>
> wrote:
>> Ok, then my point is that "signature malleability" is not
>> particularly problematic or interesting alone, and the only way
>> to get a practically-useful solution, is to address all kinds of
>> malleability.
>
> I disagree. Segregated witnesses, for example, doesn't solve all
> kinds of malleability and is very useful in some practical cases by
> solving all signature malleability. As said, we don't want to
> eliminate all forms of malleability (for example, replace by fee),
> although we may want to "address them" at some level. As you have
> said, wallets should be looking at scriptPubKeys, not transaction
> ID, but that is orthogonal to SW, a normalized tx ID and signature
> malleability.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWO9w7AAoJEIN/pSyBJlsR2BsH+gMwxJ/isiWfJF12LJ9s4wat
Bd/K2Ld+Lyk5BRs+6rQzv5NeeYjYC3FtNFV+z1Z1dMDd752cUfEZqQA9dt9nl0E7
BEia3RSFii1k2L/4xwiIWKZM20qoiykou41J56GZrJa9SoP+9kg8iLq8CokahakP
PLjfBrTylJBsgq34foPPaOH9ckOa/RJpx3WHrRFTPhxbTCm1Ezv6jAZmYr9tTi1h
afzU0YayzLUIb9xH8vfODY2qMJ91uguTUZYCGuopDYhom5GMw8zss0kG5FdEZrEQ
Z7srQmKQ0SRMtiSlg6lg3d8TS5Mv1gIp1HcL+gtMFroi38pJS8dXT65nGjg0Epc=
=ZhVA
-----END PGP SIGNATURE-----

2023-06-07 17:43:41

- reply

📅 Original date posted:2015-10-19
📝 Original message:So what exactly is used to create the normalized txid (sha256 hash of
what data)? I've read in the linked BIP draft that it will strip the
'malleable parts' but didn't understand what exactly will be used to
calculate the normalized transactions ids and how will the change apply
retro-active for the transactions so deep buried in the blockchain?
Pubkeys (addresses) can be reused infinitely so what guarantees us
unique normalized txids all the time and protection against replay
attacks? The question is not if this issue is covered or not, I know it
is, I am just asking how, in simpler terms.
SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document.
Will it also fix > third level malleability (a tx which spends from
another unconfirmed tx which spends from yet another unconfirmed tx)?
On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote:
> On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto: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.
>
>

2023-06-07 17:43:26

- reply

📅 Original date posted:2015-10-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 10/14/2015 6:19 PM, Paul Sztorc wrote:
> LN transactions are a substitute good for on-chain transactions.
>
> Therefore, demand for on-chain transactions will decrease as a
> result of LN, meaning that fees will be lower than they would
> otherwise be.
>
> However, the two are also perfect compliments, as LN transactions
> cannot take place at all without periodic on-chain transactions.
>
> The demand for *all* Bitcoin transactions (LN and otherwise) is
> itself a function of innumerable factors, one of which is the
> question "Which form of money [Bitcoin or not-Bitcoin] do I think
> my trading partners will be using?". By supporting a higher rate of
> (higher-quality) Bitcoin transactions, the net result is highly
> uncertain, but will probably be that LN actually increases trading
> fees.
Probably yes. But probably no. Having less hashing power is not good,
and it's unrelated to scalability and decentralization, it's related
to security. Of course we could argue that the hashing power is not
super decentralized at this moment but it's unrelated to the topic.
I'd rather have less decentralized big amount of hashing power as
opposite to less hashing power.
One theory, very close to yours, is that if Bitcoin transactions
demand grows so high that we need the lightning network, there should
be plenty of on chain transactions for miners to collect fees from.
I haven't yet seen the incentives of everyone involved in lightning
network (payment channel end points, hub operators, miners, etc.) but
would it make sense to enforce a % of the fees collected by on payment
hubs to be spent as miner fees, regardless if the transactions from
that hub go on the main chain or not?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWHtksAAoJEIN/pSyBJlsR9Y0H+QE/XdW7yauhrNJtp2eIBPg9
zVUanzR2LT0zAkeF5/Xsx3PFoypALOV7R0YNL29jI3F2XkZA8v24wfNvPi0DETcC
ZOxw4G1erIEjjj51Qz4M7okjQecJxPHOJ+Nz6iNZEDFcZG2b15phCRSQKZwSHP+b
Erw6a4NPs1foieZyk260KSOB8lFs9e8bUJfXd4FfA7l60RA9582K6p05aqVtehFW
ONTe8ULv8F0ba+EzVyTodzzY6ehjD+uc31zL6mDFIbiW+InivFbfi2uDVN1BP/US
m99lLHvDEthnkTokFrbDu81kXdD0lHwIu4O0EMzCnw2E0vWi3sGKd+M0P0sv4WA=
=1qxh
-----END PGP SIGNATURE-----

2023-06-07 17:43:25

- reply

📅 Original date posted:2015-10-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I am reading about the Lightning Network and the BIPs which need to be
deployed until it can be fully functional. I have to say it's a neat
solution to scale and have almost instant transactions in a peer 2
peer, distributed and trustless way. I already knows what the needed
BIPs are and what each one does, I am curios about the impact this
will have on miner fees.
If transactions happen in a big percent offchain, and they are only
broadcasted on the mainchain where funds are moved in or out of the
lightning network, this means there will be less transactions on the
mainchain -> less fees collected by the miners. What will happen when
the block reward will go away? Either the fees for the little amount
of onchain transactions will increase to unpractical levels, either
the miners will find it not profitable to keep their hardware plugged
in to mine, so will leave and the effect will be that the hashing
power of the network will decrease. Since the network's hashing power
is a security feature (it makes some attacks impossible or insanely
expensive) I think it's important to anticipate what will happen in
this scenario.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWHisJAAoJEIN/pSyBJlsRQfgH/05DTVd+oUNeBt6LzitY/b2a
b4Ubky0vWE5fa7sHxcfMQz4g4dPVKrDrMrpJsx2aY6D8a14tXzHsgyyRqJSZlHZh
CUYvuy+HVje5wSwYRRIFEI+yyJLRrxJYLQuTqd9u/5kpL91Qq1cgzGr9BQgz20vb
tDEP3Z0/08XeUPFA8ZxwjUptfzypVl0euIjsa2bFNFAWN9UYcDqKc0MnqgCYRTx3
F/cm1NVmtFdpE2srTXVOqC0nTdfhHjnd1zmfRpPq0ZZoG43U81PbzC0kZmdz6rkt
kUrtzKEDRLs12FNPVMrNnsHvRpScqoxIelubSvR8U3xrtIHkG9bpYO9EMqX6O4I=
=+sdq
-----END PGP SIGNATURE-----

2023-06-07 17:42:43

- reply

📅 Original date posted:2015-10-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
First, this only makes reference to hard forks not to soft forks. This
is very important because we are trying to apply a hard fork
requirement to a soft fork procedure which obviously won't work.
Your statement that 'all objections coming from anyone must be
addressed until that person agrees' is not applicable in reality. What
if that person objecting is explained several times, with plausible
and verifiable technical arguments, and that person still doesn't
agree (either on purpose, either really doesn't understand the
explanations)? What will we do in this case? Assume it's controversial
because someone refuses to or simply doesn't understand? This seams at
least a little bit unfair.
It's like we are in a court room where a text from a law (like this
requirement from that BIP) can be twisted and interpreted in various
way in an endless debate. We cannot apply everything as-it-is-stated
word-by-word and apply it _blindly_ like robots in every situation,
everything always depends on context and other factors.
For example, I don't see this controversial nor a violation of the BIP
requirements. Mike had some fair objections, they were explained by
gmaxwell and Jorge, everybody understood. The explanation is clear,
with plausible practical examples, so from my point of view the
objections have no arguments to sustain the claim. I don't see
anything controversial here. Now of course it's Mike's right to reject
those explanations, but what's the 'controversial' here?
On 10/5/2015 6:56 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not
> Mike's main intention. At least I perceive (and maybe others too)
> something else is happening.
>
> Let me try to clarify: the discussion has nothing to do with
> technical arguments. I generally like more hard forks than soft
> forks (but I won't explain why because this is not a technical
> thread), but for CLTV this is quite irrelevant (but I won't explain
> why..), and I want CLTV to be deployed asap.
>
> Mike's intention is to criticize the informal governance model of
> Bitcoin Core development and he has strategically pushed the
> discussion to a dead-end where the group either:
>
> 1) ignores him, which is against the established criteria that all
> technical objections coming from anyone must be addressed until
> that person agrees, so that a change can be uncontroversial. If the
> group moves forward with the change, then the "uncontroversial"
> criteria is violated and then credibility is lost. So a new
> governance model would be required for which the change is within
> the established rules.
>
> 2) respond to his technical objections one after the other, on
> never ending threads, bringing the project to a standstill.
>
> As I don't want 2) to happen, then 1) must happen, which is what
> Mike wants. I have nothing for or against Mike personally. I just
> think Mike Hearn has won this battle. But having a more formal
> decision making process may not be too bad for Bitcoin, maybe it
> can actually be good.
>
> Best regards from a non-developer to my dearest developer friends,
> Sergio.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWErRQAAoJEIN/pSyBJlsRxJMIAI9eoPny6B2VOH/wSkfeeVbu
bZ+0ZBLfDIwzQ2Tqn0DZQ8TWHfHPHacA7IxtTRnkSqPTMcDUgZ5/URBE4Tt8p2F2
zDda0NjqMUIJIBkLHRHzApRTK+BcshtarSbGJOr7HUaOb2hyDnQp1bzOMPGpIdTq
YA5EY39SdzzJaF7uto/bhFj6g51kdxux2epbmbaJjUHFUO1+6RAw/irI6hkyzWzi
VS8l6ZpXiaV3Y1pU+Nc60sa4GacYwKvFmvve7DTIYVsPV6KzJmbT924n5TW3191H
JBxRnUUqoWEae/h85pOQiYbJGX/EtXOmy2CZcGm0TkL3vXsAwxiDQyz8NlNyAOI=
=ClSy
-----END PGP SIGNATURE-----

2023-06-07 17:42:25

- reply

📅 Original date posted:2015-10-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi aj,
On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
> On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
> bitcoin-dev wrote:
>> So we need to make the case for two main things: 1) We have
>> applications that need a relative (instead of absolute CLTV) 2)
>> Additionally to RCLTV, we need to implement this via nSequence
>
>> However I don't think we've done a good job showing why we need
>> to implement this feature via nSequence. BIP68 describes the new
>> nSequence semantics, and gives the rational for them as being a
>> "Consensus-enforced tx replacement" mechanism, with a
>> bidirectional payment channel as an example of this in action.
>> However, the bidirectional payment channel concept itself can be
>> easily implemented with CLTV alone.
>
> Do you mean "with RCLTV alone" here?
>
> RCLTV/OP_CSV is used in lightning commitment transactions to
> enforce a delay between publishing the commitment transaction, and
> spending the output -- that delay is needed so that the
> counterparty has time to prove the commitment was revoked and claim
> the outputs as a penalty.
>
I partially understand - can you please provide a simple Alice and Bob
example here with the exact scenario? Thanks. Why is there a need to
'delay between publishing the commitment transaction and spending the
output'? If the absolute CLTV script reached its maturity it means
something went wrong (e.g. counterparty cheated or got hit by a bus)
so what is with the delay time needed for proving that the commitment
was revoked? I assume an absolute CLTV script reaching its maturity
(nLockTime) is the proof itself that the commitment was revoked - but
maybe I'm missing something obvious, sorry if this is the case.
> Using absolute CLTV instead would mean that once the effective
> delay a commitment transaction has decreases over time -- initially
> it will be longer than desirable, causing unwanted delays in
> claiming funds when no cheating is going on; but over time it will
> become too short, which means there is not enough time to prove
> cheating (and the channel has to be closed prematurely). You can
> trade those things off and pick something that works, but it's
> always going to be bad.
>
I agree, I see the logic here. Absolute CLTV is not necessary inferior
to RCLTV - there are use cases and use cases. For example, you can
avoid unnecessary waiting until the nLockTime expires if you use
absolute CLTV in combination with P2SH (2/2). Again, it always depends
on the use case - it might be a good solution, it might not be such a
good solution, but even absolute CLTV alone clearly fixes a lot of
things and takes smart contracts to the next level.
>> There is a small drawback in that the initial transaction could
>> be delayed, reducing the overall time the channel exists, but the
>> protocol already assumes that transactions can be reliably
>> confirmed within a day - significantly less than the proposed 30
>> days duration of the channel.
>
> Compared to using a CLTV with 30 days duration, With RCLTV a
> channel could be available for years (ie 20x longer), but in the
> case of problems funds could be reclaimed within hours or days (ie
> 30x faster).
>
Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
would be neat to have both, but if I can only have (for the time
being) absolute CLTV so be it - it's still a lot better.
> But that's all about RCLTV vs CLTV, not about RCLTV vs
> nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily
> BIP 68 (nSequence relative locktime), if they could be
> disentangled.
>
> You could do all that with "<n> OP_CHECK_HEIGHT_DELTA_VERIFY" that
> ignores nSequence, and directly compares the height of the current
> block versus the input tx's block (or the diff of their
> timestamps?) though, I think?
>
> I think the disadvantage is that (a) you have to look into the
> input transaction's block height when processing the script; and
> (b) you don't have an easy lookup to check whether the transaction
> can be included in the next block.
>
> You could maybe avoid (b) by using locktime though. Have "<n>
> OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions
> locktime against the input's block height or time; if the locktime
> is 0 or too low, the transaction is invalid. (So if nLockTime is in
> blockheight, you can only spend inputs with blockheight based
> OP_CRLTV tests; and if it's in blocktime, you can only spend inputs
> with blocktime based OP_CRLTV. "n" does need to encode whether it's
> time/block height though).
>
> That way, when you see a txn:
>
> - run the script. if you see <n> RCLTV, then + if the tx's locktime
> isn't set, it's invalid; drop it + if the input txn is unconfirmed,
> it's invalid; try again later + workout "locktime - n" if that's >=
> the input tx's block height/time, it's good; keep it in mempool,
> forward it, etc
>
> - if you're mining, include the tx when locktime hits, just like
> you would any other valid tx with a locktime
>
> I think the use cases for BIP68 (nSequence) are of the form:
>
> 1) published input; here's a signed tx that spends it to you,
> usable after a delay. might as well just use absolute locktime
> here, though.
>
> 2) here's an unpublished input, you can build your own transaction
> to spend it, just not immediately after it's published. BIP112 is
> required, and OP_RCLTV as defined above works fine, just include
> it in the published input's script.
>
> 3) here's an unpublished input, and a signed transaction spending
> it, that you can use to spend it after a delay. BIP68 is enough;
> but OP_RCLTV in the second transaction works here. however without
> normalised tx ids, the input could be malleated before
> publication, so maybe this use case isn't actually important
> anyway.
>
> So I think OP_CRLTV alone works fine for them too...
>
> (Does that make sense, or am I missing something obvious?)
>
> Cheers, aj
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9
mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k
dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb
j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD
/csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th
RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=
=U0N6
-----END PGP SIGNATURE-----

2023-06-07 17:41:27

- reply

📅 Original date posted:2015-09-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
+1
I was actually waiting for this. It makes 'smart contracts' simpler
and better from many points of view.
Pete I don't see anything about RCLTV in BIP65, was that a separate
BIP? Which one is it and are we also deploying it via
IsSuperMajority()? RCLTV in addition to CLTV would be trivial so maybe
we can take the pain just once?
On 9/27/2015 9:50 PM, Peter Todd via bitcoin-dev wrote:
> Summary -------
>
> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> I've backported the CLTV op-code and a IsSuperMajority() soft-fork
> to the v0.10 and v0.11 branches, pull-reqs #6706 and #6707
> respectively. A pull-req for git HEAD for the soft-fork deployment
> has been open since June 28th, #6351 - the opcode implementation
> itself was merged two months ago.
>
> We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
> rolling on miner adoption. We have consensus that we need CLTV, we
> have a well tested implementation, and we have a well-tested
> deployment mechanism. We also don't need to wait for other
> soft-fork proposals to catch up - starting the CLTV deployment
> process isn't going to delay future soft-forks, or for that matter,
> hard-forks.
>
> I think it's possible to safely get CLTV live on mainnet before the
> end of the year. It's time we get this over with and done.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWCRIeAAoJEIN/pSyBJlsRlqgH/iir3Ao99WMNV0xC5RL+fv/Q
J1az1dXif9w9sTaCZMkENyIH9B2kwmOcPX/pU+p75qNvhQi9OrNMNRE8Wlwa+tcL
DD9DbyiQvxKdXjCnZqUyyIgBjuFbiF5VNQ67B1faEnzvmX81PoDjd2FPC51WChjZ
j7xPcJ73d23OPXpsKtyaUwn1QbGwprhFCEkcqjC50gw/IQkMJiqZ6pMepDVSyGKl
RpOsWCyCVoTJtM5NFk7wXg5LBFA7rXXQL56M00YJKLJAx/ooGb2T4ZRX0GeEWX8/
wquNA9Bj7picIr20sPohGE0cr2QiD3gmL9qLT2ZDlrFFDk8thL8afOx00Z6ih3I=
=dPXd
-----END PGP SIGNATURE-----

2023-06-07 17:40:35

- reply

📅 Original date posted:2015-09-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Nobody said anything about trusting the governments in the way such as
you describe.
No matter how much you want to disagree here, Mike Hearn is right on
some aspects. He only said that bitcoin needs to have larger user
base, more use cases, making it more popular and less likely to be
banned by the governments because of political reasons. He did not say
"let's trust the governments and centralize bitcoin, give them the
possibility to trace/seize/control people's bitcoins, own all the full
nodes or hashing power" or anything like this. So, I think he wants to
suggest "be smart and Play by the rules, follow your interest". The
general threat model for which we want to scale is: larger user base
(not necessarily by increasing the blocksize - just increase the
transactions per second using the best way from all points of view),
more use cases for simple people who only do basic stuff, more
popularity but all these without the possibility for some actor to
control more than he should (like a government agency). For example,
just a summary (among many others): it will always be impossible to
freeze anyone's coins, or take them without the party's consent, or
make it mandatory to tie bitcoin addresses / wallets to real world
identities.
If we think governments are the threat, it's bad. This is because they
can make bitcoin illegal, and no matter what you or I think, there
will _always_ be more people who follow the laws (even the immoral
ones) than people who don't. If it's illegal / banned in relevant
places/countries/continents, bitcoin will be useless. What good will
it be if you can only use it anonymously in a dark-web via Tor, and
you can't tell anyone you do it and can't exchange it to fiat or vice
versa? Bitcoin has to be legit, have normal use cases and be as
popular as possible. Don't think that if tomorrow some government bans
bitcoin there will be a revolution supporting freedom and free speech
and who had this terrible idea will be jailed forever - this will not
happen. What will happen is that users under that jurisdiction will
not use bitcoin any more, merchants from there will not accept bitcoin
any more and exchangers from there will disappear. If some of them
will remain to continue doing it as an outlaw, I assume their number
will be insignificant anyway. If we move towards crypto-anarchy where
we want to say "f*** the laws, f*** the government, f*** everything",
we already lost and this should not be the consensus here under any
circumstances. We, a few computer experts on this mail list using
bitcoin is not what it will make it strong. What will make it strong
is millions of human beings from all social classes and with various
occupations using it for whatever boring reason each one might have.
+1: An outlaw currency is useless even to outlaws.
> On 9/20/2015 4:23 PM, Steven Pine wrote:
>> It's amazing how foolish some people are to continue trusting
>> governments especially in light of recent history: a seemingly
>> endless, Orwellian 'war on terror', multiple regional conflicts
>> often justified by fake evidence, wholesale disregard of law and
>> basic human covenants such as do not torture, ubiquitous and
>> secret global surveillance.
>>
>> Anyone who doesn't consider governments the proper threat model
>> is either a shill or an idiot.
>>
>> On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev"
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Until this is settled, Bitcoin has no clear direction and
>> developers cannot make effective decisions:
>>
>>
>> How exactly do things set "settled" in this environment?
>>
>> People looking at Bitcoin think a small group of developers and
>> miners "control" these decisions. Not sure if "control" is the
>> right word but that is the perception.
>>
>> Russ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJV/yYyAAoJEIN/pSyBJlsRbagH/1mv0u+xUy2FhYhk07irH9Qd
+U/v7xOLfrzz8j7BzcqLAt3Jey0r00oWbLpay4EyhtoOjPFSFwXZ5Cz/2FChbTFO
kNFtrQpR9ioRAHslePzhIWl0Zl3qz6a7HzrYGl7hLZVJGmXdAncpGEZLpgjONggb
R+dbKipICkRCjuOWZkpULLVUEfTTdy7bkBTR33wVb7QxRhdJNdLtXc9E0xEWPwfy
AalDSu/nhg+VLjIW9NUGky8oqk1pqnHS8AkkAt0jLaemdWgLTzt6Ll4+w4GYaLrj
Ac2te3HXPwUzyq9xnoae5ESOU7MWzkzvyKQs35c4z03aLz2UxHjEL6o6K50leAw=
=43rd
-----END PGP SIGNATURE-----

2023-06-07 17:38:58

- reply

📅 Original date posted:2015-09-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
That would be very wrong and cause a lot of problems and 'political
chaos' without solving at least one (technical) problem in exchange.
Bitcoin Core is a good quality code. It is open source and free.
Anyone can contribute and submit small changes, improvements.
Controversial changes are not easily merged not because the
maintainers do not want, but because they represent a threat to the
entire ecosystem, one way or the other. We have to very carefully
balance the gains and the risks. If we try to never reach a consensus
on purpose, this will only cause instability, and a possible result
could be that we will end up having many more weaker implementations
running in the network, decreasing the security overall and for everyone.
While I do agree with some of your points of view and I am happy to
see you advocate for 'more decentralization', please let me point you
in a better direction (I think): there is a much bigger problem than >
~90% of the full nodes running Bitcoin Core software - it is
*centralized mining (e.g. a lot of hashing power behind a single full
mining node)*.
On 9/1/2015 5:16 AM, Peter R wrote:
> I agree, s7r, that Bitcoin Core represents the most stable code
> base. To create multiple implementations, other groups would fork
> Bitcoin Core similar to what Bitcoin XT did. We could have:
>
> - Bitcoin-A (XT) - Bitcoin-B (Blockstream) - Bitcoin-C (promoting
> BIP100) - Bitcoin-D - etc.
>
> Innovation from any development group would be freely integrated by
> any other development group, if desired. Of course, each group
> would have a very strong incentive to remain fork-wise compatible
> with the other implementations.
>
> In fact, this just gave me a great idea! Since Wladimir has stated
> that he will not integrate a forking change into Core without Core
> Dev consensus, *I suggest we work together to never reach consensus
> with Bitcoin Core. *This will provide impetus for new
> implementations to fork from Core (like XT did) and implement
> whatever scaling solution they deem best. The users will then
> select the winning solution simply based on the code they choose to
> run. The other implementations will then rush to make compatible
> changes in order to keep their dwindling user bases.
>
> This is the decentralized spirit of Bitcoin in action. Creative
> destruction. Consensus formed simply by the code that gets run.
>
> *Let's kill Bitcoin Core and allow the green shoots of a garden of
> new implementations to grow from its fertile ashes. *
>
> Sincerely, Peter R
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJV5iFqAAoJEIN/pSyBJlsRMvIH/RiE8BhlXPbNOQW01HBJTBOD
3H4bgaZoXuxSq2B1F4zKa/FvKJKtq7BGR3hLEj5tascqZTE2YsksRqmEednFNvbL
XOliCjees6nI/oz/aYFuz9rFoKH4cxA7bJmbvieqGSOqDt7rtClaO2JzBycilngS
F5pVGjKlprprTn4XUS8R40rfYVFbYyxaMnWBOnkgEpEAbtEvNRcASSW4HQoxuGRL
6E8mzp8f23zAv6ENxKEfQoIf5SBBfYf8v2xV+YY9JcFjwh4MAQ7zFazsChh83D42
eI01jfuh58f0DS6qGmjb++N+a/mbgmQhIC4yV4iRZKiIHp9o2xKlSv4NyEJIHlM=
=JnYI
-----END PGP SIGNATURE-----

2023-06-07 17:38:41

- reply

📅 Original date posted:2015-08-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Decentralization depends on the context and does not have a definition
in a form that it was demanded... I can confirm we have people in our
community which do understand decentralization, and quite good
actually, just there is no definition if the form demanded.
It is known that ~90% (at least of the nodes accepting incoming
connections) are running Bitcoin Core software. This does not mean
that Bitcoin is somehow less decentralized. Bitcoin Core is open
source, it has many contributors from all over the world and there are
many pull requests - most of them do get merged if you check the
commit history. It is widely used because the quality of the code is 5
stars. There are other implementations as well, they are just not
widely used. This does not mean one is not free to write his own
implementation of the Bitcoin protocol (assuming he follows the
consensus rules of the network). The biggest problem is convincing
users to adopt that implementation, which is a normal thing which
happens in general, not only related to software implementations.
The problem is there is no other implementation out there which comes
near the quality of the code in Bitcoin Core. I am actually eager to
try other implementations as well, but something serious, because
Bitcoin itself is a payment protocol not something to play with.
This is the reason why a lot of developers contribute to Bitcoin Core
rather than writing their own implementation. This only makes Bitcoin
Core stronger, better, and obviously the result is that it has
majority in the ecosystem for good reasons. If I'm experienced in a
certain segment related to software developing, I am better of in
contributing to Bitcoin Core just with the part I know instead of
writing from scratch my own implementation.
On 9/1/2015 2:32 AM, Peter R via bitcoin-dev wrote:
> On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>> Even so, *decentralization is a means to an end* - not an
>> end-goal. It is essential for Bitcoin to be a useful alternative,
>> of course.
>
> I agree. What about decentralization in development? Gavin
> recently said that he wants to "get to the point where there will
> be multiple robust implementations of the core protocol."
>
> When I look at this image (https://i.imgur.com/zivHJvY.gif)
> illustrating centralization in nodes, mining and development, the
> biggest source of concern for me is the 85% node share around
> Bitcoin Core. With this level of centralization, it may be
> possible in the future for a group of coders to prevent important
> changes from being made in a timely fashion (e.g., should their
> interests no longer align with those of the larger Bitcoin
> community).
>
> It is my opinion, then, that we should support multiple
> implementations of the Bitcoin protocol, working to reduce the
> network's dependency on Core.
>
> Best regards, Peter R
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJV5OeqAAoJEIN/pSyBJlsRRsoIAMmdyeE+Sro14NIHy6jQqTH3
JdkhUg6lg7S58tqs7ahQ/U2QGMPLaQae9yv3NidKpyqzL0YXtc2+r7RDBp0p2L4O
ieBJfJRBDwjjHYun+h7VTkPRbFGoBs/vwtTahd+uxUjwdEhiOxI2Q8pY8dLbdmJz
5lyA3TIcOVy3FjGYp3ji8aBQkw4o9OZbgmY/iCmVONgup96+81/FdR8P6wwdi3tg
Hep+4iU5Z+RHVE0sQhJDgl8Rw2oY6cmfxOCdFalRAASfZClkMfZok7eDE5yWtUbE
tn9tEP82tc3OwZCC+XvpVggVWnCp/rGZFslfTdiWXWeLXhs+JLf0hWet4/SWCT0=
=zQ9s
-----END PGP SIGNATURE-----

2023-06-07 17:38:16

- reply

📅 Original date posted:2015-08-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
2^256 x _NO_
On 8/28/2015 5:00 AM, odinn via bitcoin-dev wrote:
> No.
>
> On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
>> Hi,
>
>> I am proposing to create a AML-KYC module to control the network
>> and also qualify use cases in OFAC compliant way. Here is the
>> attached doc.
>
>> Please provide your feedback and suggestions.
>
>> Best, Prabhat Kumar Singh
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJV4vtvAAoJEIN/pSyBJlsRLhgIANLoG2/NNuc+sAMZnSojWQf7
UxJeOLFE7XXOCwDeUPfbgJ6JxYMTQwqT/mOAAPkHoAwm+k7SHUy+MuxTGnlui4n7
hKtRPdZ1ibYeBLV3CBQb9PEN2Ma7Djjh2LtBcbueF19w3j95NOSnTl9P3jOfc8kW
x2rAEoZFJeJUOE/prbedrzQ8wSHm9ekt4BXiDnUaR3Xvvp/NuVZ9+eWJT+lWS4fR
16zFQZPMYP6o2evnhluAJCTvP0q0Imz6d4I0Mryi2hLDX964sLpxP0tK+ASbtzwV
CknfKeSjwpZ116MMDSfgnya17AYc0o6RWl6XjAgciPAMJFQnhhSKzLNV9898AT0=
=It5v
-----END PGP SIGNATURE-----

2023-06-07 17:38:15

- reply

📅 Original date posted:2015-08-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
Please stop with the nonsense. Bitcoin is a decentralized payment
network. It operates globally, so neither jurisdiction can apply to it
and have effects. It is the sole responsibility of all the
users/businesses involved in Bitcoin to comply with their local
regulations while using Bitcoin. Trying to somehow standardize this
compliance at the backbone network level will be impossible in the
first place, and even if it was possible it would be a _huge_ mistake.
The word 'Bitcoin' already rings a bell in most places of the world
where there is a reasonable level of technology available. It is
powerful and we should continue the work to improve it. No law
enforcement authority or govt. branch is asking more than for
users/businesses to comply with the regulations that bind to them.
Someone in Belize for example does not have same compliance requests
with someone in Germany - which is why this is not even a subject to
be discussed on bicoin-dev mailing list. It is unique/custom for each
user/business, the requirements depending on their jurisdiction.
On 8/27/2015 11:15 AM, Patrick Strateman via bitcoin-dev wrote:
> Are you aware of the prior work in this field?
>
> https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/
>
> On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
>> Hi,
>>
>> I am proposing to create a AML-KYC module to control the network
>> and also qualify use cases in OFAC compliant way. Here is the
>> attached doc.
>>
>> Please provide your feedback and suggestions.
>>
>> Best, Prabhat Kumar Singh
>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJV3tlbAAoJEIN/pSyBJlsR438H/Aw6PCjPxLGuxdlDVmqQG4Lz
a95OVm8KqEfbiRGc1lYjBhh3JjXoUBuZKUgbnve6oFOBdNpmtm/OCJpCBQqaLDnT
Ksao1aM42c+1RdiLRhd3QjoDHyfRpNnE+XQ4lk+H0nMlroRos1K5Dpnmiea15yMQ
1mxvnKyW5mIRu11Z/6xEJ3tX8VoAk3G2MtYf0SRkfJjbdRai1JIL/4w/JJJnkS1L
klMYPQeHOolIaSgXfy/oCGgqDLVKi3utkDZuIqLe8Pg0OoQFOnn4k3vDdQ/U0N5z
r7rzvriXBlCaZttNi8MkLujP3ugcTAjLxzntS68vXIRwSy+VzrASYdDd6vXGR4U=
=61p4
-----END PGP SIGNATURE-----

2023-06-07 17:35:34

- reply

📅 Original date posted:2015-08-20
📝 Original message:On 8/20/2015 1:28 AM, Jorge Timón wrote:
[snip]
>> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
>> just by 2 people forking the software and submitting a consensus rule to
>> a vote, it means Bitcoin is dead already and it should be worthless! We
>> can't go around and panic every time somebody forks Bitcoin and tries to
>> change something - this should be allowed by the nature of its license.
>> If tomorrow 5 more people fork 5 different software implementing the
>> bitcoin protocol and submit 5 different new consensus rules to a vote,
>> then what? We should all sell so the price will drop to 1 cent, because
>> it is somehow not good enough, not stable enough?
>
> If they don't extensively lobby Bitcoin companies, they don't start a
> massive PR campaign labbeling other developers as "obstructionists"
> and don't misinform a big part of the Bitcoin users (often using
> logical fallacies, intentionally or not), probably those 5 new
> currencies will be ignored and nothing bad will happen.
> Unfortunately in this case a great division between users is being created.
>
This is exactly the point. If shouldn't matter if somebody who forks
also tries lobbying to Bitcoin companies and miners and also trying to
convince users to adopt the fork. Bitcoin should be immune to such
attacks, otherwise it is really flawed.
Think of a very unlikely but not theoretically impossible example:
The Prime Minister of X with a government controlled authority forks
Bitcoin and changes a very important consensus rule. To ensure adoption
at hashing power level, he issues an order and raises electricity cost
for the entire population with 10 cents or so, and compensates the
miners adopting his fork with free electricity to mine Bitcoin. What
better stimulator could a miner get if not this one?
This is a social problem, not a technical one. There is no code in
Bitcoin or rule in the protocol itself to defend against such a thing.
What can and will make this attack impossible?
The users (economic power) which always ultimately should win any
dispute will refuse using the coins mined by the miners adopting the
controversial fork, which means the coins they mine will be worthless.
Even if they are created with low costs / free electricity, the mined
coins will still be worthless so it won't worth it for the miners to
take this step. Better pay for electricity and win something less vs.
not paying for electricity but winning nothing.
The same with -XT, nobody should be able to affect the entire bitcoin
ecosystem regardless how many miners or bitcoin companies you can lobby.
If this is possible, then Bitcoin is not as secure as we thought.
>> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
>> block in the future spends all the longest dusted coins to me, out of
>> which I give away 50% to the miners (so the hashing power will have
>> incentive to use my fork).
>>
>> Can they do it? YES
>> Will they do it? NO
>> Should the world care about this? NO
>>
>> It's as simple as that. We cannot continue to panic that "Bitcoin as a
>> project" is at threat because somebody forked it.
>
> Can you please stop conflating "Bitcoin Core as a project" and
> "Bitcoin consensus rules".
> They are different things and nobody is or can be "in charge" of the
> later, face it.
>
> Can you please also stop conflating software fork and
> "Schism/controversial/contentious hardfork"? Nobody has anything
> against the former and as you point out it is allowed by its free
> software license.
>
I agree, wrongly expressed here - sorry about it. It's true that a
software fork is nothing alike a Schism hardfork. I am still optimistic
that we aren't at a Schism hardfork yet and hope we won't get there and
-XT will rejoin in following the consensus rule and stop this division.
>> 4. By having a software fork and consensus rule submitted to vote we
>> actually prove how open Bitcoin is, and how there is lack of control
>> over it from all parties (developers, miners, engineers on the mail
>> list). This is reason to increase Bitcoin's value! It is a feature, not
>> a flaw!
>
> Why should miners have a voting power that the rest of the users lack?
>
This is something which seams very unfair to me as well. This was my
first question after the -XT release which Mike replied to here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010241.html
To be frank the arguments didn't convince me at all. I am against this
model where users will is ignored. By forcing you to stop using
something it's not what exactly I would call a way to express your will,
it is more like a force out.
>> It's very important for everyone in the ecosystem to understand:
>>
>> - yes, Bitcoin is open source, even you can fork it tomorrow if you want
>> and you think enough users might follow you.
>>
>> - no, it's not a requirement for 100% of the nodes in the network to be
>> running Core, or -XT or other implementation. The more we have, the better.
>>
>> - yes, there is absolutely no authority in Bitcoin - this is what lead
>> to this dispute in the first place. This is the truly decentralized
>> nature of the software, not important if we have 10.000 full nodes or
>> 1000 full nodes.
>
> All this sounds reasonable.
>
>> - no, Bitcoin won't split / die or whatever because of this fork.
>> Regardless what it happens, if XT will reach the threshold or not,
>> Bitcoin will go on just because it has some unique advantages and has no
>> competitor from some points of view.
>
> But you cannot know this will happen this way!
> If the threshold is reached (let's forget about noXT for now), the
> remaining miners cannot be forced to adopt bip101.
> And users can never be forced to adopt hardforks.
> It is possible that 75% of the hashrate moves to the bip101 chain
> while 99% of the users remain in the old Bitcoin chain. Or 50/50,
> 40/60...nobody knows.
>
>> - Bitcoin by its design has many many advantages, but also the
>> limitation that it relies on majority being honest / doing the right
>> thing! This is just the way it is, and the benefits it is offering
>> heavily win over this fundamental limitation.
>
> No, it doesn't rely on that. It just relies on the majority of the
> miners not attacking the network for too long (ie the number of
> confirmations people are waiting).
> If I'm running a full node, I'm not isolated from the network and the
> majority of the hashrate is not reorging the chain I am safe no matter
> how dishonest the "majority" (whatever that means in this context) is.
>
Correct - but the point still stands. If 75% of the hashing power wants
to do something which you don't agree to, as an user you don't have any
real options to prevent them. Only game them as in don't use bitcoin to
decrease its value so they are mining worthless or less valuable coins -
but by this you are hitting Bitcoin as a whole and not just the miners.

2023-06-07 17:35:31

- reply

📅 Original date posted:2015-08-19
📝 Original message:Hello Jorge, Eric,
With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
blocksize increase neither against it, because plain and simple I don't
have enough arguments to take some definitive decision on this topic.
What I am angry about is spreading FUD that a fork could kill Bitcoin
and what we are experiencing now is somehow terrible.
1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
split it into 2 different coins. It is the result of an open source free
system which lacks centralization. It is just at early stage, it could
have thousands for forks (or fork attempts) during its life.
2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
something bad to Bitcoin. So far everything they have done is (or should
be) allowed. They have forked an open source software and implemented a
voting system for a consensus rule change - doesn't sound like they are
committing a crime here (either legally or morally). If they are
qualified enough to maintain the software, or if the decision is
technically correct or not is another story, and it should only matter
to whoever uses / wants to use -XT.
3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
just by 2 people forking the software and submitting a consensus rule to
a vote, it means Bitcoin is dead already and it should be worthless! We
can't go around and panic every time somebody forks Bitcoin and tries to
change something - this should be allowed by the nature of its license.
If tomorrow 5 more people fork 5 different software implementing the
bitcoin protocol and submit 5 different new consensus rules to a vote,
then what? We should all sell so the price will drop to 1 cent, because
it is somehow not good enough, not stable enough?
I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
block in the future spends all the longest dusted coins to me, out of
which I give away 50% to the miners (so the hashing power will have
incentive to use my fork).
Can they do it? YES
Will they do it? NO
Should the world care about this? NO
It's as simple as that. We cannot continue to panic that "Bitcoin as a
project" is at threat because somebody forked it.
4. By having a software fork and consensus rule submitted to vote we
actually prove how open Bitcoin is, and how there is lack of control
over it from all parties (developers, miners, engineers on the mail
list). This is reason to increase Bitcoin's value! It is a feature, not
a flaw!
It's very important for everyone in the ecosystem to understand:
- yes, Bitcoin is open source, even you can fork it tomorrow if you want
and you think enough users might follow you.
- no, it's not a requirement for 100% of the nodes in the network to be
running Core, or -XT or other implementation. The more we have, the better.
- yes, there is absolutely no authority in Bitcoin - this is what lead
to this dispute in the first place. This is the truly decentralized
nature of the software, not important if we have 10.000 full nodes or
1000 full nodes.
- no, Bitcoin won't split / die or whatever because of this fork.
Regardless what it happens, if XT will reach the threshold or not,
Bitcoin will go on just because it has some unique advantages and has no
competitor from some points of view.
- Bitcoin by its design has many many advantages, but also the
limitation that it relies on majority being honest / doing the right
thing! This is just the way it is, and the benefits it is offering
heavily win over this fundamental limitation.
On 8/19/2015 1:09 PM, Jorge Timón via bitcoin-dev wrote:
> On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I think that it is important to note that Bitcoin XT faces a natural
>> uphill battle.
>>
>> Since it is possible to setup atomic inter-fork coin trades. I do not
>> see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
>> XTBTC for BTC everyday for the first 100 days after the fork.
>>
>> In many ways Satoshi gets to decide the winning fork just by his huge
>> economic investment in Bitcoin.
>>
>>
>> Here is some simple game-theory for non-consensus forks:
>>
>> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
>> string.
>>
>> 2. Encourage all miners to false vote for the Bitcoin XT fork.
>>
>> - Now people have no-idea what % of the economy Bitcoin XT holds. -
>> Making it impossible for people to put economic faith behind Bitcoin XT.
>>
>> 3. Setup good Atomic Swap markets.
>> [...]
>> The price for XTBTC coins will plummet, Satoshi progressively dumping
>> his 1M stash over a year or it so will make sure that it doesn't recover
>> either.
>
> Some XTBTC advocates may sell all their BTC for XTBTC and viceversa.
> But I'm afraid that what most currency speculators (thus most Bitcoin
> holders) will do is just sell both all their BTC and XTBTC for fiat,
> and wait for things to settle before deciding whether to re-enter or
> not.
> This could result in both currencies' prices going down to 1 usd cent,
> nobody knows.
>
>> I cannot see how Bitcoin XT is but-not in a extremely weak position from
>> game theory.
>
> Unfortunately it also puts Bitcoin core in an extremely weaker
> position than it was before the Schism hardfork.
> Even if XT fails in making blocks bigger, it may destroy Bitcoin.
> That's probably not the goal of Bitcoin XT, but I don't think Andresen
> and Hearn fully undesrtand the risks of a Schism hardfork (not to
> mention their "followers" in the interwebs).
>
> Since we want to discard the assumption that Hearn and Andresen want
> to make Bitcoin centralized or destroy it, it's reasonable to conclude
> that have serious misunderstandings on how the global consensus works.
> This is consistent with some of their strong positions on Bitcoin Core
> policy defaults (like maintaining the first seen spending-conflict
> replacement policy [the dumbest possible one after "last seen"]
> forever).
>
> On Mon, Aug 17, 2015 at 2:33 PM, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB?
>
> Yes, it seems the simplest way to permanently separate your BTC from
> your XTBTC is to move them all in transactions bigger than 1MB. You
> may need too many outputs to increase the size (thus also hurting the
> utxo size in Bitcoin XT), but that's just a side effect.

2023-06-07 17:35:12

- reply

📅 Original date posted:2015-08-15
📝 Original message:Fair enough, this is what open source is all about. Good things
sometimes come out of controversial actions. I briefly read the
manifesto, saw the migration plan, it is not that greedy and in theory
it is possible to migrate safely with no (big) incidents.
What seams a little bit unfair is that only miners get to vote and
decide, and the users will have nothing to say about it. Not even
individual miners will vote, since it will be mostly only mining pools
(individual small miners will accept whatever their mining pool runs
on). There are more users than miners obviously, the miners just mine
transactions for the users, it is the users who keep the btc/usd price.
I use bitcoin heavily (not from time to time) but I don't mine - can I
vote? The way I see it I cannot, and I am not saying it is a bad thing,
but I missed the argument explaining why users don't matter and only
miners do.
The btc/usd rate is based on supply and demand, only users take part in
this. If 20% of the miners (hashing power) go away, the network will
still operate normally (lower nethash and probably difficulty) and the
btc/usd price will be the same, but if 20% of the users go away the
btc/usd price will drop -> mining will be less profitable -> miners
could be forced to quit. In other words, the users have more control
over the miners. Why ignore?
On 8/15/2015 8:02 PM, Mike Hearn via bitcoin-dev wrote:
> Hello,
>
> As promised, we have released Bitcoin XT 0.11A which includes the bigger
> blocks patch set. You can get it from
>
> https://bitcoinxt.software/
>
> I feel sad that it's come to this, but there is no other way. The
> Bitcoin Core project has drifted so far from the principles myself and
> many others feel are important, that a fork is the only way to fix things.
>
> Forking is a natural thing in the open source community, Bitcoin is not
> the first and won't be the last project to go through this. Often in
> forks, people say there was insufficient communication. So to ensure
> everything is crystal clear I've written a blog post and a kind of
> "manifesto" to describe why this is happening and how XT plans to be
> different from Core (assuming adoption, of course).
>
> The article is here:
>
> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
>
> It makes no attempt to be neutral: this explains things from our point
> of view.
>
> The manifesto is on the website.
>
> I say to all developers on this list: if you also feel that Core is no
> longer serving the interests of Bitcoin users, come join us. We don't bite.
>
>

2023-06-07 17:35:12

- reply

📅 Original date posted:2015-08-15
📝 Original message:On 8/15/2015 8:02 PM, Mike Hearn via bitcoin-dev wrote:
>
> I say to all developers on this list: if you also feel that Core is no
> longer serving the interests of Bitcoin users, come join us. We don't bite.
>
Bwhahahahahahahhahahahahah

2023-06-07 17:34:21

- reply

📅 Original date posted:2015-08-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Interesting point of view Thomas! I agree that if we only think
towards one single direction (treat trust as a super bad thing) we
might miss some good features (or scalability levels) among the way.
Benjamin:
> Lightning assumes explicit trust and ID - much like Ripple. That's
> not going to work, and I'm surprised that someone with basic
> knowledge of crypto doesn't see this problem. Having explicit
> counter-parties is something very different from Bitcoin where the
> entity doing transactions verification is unknowable and changes
> all the time.
Can explain why exactly do you think this? What is the problem that
you see in lightning model exactly? I am not arguing, maybe you are
right and there is a part of the lightning network proposal which I
missed, so that is why I am asking for clarification here.
Lightning doesn't require explicit trust, worst case scenario you can
end up with coins blocked until next in-chain broadcast. It depends on
each and very hub, obviously there will also be trusted, identified
public hubs but we can also have anonymous hubs.
On 8/8/2015 12:24 PM, Benjamin via bitcoin-dev wrote:
>>> The point was NOT to trust no-one, the point was to trust
>>> everyone, but keep everyone honest by keeping the ledger open
>>> and publicly available.
>
> Trust takes many different forms and is not a binary function. You
> trust a surgeon to do an operation and a pilot to fly a jet, but
> not vice versa. To trust someone explicitly, you need to know who
> they are. Most social structures work without explicit identity and
> they still function quite well. For example companies are mostly
> anonymous to the consumer - if you buy something in a shop you
> trust a chain of people producing that good. A priori there is
> little reason to trust others, but rather that trust is already
> developed through social institutions. Money is one such
> institution with specific trust problems, and the history of money
> is indeed a very good way to study these problems. Unfortunately in
> Bitcoin development such insights are rare to find.
>
> Lightning assumes explicit trust and ID - much like Ripple. That's
> not going to work, and I'm surprised that someone with basic
> knowledge of crypto doesn't see this problem. Having explicit
> counter-parties is something very different from Bitcoin where the
> entity doing transactions verification is unknowable and changes
> all the time. Users of Bitcoin trust nodes doing the verification
> because they know it is in their best interest to be honest.
> Neither Sidechains nor LT have preserve that important property,
> and so IMO there are no good proposals to make Bitcoin scale (if
> that is possible at all).
>
> On Sat, Aug 8, 2015 at 10:54 AM, Thomas Zander via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I didn't say off-chain, and gave an example of on-chain usecase
> with trusted middleman.
>
> So, no, that's not what I meant.
>
> Sent on the go, excuse the brevity. Original Message From: Adam
> Back Sent: Saturday, 8 August 2015 09:50 To: Thomas Zander Cc:
> Bitcoin Dev Subject: Re: [bitcoin-dev] trust
>
> If you are saying that some people are happy trusting other
> people, and so would be perfectly fine with off-chain use of
> Bitcoin, then we agree and I already said that off-chain use case
> would be a constructive thing for someone to improve scale and
> interoperability of in the post you are replying to. However that
> use case is not a strong argument for weakening Bitcoin's security
> to get to more scale for that use case.
>
> In a world where we could have scale and decentralisation, then of
> course it would be nice to provide people with that outlook more
> security than they seem to want. And sometimes people dont
> understand why security is useful until it goes wrong, so it would
> be a useful thing to do. (Like insurance, your money being seized
> by paypal out of the blue etc). And indeed providing security at
> scale maybe possible with lightning like protocols that people are
> working on.
>
> Adam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJVxeMaAAoJEIN/pSyBJlsRJFoH/RbgArUMJStQwF92XZk99dUd
0xI/VU1goFLDFiFVkrea7uNWUrWw0GM9nDq0kTIV+mTi9rTYgWKlgA1XZnPusr35
GpDhXxoG3mJmay9AX1fezrZjGmCZPCjSnPWa+BeQCSMXnVchZX0U4XZSwgD7qTIU
7o4r5JIDuGxXyPcwECnB7ePmZ8xA2QGQaMW6nnMhlA4KCanSd5/78kcpUp/kGAJ1
chjhV2g7tAeq3NMs2IXeIMiEAqji0B7RRAejviBg9CAwbpo4dP3dRz8hv/qPx6K0
Mu6jHczCQOUyAHagwG8q4+laMbkskVETw18NwluspOZi3inxvVpOD60CDqSZPS4=
=ogMZ
-----END PGP SIGNATURE-----

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-29
📝 Original message:We could care less about you selling your bitcoins or moving to
something else.
What we care more is keeping bitcoin a successful project which offers
clear benefits to the world. I agree a fee market is good and needed,
and transactions shouldn't be free ever, but users should also be able
to transact fast and relatively cheap, as opposite to the competition,
or at least with the same costs, so people won't move to something else.
The more people use bitcoin, the more demand we have on the market for
BTC, the higher BTC/FIAT rate will be, more people will become
interested in mining and so on. Bitcoin is not a rich-only-private-club,
it's an open, global, decentralized payment network. The less people use
it... I guess you figured it out.
So we could care less that you will go away in case the fee market won't
become absurd or too expensive to use for most users. Having some
offchain solution for small transactions would be a good idea, but this
doesn't mean we should make small transactions impossible due to absurd
fees.
On 7/29/2015 8:47 PM, Raystonn . via bitcoin-dev wrote:
>> When a category of users would get priced out because of the fee
> market, they would be free to use any altcoin they want.
>
> I believe that pretty well sums up where we’re headed if transaction
> rate is artificially limited, whether that be by maximum block size
> limit or something else. A fee market will necessarily include more
> than just Bitcoin. The reality is it’s very easy to trade value across
> different blockchains, and thus a fee market will bleed value from
> Bitcoin and give it to alternative blockchains. If Bitcoin’s blocks are
> at maximum capacity, people will exchange for something that allows them
> to transact with a lesser fee, then make the desired payment. This adds
> value to the alternative blockchain and removes it from Bitcoin.
>
> Anyone thinking the fee market can be restrained to Bitcoin alone is
> mistaken.
>
>
> *From:* Vali Zero via bitcoin-dev
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Wednesday, July 29, 2015 7:09 AM
> *To:* bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* [bitcoin-dev] Răspuns: Personal opinion on the fee market
> from a worried local trader
>
> I am disappointed that you did not understand my point of view. Let me
> rephrase it for you,
>
> People tipping, buying 0.99$ products and gamblers that need Bitcoin
> transactions *more* than the rest of the people will afford the fees
> that establish the equilibrium between demand and supply of Bitcoin
> transactions. The people are free to use they money for whatever they
> like, but you should understand that Bitcoin transactions are not free.
>
> I was merely attempting to point out that spammers and gamblers would be
> the first ones that would go away. They would be free to spam or gamble,
> but they would have to pay for it.
>
> When a category of users would get priced out because of the fee market,
> they would be free to use any altcoin they want.
>
> Please understand that not everyone will leave. The more important
> players will remain, those that need it the most. The other players are
> free to use whatever altcoin they wish.
>
>
> În Miercuri, 29 Iulie 2015 16:47:57, Angel Leon <gubatron at gmail.com> a
> scris:
>
>
> "the gamblers and perhaps people transacting very low amounts. The
> people that actually need Bitcoin would remain."
>
> so people tipping, buying $0.99 products, and gamblers actually don't
> need Bitcoin.
> Who are you to say what people need to use money for?
> This statement goes against the freedom of decentralization and
> financial freedom Bitcoin should be able to provide.
>
> It's an open network and it will be used as most users see fit, and that
> requires a blocksize increase wether you like it or not, it's simple
> physics, other time wait times will become unbearable for those not
> willing to pay the high fees, if people leave, then it only mean
> bitcoins isn't useful, and if bitcoin isn't useful, it's worthless.
>
>
>
> http://twitter.com/gubatron
>
> On Wed, Jul 29, 2015 at 9:27 AM, Vali Zero via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hello,
>
> I have been reading an argument saying that paying higher fees would
> scare Bitcoin users and they would stop using it, preferring bank
> transfers or other payment methods. This does not make sense for me.
> If some users leave, then demand for bitcoin transactions goes down
> and so do the fees. The others remain.
>
> Fee market means that an equilibrium is found between the demand for
> bitcoin transactions and the available supply (given by the block
> size). The fee is the price that finds this equilibrium.
>
> If a fee market starts to exist, the first ones to leave are the
> spammers, probably followed by the gamblers and perhaps people
> transacting very low amounts. The people that actually need Bitcoin
> would remain.
>
> Please allow this fee market to form...
>
> In the absence of a functioning fee market, I will refuse to run
> Bitcoin code that increases the block size and will do my best to
> tell everyone I know not to upgrade towards running such code. If
> Bitcoin succombs to the free stuff army, I will sell all the coins
> and leave. Nothing is for free.
>
> I apologize for any exagerations, but I just felt strongly towards
> expressing my opinion here. I'm only a local Bitcoin trader,
> computer engineer, with a reasonable understanding of free markets.
> And I'm running only one full node.
>
> Kind regards,
> Valentin
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

2023-06-07 15:42:46

- reply

📅 Original date posted:2015-07-24
📝 Original message:Hi,
I think this would be too complicated in practice and you'd have to
defend against many other types of attacks, including but not limited to
Sybil attacks, misbehaving servers not responding to requests,
misbehaving servers not forwarding requests, you'd need some kind of
directory servers or master servers which sign and authenticate the
public server keys, otherwise someone can poison that data and provide
the clients with wrong server keys.
Secondly, you'd not use RSA for this, but rather Ed25519 which is
faster, more cpu efficient and provides better security.
Last but not least, I don't see this as a major issue and I really thin
it is not worth your time. Better work on electrum server defenses,
hardening them against DoS. After all, Electrum is a SPV based Bitcoin
wallet, so it cannot be more anonymous than Bitcoin itself, which we
already know it is pseudonymous, not anonymous and transactions can
/will be linked to addresses. This is just a limitation of Bitcoin as it
is today, and using SPV you assume the risk of trusting the server, it's
just how SPV should work. As a pro, it gives you the ability to sync
immediately and not download the entire blockchain.
Privacy concerned people should run their own Electrum server and make
it accessible via .onion, and connect the bitcoind running on the
electrum server host only to other onion peers (onlynet=tor). We should
highlight that using Electrum with Tor cannot leak more that some
addresses belong to the same wallet, which is not the end of the world.
On 7/22/2015 6:51 PM, Thomas Voegtlin via bitcoin-dev wrote:
> Hello,
>
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a single server. This means that the chosen server knows
> that a given set of addresses belong to the same wallet. That is true
> even if Electrum is used over TOR.
>
> There have been various proposals to improve on that, but none of them
> really convinced me so far. One recurrent proposal has been to create
> subsets of wallet addresses, and to send them to separate servers. In my
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
>
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
>
> What do you think? What are the costs and benefits of such an approach?
>
> (Note: this will not work if all servers, or a large fraction of them,
> are controlled by the same entity that controls M)
>
>
> Thomas
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:40:41

- reply

📅 Original date posted:2015-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
+1 for this Jorge.
Agreed the majority should not be able to enforce rules over the
minority. But if the majority will just leave and create an altcoin or
whatever, this will leave the remaining minority with a less value (or
even 0 value) product or service. By enforcing some rules agreed by
the majority or supermajority, the minority will be dragged along and
even so with rules they haven't signed up for, they will still have a
product or service which is worth something.
That is why we have to be very careful into deciding this.
This debate is good, there are lots of valid points from smart people
and I am happy to see there is so much interest in this project, and
regardless if the blocksize hard cap will be changed or not I do hope,
if a hardfork will happen, it will also include a smart change that
will allow future changes (requiring hardforks) simpler, with less
headache and risks involved.
On 6/28/2015 3:13 PM, Jorge Timón wrote:
> On Sat, Jun 27, 2015 at 2:10 PM, NxtChg <nxtchg at hush.com> wrote:
>>
>> On 6/27/2015 at 2:04 PM, "Jorge Timón" <jtimon at jtimon.cc> wrote:
>>
>>> But that option is not unknown...
>>
>> It is, until it actually happens. Before that, anything is a
>> speculation. That's why risk is attached to both "doing nothing"
>> and "raising the limit".
>
> Fortunately we have a lower limit in the standard mining policy to
> see if the skies turn purple when we hit that limit like some
> people predict.
>
>> Various people perceive these risks differently and there is no
>> clear mechanism currently to somehow gauge what the majority
>> wants. So it's tempting to just give up and say: let's do
>> nothing.
>>
>> In this situation, doing a "software fork" seems like the only
>> way to actually see how many people/interests are in favor of
>> bigger blocks.
>
> But this is NOT a way to see the majority of anything. I can run
> 1000 nodes, have you heard of sybil attacks? There's simply no
> decentralized way of voting that works. Otherwise we could vote on
> each block instead of using proof of work. Miners voting on size is
> also ridiculous since big miners have an incentive to completely
> remove the limit and make smaller miners unprofitable.
>
>> (Whether the majority has a moral right to dictate the minority
>> is a tough philosophical question, which should probably be left
>> out of this discussion :)
>
> No, this is very important. The majority has no right to dictate
> on the minority. If the majority of bitcoiners wanted demurrage
> (and we actually had a working method for "measuring majorities"),
> the minority would still say "these are not the rules we signed up
> for, go make freicoin as a separate chain". And that is very
> reasonable. If some people want a more centralized version of
> Bitcoin they can create an altcoin too. Doesn't dogecoin already
> have big blocks? _______________________________________________
> bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJVkBKpAAoJEIN/pSyBJlsR4FMIAITS10rtx4Uw20WjFPkWZRB3
ucRRPncXkKehQlFd9cY6sgPAUk50rM0FSpm69Ra1KnawNLLxkgpzTGZk1iTHbGe8
JlWoTduLOyvInVXCdM8l71TVWoyt8rDZpg1KAsaMmMi9UvstHZPGZp85XScxhYyC
uBHv1Hm7oeszPBkjGsB9B9mF/gH8naCjcNva+XbcgsKNM681xbOeJQ9qW0GOwq+Z
j4ocY77G8AENZkhCy2KKiJrz0ZBVDbnJAos06uKrdxhUPBwliVpyJW96aFsRp/sL
SNqTkpSmvxgSUBHCrRoWiBf/xo06W9QeoEfoROfgFkSTcUlPWqCJHxqwOLk2VrY=
=eUgF
-----END PGP SIGNATURE-----

2023-06-07 15:40:13

- reply

📅 Original date posted:2015-06-25
📝 Original message:+1 for Wladimir, as I said. Anyone who checks the commit history on
github can see that he decides quite well all the time for code changes.
These fake arguments are thrown by people who hope they will force him
into deciding for consensus / protocol changes. This won't happen.
On 6/25/2015 4:41 PM, Eric Lombrozo wrote:
> Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please.
>
> - Eric Lombrozo
>
>> On Jun 25, 2015, at 6:36 AM, s7r <s7r at sky-ip.org> wrote:
>>
>> I guess you mean Wladimir here. You are wrong, Wladimir does decide and
>> if you look at the commit history on github.com for bitcoin core you
>> will see, that he does actually decide and does it really good.
>>
>> He just does not want to decide (and he really should not) on CONSENSUS
>> changes or protocol changes. This is totally different.
>>
>> Stop the analogy with "other open source projects". This is an open
>> source project (the code part) but unlike any other open source projects
>> which can just be forked, without affecting the other users, in bitcoin
>> we need all the users to trust a single blockchain, so it'll have value.
>> If some users fork the blockchain and change consensus rules, they are
>> not just harming themselves, they are affecting ALL the users, since
>> such a thing would have strong impact over the BTC/FIAT rate, affecting
>> everyone in the ecosystem. There is economics involved here and human
>> element, things which are hard to fix via code, even if the code is
>> developed in open source style.
>>
>> It's one thing to decide to merge some patches, improve the code, etc.
>> and another thing to decide for consensus rules when you literary play
>> with 4 billion united states dollars of other people's money. This
>> shouldn't be Wladimir's responsibility, it's just unfair for people to
>> throw this on his shoulders.
>>
>> I do not under any circumstances suggest that the consensus should
>> remain as it is now forever. We need to improve it, but this should not
>> be on the maintainer. I've seen smart suggestions on this mail list
>> where consensus changes can be made during a long period of time,
>> through soft forks, where all users/miners/exchangers/merchants get the
>> chance to choose / take action.
>>
>> On 6/25/2015 3:07 AM, Milly Bitcoin wrote:
>>> I have seen this question asked many times. Most developers become
>>> defensive and they usually give a very vague 1-sentence answer when this
>>> question is asked. It seems to be it is based on personalities rather
>>> than any kind of definable process. To have that discussion the
>>> personalities must be separated out and answers like "such-and-such
>>> wouldn't do that" don't really do much to advance the discussion. Also,
>>> the incentive for new developers to come in is that they will be paid by
>>> companies who want to influence the code and this should be considered
>>> (some developers take this statement as an insult when it is just a
>>> statement of the incentive process).
>>>
>>> The other problem you are having is the lead developer does not want to
>>> be a "decider" when, in fact, he is a very significant decider. While
>>> the users have the ultimate choice in a practical sense the chief
>>> developer is the "decider." Now people don't want to get him upset so
>>> nobody wants to push the issue or fully define the process. Now you are
>>> left with a broken, unwritten/unspoken process. While this type of
>>> thing may work with a small group of developers businesses/investors
>>> looking in from the outside will see this as a risk.
>>>
>>> Until you get passed all the personality-based arguments you are going
>>> to have a tough time defining a real process.
>>>
>>> Russ
>>>
>>>
>>>
>>>
>>>
>>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>>> I would like to start a civil discussion on an undefined, or at least
>>>> unwritten, portion of the BIP process. Who should get to vote on
>>>> approval to commit a BIP implementation into Bitcoin Core? Is a
>>>> simple majority of these voters sufficient for approval? If not, then
>>>> what is?
>>>>
>>>> Raystonn
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:40:12

- reply

📅 Original date posted:2015-06-25
📝 Original message:I guess you mean Wladimir here. You are wrong, Wladimir does decide and
if you look at the commit history on github.com for bitcoin core you
will see, that he does actually decide and does it really good.
He just does not want to decide (and he really should not) on CONSENSUS
changes or protocol changes. This is totally different.
Stop the analogy with "other open source projects". This is an open
source project (the code part) but unlike any other open source projects
which can just be forked, without affecting the other users, in bitcoin
we need all the users to trust a single blockchain, so it'll have value.
If some users fork the blockchain and change consensus rules, they are
not just harming themselves, they are affecting ALL the users, since
such a thing would have strong impact over the BTC/FIAT rate, affecting
everyone in the ecosystem. There is economics involved here and human
element, things which are hard to fix via code, even if the code is
developed in open source style.
It's one thing to decide to merge some patches, improve the code, etc.
and another thing to decide for consensus rules when you literary play
with 4 billion united states dollars of other people's money. This
shouldn't be Wladimir's responsibility, it's just unfair for people to
throw this on his shoulders.
I do not under any circumstances suggest that the consensus should
remain as it is now forever. We need to improve it, but this should not
be on the maintainer. I've seen smart suggestions on this mail list
where consensus changes can be made during a long period of time,
through soft forks, where all users/miners/exchangers/merchants get the
chance to choose / take action.
On 6/25/2015 3:07 AM, Milly Bitcoin wrote:
> I have seen this question asked many times. Most developers become
> defensive and they usually give a very vague 1-sentence answer when this
> question is asked. It seems to be it is based on personalities rather
> than any kind of definable process. To have that discussion the
> personalities must be separated out and answers like "such-and-such
> wouldn't do that" don't really do much to advance the discussion. Also,
> the incentive for new developers to come in is that they will be paid by
> companies who want to influence the code and this should be considered
> (some developers take this statement as an insult when it is just a
> statement of the incentive process).
>
> The other problem you are having is the lead developer does not want to
> be a "decider" when, in fact, he is a very significant decider. While
> the users have the ultimate choice in a practical sense the chief
> developer is the "decider." Now people don't want to get him upset so
> nobody wants to push the issue or fully define the process. Now you are
> left with a broken, unwritten/unspoken process. While this type of
> thing may work with a small group of developers businesses/investors
> looking in from the outside will see this as a risk.
>
> Until you get passed all the personality-based arguments you are going
> to have a tough time defining a real process.
>
> Russ
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>> I would like to start a civil discussion on an undefined, or at least
>> unwritten, portion of the BIP process. Who should get to vote on
>> approval to commit a BIP implementation into Bitcoin Core? Is a
>> simple majority of these voters sufficient for approval? If not, then
>> what is?
>>
>> Raystonn
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:39:34

- reply

📅 Original date posted:2015-06-21
📝 Original message:It did go through the list - I got it like any message from a subscribed
user.
On 6/22/2015 1:19 AM, Warren Togami Jr. wrote:
> This post from wtogami at apache.org <mailto:wtogami at apache.org> is from an
> address not subscribed to the list. It should be auto-rejected by the
> server. If this goes through to the list then something is wrong with
> the configuration.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:39:33

- reply

📅 Original date posted:2015-06-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is a new thread posting something else.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJVhzJeAAoJEIN/pSyBJlsRX00IAMKa4w5V5RJjnZ9zPo8gQBQJ
WFnnXQGVx5HlYQuaP/oV4EWeVUP/EZM6QiYV3aE3gJxVJAX99k7Cm9ilZthkhzhq
+LztI6SBeX1y61MueQUcj6eHW376e08HRkwn4OfOTvl6V9LnZ0Gf9etSnJsTPop4
0ebu53HKkOjpfxhX3r6riqty7K+TZberPlJ5ljkKm/Hg+tklNaReTWwZDn2hWwyI
/0uU9TKW5sKF/tjYjWXRsruyrHeDAXMMGsIL5KocYho2SG15aNmVvtvqF7szrapJ
9RYWCwCiWf4hnBe8R6IIN/Wu84Kq4/kqIsJGYficYMHUzLRYf13QfBL1fcfWrBA=
=XHak
-----END PGP SIGNATURE-----

2023-06-07 15:39:32

- reply

📅 Original date posted:2015-06-21
📝 Original message:ACK - all seams fine here.
Do we have all the archives imported? I run several full nodes and
mirrors for open source projects, if you think it's useful, I can
provide a mirror for the mail list archives.
On 6/22/2015 12:29 AM, Warren Togami Jr. wrote:
> Hi folks,
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> The move is now complete. The previous archive has been fully imported
> and new posts here will now be saved.
>
> *Greylisting Notice*
> Your first post to this list may be delayed by 5+ minutes due
> to Greylisting <https://en.wikipedia.org/wiki/Greylisting>. Subsequent
> posts should go through without delay. Contact Freenode #bitcoin-dev if
> you have any questions or concerns.
>
> *TODO*
>
> * LF will be upgrading Mailman soon to better handle posts from DKIM
> enforced domains.
> * There will be a few more config tweaks like auto-rejecting
> non-subscribed posts. Nobody has time to moderate this list, and
> mail silently disappearing into the moderation hold blackhole is
> worse than an instant reject message telling people to subscribe.
> Unfortunately, it is too dangerous to auto-reject spam ... those
> messages need to go into a blackhole to prevent bounce abuse.
>
> Warren Togami
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:39:30

- reply

📅 Original date posted:2015-06-21
📝 Original message:Hi,
Well, depends on your model and what you want to achieve. That would
depend on each wallet, I couldn't confirm nor deny that this is or isn't
true. You have to check with your wallet how it handles transactions
with nLockTime. Maybe you are the one who generates the nLockTime
transaction, but that needs to be broadcasted by the payee (your
recipient) when the locktime expires?
One way I would use nLockTime is to have the tx generated, and keep it
somewhere not related to my wallet(s) until the nLockTime expires, then
I can broadcast it to the network by /sendrawtransaction and have it
mined and included into a block.
On 6/21/2015 3:11 PM, Braun Brelin wrote:
> So, basically it sounds as though the wallet generating the transaction
> is what is responsible for holding on to the transaction and then
> only releasing it to the network when the NLOCKTIME value is less than
> or equal to the current time. Does that sound right?
>
> Braun
>
>
> On Sun, Jun 21, 2015 at 10:45 AM, s7r <s7r at sky-ip.org
> <mailto:s7r at sky-ip.org>> wrote:
>
> Hi
>
> I don't think that a transaction with nLockTime>0 will be accepted by
> nodes / relayed in the Bitcoin network, until its time expires (e.g.
> nLockTime==now). This means it obviously cannot be stored in a block,
> before its locktime expires. nLockTime is designed in a way that you,
> need to keep it offline (not broadcast it to the network because it
> won't be accepted or relayed by nodes) until the locktime expires, then
> you can broadcast it and it will be mined and included in a block, like
> a normal tx.
>
> This is exactly why Peter Todd and others are working on
> CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY - this is an
> enhancement to basic nLockTime which tends to offer to users the
> guarantee that if you have a transaction with nLockTime, the signer
> holding the private keys used to sign it cannot sign another one, with
> nLockTime 0 and broadcast it before the locktime for your tx expires.
>
> Cheers!
>
> On 6/21/2015 10:10 AM, Braun Brelin wrote:
> > Hi all,
> >
> > When a transaction with N_LOCKTIME>0 is created, does that transaction
> > get stored in a block on the blockchain or is it stored in the mempool
> > until the actual time (or block number) exceeds the current value? If
> > it is stored on the blockchain, how does that affect the concept of
> > pruning that is supposed to be going in to version 0.11? I.e. if I
> > create a transaction that doesn't take effect for 10 years, and that
> > transaction is stored in a block, does that block stay on the active
> > list for that period of time?
> >
> > Thanks,
> >
> > Braun Brelin
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>

2023-06-07 15:39:29

- reply

📅 Original date posted:2015-06-21
📝 Original message:Hi
I don't think that a transaction with nLockTime>0 will be accepted by
nodes / relayed in the Bitcoin network, until its time expires (e.g.
nLockTime==now). This means it obviously cannot be stored in a block,
before its locktime expires. nLockTime is designed in a way that you,
need to keep it offline (not broadcast it to the network because it
won't be accepted or relayed by nodes) until the locktime expires, then
you can broadcast it and it will be mined and included in a block, like
a normal tx.
This is exactly why Peter Todd and others are working on
CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY - this is an
enhancement to basic nLockTime which tends to offer to users the
guarantee that if you have a transaction with nLockTime, the signer
holding the private keys used to sign it cannot sign another one, with
nLockTime 0 and broadcast it before the locktime for your tx expires.
Cheers!
On 6/21/2015 10:10 AM, Braun Brelin wrote:
> Hi all,
>
> When a transaction with N_LOCKTIME>0 is created, does that transaction
> get stored in a block on the blockchain or is it stored in the mempool
> until the actual time (or block number) exceeds the current value? If
> it is stored on the blockchain, how does that affect the concept of
> pruning that is supposed to be going in to version 0.11? I.e. if I
> create a transaction that doesn't take effect for 10 years, and that
> transaction is stored in a block, does that block stay on the active
> list for that period of time?
>
> Thanks,
>
> Braun Brelin
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:37:12

- reply

📅 Original date posted:2015-06-10
📝 Original message:The mail list is public, so it's not like the data on it is somehow
sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
the message and sort/order them as you want, etc.
Why would you want to move to a paid solution? And why would you want
users to have to pay per message? This is the worst idea ever from my
point of view. We want to encourage people to join the community, run
full nodes, ask questions, come with solutions, ideas for improvements
and so on. Everyone should read and write and contribute as much as
possible with ideas in debates. You never know who can have bright ideas
in some contexts.
Bottom line is so far sourceforge handles the mail lists just fine. I
don't see a single advantage another mail list provider / system could
offer, except some headache and extra work for migration. The software
distribution via sourcefoge was cancelled for obvious reasons which I
fully understand and agree to, but it has nothing to do with the mail
lists. We have way more important things to brainstorm about.
On 6/10/2015 7:46 PM, Andy Schroder wrote:
> Regarding changing the e-mail list provider. Is anyone interested in
> sponsoring it? There are non-free options, but it may be difficult to
> always ensure the fee is being paid to the provider. I think finding an
> agreeable free solution may have been the issue before? I've also
> thought of trying to make a pay per message or byte solution (and this
> cost could be dynamic based upon the number of current mailing list
> subscribers). This could solve the who pays problem (the sender pays),
> as well as motivate people to be more concise and clear with their
> messages, and at the same time limit spam.
>
>
>
> Any thoughts?
>
> Andy Schroder
>
> On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:
>> On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
>>> http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
>> All our downloads (even old ones) have recently been deleted from sourceforge, for this reason. They haven't been mentioned in Bitcon Core release announcements for a long time.
>>
>> No opinion on the mailing list. Though I think it's less urgent. The issue of moving the mailinglist has come up before a few times and people can't agree where to move to.
>>
>> Wladimir
>>
>>
>> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:35:56

- reply

📅 Original date posted:2015-05-31
📝 Original message:Hi,
For the less crypto engineering experts but highly interested in Bitcoin
and working with Bitcoin on daily basis reading the list, what would be
an easy to understand explanation about how does this solution represent
a good fix?
So, we have a hard cap of 1 MB block currently. This is not enough
because more and more people use Bitcoin and the transaction volume
increased (yeey, good news). So, rather than fixing the issue for good,
we just increase the block size hard cap to 20 MB. I will not discuss if
this causes problems or not. But what are the future plans, when the 20
MB hard cap will be reached? Increase it again? This doesn't sound like
a fix, it sounds more like pushing the can down the road. Obviously if 1
MB is not enough now, we have the reasonable suspicion that 20 MB could
not be enough in few years.
What is the explanation that 20 MB blocks will be sufficient for life
time? Is it because 'probably other solutions will appear, such as
micropayment channels and offchain transactions'? If this is the case,
those can easily function with 1 MB blocks as well, and we should see
those in action sooner rather than later.
I run multiple full nodes, including one with Bitcoin XT and I don't
want to see Bitcoin XT and Bitcoin Core divide into different consensus
and create 2 altcoins instead of one Bitcoin.
On 5/31/2015 3:29 AM, Matt Whitlock wrote:
> Greg, Pieter, Jeff, and Wladimir,
>
> I'll try to be brief to respect your time.
>
> 1. I don't want to see Bitcoin die.
>
> 2. As has been discussed on this list and elsewhere: Bitcoin could potentially die due to economic and/or game-theoretic complications arising from raising the block size limit, but Bitcoin could also die due to usability complications arising from NOT raising the block size limit. Strong, personally held opinions by various members of this community notwithstanding, it is not clear which of these scenarios is more likely.
>
> 3. What *is* clear at this point is that Gavin will move ahead with his proposal, regardless of whether the remainder of the Bitcoin Core committers agree with him. If he has to commit his changes to Bitcoin XT and then rally the miners to switch, then that's what he'll do. He believes that he is working in the best interests of Bitcoin (as I would hope we all do), and so I do not fault him for his intentions. However, I think his proposal is too risky.
>
> 4. I also think that ignoring the immediate problem is too risky. If allowing significantly larger blocks will cause a serious problem for Bitcoin (which is a possibility that we cannot rule out, as we lack omniscience), then NOT making any change to Bitcoin Core will virtually *assure* that we cause exactly this problem, as the popular (non-technical) consensus appears to be in favor of Bitcoin XT and a larger block size limit. If we do nothing, then there's a very real chance that Bitcoin XT takes over, for better or worse.
>
> 5. I'd like to propose a way that we can have our cake and eat it too. My proposal attempts to satisfy both those who want larger blocks AND those who want to be extremely cautious about changing the fundamental economic parameters of Bitcoin.
>
> 6. Something I've never understood about Gavin's (et al.) proposal is why there is a massive step right up front. Assuming we accept his argument that we're critically close to running out of capacity, I still must ask: why do we need a 20x increase all at once?
>
> 7. It's not a given that blocks will immediately expand to meet the hard limit. In fact, there are strong and compelling arguments why this will NOT happen. But in any software system, if a given scenario is *possible*, then one MUST assume that it will happen and must have a plan to handle it.
>
> 8. My primary objection is not to raising the block size limit; my objection is to raising it *suddenly*. You can argue that, because we'll have plenty of time before March 2016, it's not "sudden," but, whether we do it now or a year from now or a decade from now, a step function is, by definition, sudden.
>
> 9. My proposal is that we raise the block size limit *gradually*, using an approximately smooth function, without a step discontinuity. We can employ a linear growth function to adjust the block size limit *smoothly* from 1 MB to 20 MB over the course of several years, beginning next March.
>
> 10. This is the difference between cannonballing into the deep end of the pool and walking gingerly down the steps into the shallow end. Both get you to the eventual goal, but one is reckless while the other is measured and deliberate. If there's a problem that larger blocks will enable, then I'd prefer to see the problem crop up gradually rather than all at once. If it's gradual, then we'll have time to discuss and fix it without panicking.
>
> 11. I am offering to implement this proposal and submit a pull request to Bitcoin Core. However, if another dev who is more familiar with the internals would like to step forward, then that would be superior.
>
> Respectfully submitted,
> Matt Whitlock
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:35:51

- reply

📅 Original date posted:2015-05-28
📝 Original message:On 5/28/2015 4:35 PM, Tier Nolan wrote:
> On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete at petertodd.org
> <mailto: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.
>
Indeed. This is very important for refunds.
> 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).
>
In this scenario, if channel is closed, Alice is the only one who can
take the coins back after a relative locktime of 150 blocks. Bob is not
able to do this.
> 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.
>
How is Bob protected in this scenario? If Alice sings a transaction
which spends the output of the refund transaction and gives it to Bob,
Bob can just add its signature and claim his slice of the output,
without necessarily shipping the goods or delivering the services to Alice.
> 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.
>
Can you be more explicit here? It doesn't make sense for me.
> 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.
>
With some risks.
> TXA could be protected against malleability by adding a locktime path.
> This would only be for use if the transaction is mutated.
>
How do you apply a locktime path to a tx in the current network consensus?
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:35:13

- reply

📅 Original date posted:2015-05-15
📝 Original message:Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
b) replays
If you strip just the scriptSig of the input(s), the txid(s) can still
be mutated (with higher probability before it gets confirmed).
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. This could
work if we were using only one scriptPubKey per tx. But this is not
enforced, and I don't think it's the proper way to do it.
Something similar can be achieved if you would use a combination of
flags from here:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
But this has some issues too.
I've read your draft but didn't understand how exactly will this prevent
normal malleability as we know it, second level malleability and replays
as well as how will we do the transition into mapping the txes in the
blockchain to normalized txids. Looking forward to read more on this
topic. Thanks for the brainstorming ;)
On 5/13/2015 3:48 PM, Christian Decker wrote:
> Hi All,
>
> I'd like to propose a BIP to normalize transaction IDs in order to
> address transaction malleability and facilitate higher level protocols.
>
> The normalized transaction ID is an alias used in parallel to the
> current (legacy) transaction IDs to address outputs in transactions. It
> is calculated by removing (zeroing) the scriptSig before computing the
> hash, which ensures that only data whose integrity is also guaranteed by
> the signatures influences the hash. Thus if anything causes the
> normalized ID to change it automatically invalidates the signature. When
> validating a client supporting this BIP would use both the normalized tx
> ID as well as the legacy tx ID when validating transactions.
>
> The detailed writeup can be found
> here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
>
> @gmaxwell: I'd like to request a BIP number, unless there is something
> really wrong with the proposal.
>
> In addition to being a simple alternative that solves transaction
> malleability it also hugely simplifies higher level protocols. We can
> now use template transactions upon which sequences of transactions can
> be built before signing them.
>
> I hesitated quite a while to propose it since it does require a hardfork
> (old clients would not find the prevTx identified by the normalized
> transaction ID and deem the spending transaction invalid), but it seems
> that hardforks are no longer the dreaded boogeyman nobody talks about.
> I left out the details of how the hardfork is to be done, as it does not
> really matter and we may have a good mechanism to apply a bunch of
> hardforks concurrently in the future.
>
> I'm sure it'll take time to implement and upgrade, but I think it would
> be a nice addition to the functionality and would solve a long standing
> problem :-)
>
> Please let me know what you think, the proposal is definitely not set in
> stone at this point and I'm sure we can improve it further.
>
> Regards,
> Christian
>
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 15:34:35

- reply

📅 Original date posted:2015-05-27
📝 Original message:Hi Peter,
Thanks for your reply.
I know and bookmarked your branch - nice work.
So, to clarify:
- bitcoin core (official / default) 0.10.x currently has First-seen
mempool behavior
- your custom branch uses replace by fee mempool behavior which allows
an user to change anything in a tx (I guess it needs just to have at
least one same input, so it can link it to another previously signed tx
with lower fee and substitute it in the mempool, correct?).
- First Seen Safe Replace by Fee (FSF-RBF) mempool behavior which allows
an user only to add inputs and/or increase the value of outputs will be
in yet another branch, maintained by you, but not in default / official
bitcoin core?
Another thing, if FSF-RBF lets you change TXes in the manner described
above, how does the client know which tx needs to be replaced in the
mempool? Since the txid naturally changes. How does it map tx1 with tx2
(to know tx2 has a higher fee and needs to substitute tx1) if quite a
lot of params from the transaction structure can change?
Thanks!
On 5/27/2015 4:25 AM, Peter Todd wrote:
> On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote:
>> What is wrong with the man testing some ideas on his custom branch? This
>> is how improvements come to life. I saw in the BIPs some really
>> interesting ideas and nice brainstorming which came from Peter Todd.
>>
>> Now, my question, if replace by fee doesn't allow me to change the
>> inputs or the outputs, I can only add outputs... what can I do with this
>> feature? If I sent a tx and want to replace it with a higher fee one,
>> the higher fee one can only have maybe additional change addresses or
>> another payment, if the inputs suffice? Do we have any real use cases?
>
> You're a bit mistaken there: standard RBF lets you change anything, and
> FSS RBF lets you modify inputs and add outputs and/or make the value of
> outputs higher.
>
>> P.S. is it planned to include this by default in bitcoin core 10.0.3 or
>> it will remain just on Peter's branch?
>
> Any significant change to mempool policy like RBF is very unlikely to be
> incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be
> too large a change for a minor, mostly bugfix, release.
>
> Having said that, I already maintain a standard RBF branch for v0.10.x,
> and have been asked by a major minor to backport FSS RBF for v0.10.x as
> well.
>

2023-06-07 15:34:34

- reply

📅 Original date posted:2015-05-26
📝 Original message:What is wrong with the man testing some ideas on his custom branch? This
is how improvements come to life. I saw in the BIPs some really
interesting ideas and nice brainstorming which came from Peter Todd.
Now, my question, if replace by fee doesn't allow me to change the
inputs or the outputs, I can only add outputs... what can I do with this
feature? If I sent a tx and want to replace it with a higher fee one,
the higher fee one can only have maybe additional change addresses or
another payment, if the inputs suffice? Do we have any real use cases?
P.S. is it planned to include this by default in bitcoin core 10.0.3 or
it will remain just on Peter's branch?
On 5/26/2015 11:30 PM, joliver at airmail.cc wrote:
> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
>
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
>
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
>
> On 2015-05-26 00:10, Peter Todd wrote:
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>>> CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> ----------------------------------------------------------
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in
>> size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the
>> new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> ------------------------------------------------
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260
>> bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> ----------------------------------------------------------------
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> ----------------------------
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined
>> total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>> costs you more than you save
>>
>> ------------------------------------------------------------------------------
>> 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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:32:32

- reply

📅 Original date posted:2015-04-25
📝 Original message:Thank you all for your comments. The youtube video was indeed very
educative and nice to watch.
It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying solely
on its txid.
BIP62 is good for preventing 3rd parties (non signers) to mutate txids,
but cannot do anything against 2nd parties (signers). I think we can
solve both by using NORMALIZEDTXID - wouldn't this be simpler and easier
to implement? Why are we talking about P3SH when we can just upgrade
P2SH to support additional OP codes? I saw that there have been talks
about a hard fork for increasing the block size, might as well take the
opportunity and fix this for good, by implementing BIP62, NORMALIZEDTXID
as well as BIP65. Couldn't all these be part of P2SH?
On 4/25/2015 6:40 PM, Stephen Morse wrote:
> Hi Gregory,
>
> In particular not covering the ID allows for transaction replay which
> can result in monetary losses far more severe than any possible
> mishandling of malleability could result in. Byzantine attackers can
> costlessly replay your old transactions any time anyone reuses an
> address, even accidentally (which cannot be easily prevented since
> they can race).
>
>
> With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
> specify that they are to be signed without the previous UTXO's
> value/amount. This means that, at worst, replay attacks can send the
> money to the same place it was sent before (which in many cases is
> likely not be a loss of funds), and only if the amount sent to the
> reused address is the exact same as it was before. I don't think this is
> worse than an attacker being able to mutate their transaction and extort
> a merchant who accepts zero-conf transactions. Anyway, not signing the
> input ID wouldn't exactly be the norm, there would be a defined set of
> flags for standard use cases. Not signing the input TXID would only be
> used in specialized cases, such as setting up micropayment channels.
>
>
> There are no free lunches; the proposal linked to there is itself a
> game of wack-a-mole with assorted masking flags;
>
>
> I agree that it is also a bit of wac-a-mole, but the defined space of
> issues is possibly more limited here. There are only X number of things
> that can be signed/not signed in a transaction, and the 'Build your own
> nHashType' proposal enables you to fully specify which of those are
> being signed. If you don't want to get burned by not fully signing your
> transactions, then don't use the non-standard sighash flags.
>
> many of which we have
> no notion of if they're useful for any particular application(s);
>
>
> A few of the flags, indeed, may not ever be useful. But we can't predict
> the future, and I think it's better to build in a more flexible solution
> now than to wish we had more flexible nHashTypes later.
>
> To the original point of this thread, hopefully the suggested proposal
> won't be necessary as wallets will upgrade to use version 3 transactions
> and the rules associated with them over time.
>
> Best,
> Stephen
>
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 15:32:31

- reply

📅 Original date posted:2015-04-18
📝 Original message:Understood. That is unfortunate, but not the end of the world. If you
could please give feedback also to these last comments / questions:
How far are we at this moment from BIP62? Can an user send a
non-malleable tx now, if enforces some additional rules?
As for the security of the system, it does not fully rely on txids being
non malleable, but see this quote from my previous email:
[QUOTE]
I am trying to build a bitcoin contract which will relay on 3 things:
- coinjoin / txes with inputs from multiple users which are signed by
all users after they are merged together (every user is sure his coins
will not be spent without the other users to spend anything, as per
agreed contract);
- pre-signed txes with nLockTime 'n' weeks. These txes will be signed
before the inputs being spent are broadcasted/confirmed, using the txid
provided by the user before broadcasting it. Malleability hurts here.
- P2SH
Another thing I would like to confirm, the 3 pieces of the bitcoin
protocol mentioned above will be supported in _any_ future transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...
[/END QUOTE]
Can you comment on the quote please?
So, basically transaction malleability could affect the system in the
way that a pre-signed tx which offers the insurance and which is sent to
the user before the user sends the coins (spending user's coins back to
him after a certain period of time) could be invalidated. The insurance
tx signature will still be good, but invalid overall since the input
(txid) being spent does not exist (was altered / modified). The coins
won't be stolen or lost, but a new tx needs to be signed with the
altered (new) txid, for the system to work.
So, an user creates a transaction TX1 sending the coins to the server
but does not broadcast it. Instead, he provides the txid of TX1 to the
server. Server generates another transaction TX2 which spends TX1 back
to the user, with an nLockTime. User checks and if everything ok
broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2
will become invalid (since it will be spending an inexistent input), and
the server will need to re-create and sign TX2 with the new
(altered/modified) txid of TX1, as per agreed contract. Should the
server disappear after user broadcasts TX1 and before the
altered/modified txid of TX1 gets confirmed, user's coins are forever
locked. It is true that no third party can benefit from this type of
attack, only the user will result with coins locked, but it is something
which could be used by competition to make a service useless / annoying
/ too complicated or less safe to use.
How could I mitigate this?
Thanks you for your time and help.
On 4/17/2015 12:02 PM, Pieter Wuille wrote:
>> Anyone can alter the txid - more details needed. The number of altered
>> txids in practice is not so high in order to make us believe anyone can
>> do it easily. It is obvious that all current bitcoin transactions are
>> malleable, but not by anyone and not that easy. At least I like to
> think so.
>
> Don't assume that because it does not (frequently) happen, that it
> cannot happen. Large amounts of malleated transactions have happened in
> the past. Especially if you build a system depends on non-malleability
> for its security, you may at some point have an attacker who has
> financial gain from malleation.
>
>> >From your answer I understand that right now if I create a transaction
>> (tx1) and broadcast it, you can alter its txid at your will, without any
>> mining power and/or access to my private keys so I would end up not
>> recognizing my own transaction and probably my change too (if my systems
>> rely hardly on txid)?
>
> In theory, yes, anyone can alter the txid without invalidating it,
> without mining power and without access to the sender's private keys.
>
> All it requires is seeing a transaction on the network, doing a trivial
> modification to it, and rebroadcasting it quickly. If the modifies
> version gets mined, you're out of luck. Having mining power helps of course.
>
> After BIP62, you will, as a sender, optionally be able to protect others
> from malleating. You're always able to re-sign yourself.
>
> --
> Pieter
>

2023-06-07 15:32:30

- reply

📅 Original date posted:2015-04-16
📝 Original message:On 4/16/2015 8:34 PM, Mark Friedenbach wrote:
> At this moment anyone can alter the txid. Assume transactions are 100%
> malleable.
>
Anyone can alter the txid - more details needed. The number of altered
txids in practice is not so high in order to make us believe anyone can
do it easily. It is obvious that all current bitcoin transactions are
malleable, but not by anyone and not that easy. At least I like to think so.
>From your answer I understand that right now if I create a transaction
(tx1) and broadcast it, you can alter its txid at your will, without any
mining power and/or access to my private keys so I would end up not
recognizing my own transaction and probably my change too (if my systems
rely hardly on txid)?
> On Apr 16, 2015 9:13 AM, "s7r" <s7r at sky-ip.org <mailto:s7r at sky-ip.org>>
> wrote:
>
> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate
> things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" <s7r at sky-ip.org
> <mailto:s7r at sky-ip.org> <mailto:s7r at sky-ip.org <mailto:s7r at sky-ip.org>>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from
> all the
> >> transactions in the latest 1000 blocks are version 'n' mark all
> previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not
> make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet
> software to
> > be changed.
> >
> > --
> > Pieter
> >
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:32:30

- reply

📅 Original date posted:2015-04-16
📝 Original message:Hi Pieter,
Thanks for your reply. I agree. Allen has a good point in the previous
email too, so the suggestion might not fix anything and complicate things.
The problem I am trying to solve is making all transactions
non-malleable by default. I guess there is a very good reason why BIP62
will not touch v1 anyway.
I am trying to build a bitcoin contract which will relay on 3 things:
- coinjoin / txes with inputs from multiple users which are signed by
all users after they are merged together (every user is sure his coins
will not be spent without the other users to spend anything, as per
agreed contract);
- pre-signed txes with nLockTime 'n' weeks. These txes will be signed
before the inputs being spent are broadcasted/confirmed, using the txid
provided by the user before broadcasting it. Malleability hurts here.
- P2SH
In simple terms, how malleable transactions really are in the network at
this moment? Who can alter a txid without invalidating the tx? Just the
parties who sign it? The miners? Anyone in the network? This is a little
bit unclear to me.
Another thing I would like to confirm, the 3 pieces of the bitcoin
protocol mentioned above will be supported in _any_ future transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...
On 4/16/2015 8:22 AM, Pieter Wuille wrote:
>
> On Apr 16, 2015 1:46 AM, "s7r" <s7r at sky-ip.org <mailto:s7r at sky-ip.org>>
> wrote:
>> but for transaction versions? In simple terms, if > 75% from all the
>> transactions in the latest 1000 blocks are version 'n', mark all
>> previous transaction versions as non-standard and if > 95% from all the
>> transactions in the latest 1000 blocks are version 'n' mark all previous
>> transaction versions as invalid.
>
> What problem are you trying to solve?
>
> The reason why BIP62 (as specified, it is just a draft) does not make v1
> transactions invalid is because it is opt-in. The creator of a
> transaction needs to agree to protect it from malleability, and this
> subjects him to extra rules in the creation.
>
> Forcing v3 transactions would require every piece of wallet software to
> be changed.
>
> --
> Pieter
>

2023-06-07 15:32:29

- reply

📅 Original date posted:2015-04-15
📝 Original message:Hi,
Would it be wise to add a consensus rule like the one we have for blocks,
(if > 75% from last 1000 blocks are version 'n' mark version 'n' as
standard for blocks and if > 95% from the last 1000 blocks are version
'n' mark previous block versions as invalid)
but for transaction versions? In simple terms, if > 75% from all the
transactions in the latest 1000 blocks are version 'n', mark all
previous transaction versions as non-standard and if > 95% from all the
transactions in the latest 1000 blocks are version 'n' mark all previous
transaction versions as invalid.
At this moment, the standard in consensus is v1, but nothing is enforced
in the network related to transaction versions.
Regarding BIP62, as it can be read here [0] it is said that it requires
v2 transactions. It is also said that transaction version 2 will be
skipped and jump directly to v3, for an even version for transactions
and blocks (?). Might as well add the rule for invalidating previous
transaction versions if the majority updates - could this break anything
or affect functionality in any way?
BIP62 adds a newer transaction version which is optional and does not
mark previous v1 as non-standard or invalid. This means bitcoin core
will treat both v1 and v2/v3 transactions as standard and relay/mine
them with the same priority, regardless of the tx version?
Thanks.
[0]
https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented

2023-06-07 15:32:15

- reply

📅 Original date posted:2015-03-26
📝 Original message:This should not be enforced by default. There are some use cases where
address re-use is justified (a donation address spread on multiple
static pages or even printed on papers/books?). For example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations which is posted everywhere. Obviously this could
possibly harm privacy, but not everyone who uses bitcoin wants to keep
all transactions private. To the contrary, there are accounting cases
when you need to archive all keys, hashes of transactions and
everything (for example when using btc inside a company which is
required by law to keep accounting registries).
I know it's not recommended to use the same pubkey more than once, but
the protocol was not designed this way. Enforcing something as
described in this topic will undermine an user's rights to re-use his
addresses, if a certain situation requires it.
On 3/26/2015 11:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh at thinlink.com>
> wrote:
>> I should have been clearer that the motivation for address
>> expiration is to reduce the rate of increase of the massive pile
>> of bitcoin addresses out there which have to be monitored
>> forever for future payments. It could make a significant dent
>> if something like this worked, and were used by default someday.
>
> Great, that can be accomplished by simply encoding an expiration
> into the address people are using and specifying that clients
> enforce it.
>
> ----------------------------------------------------------------------
--------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:25:59

- reply

📅 Original date posted:2014-09-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/26/2014 5:16 AM, Matt Whitlock wrote:
> Probably the first double-spend attempt (i.e., the second
> transaction to spend the same output(s) as another tx already in
> the mempool) would still need to be relayed. A simple
> "double-spend alert" wouldn't work because it could be forged. But
> after there have been two attempts to spend the same output, no
> further transactions spending that same output should be relayed,
> in order to prevent flooding the network.
>
This sounds rational - is this already implemented nowadays or *SHOULD
BE* implemented to prevent this attack type in the future?
>
> On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote:
>> Something like that would be a great help for SPV clients that
>> can't detect double spends on their own. (still limited of
>> course to sybil attack concerns)
>>
>> Aaron Voisine breadwallet.com
>>
>>
>> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock
>> <bip at mattwhitlock.name> wrote:
>>> What's to stop an attacker from broadcasting millions of
>>> spends of the same output(s) and overwhelming nodes with
>>> slower connections? Might it be a better strategy not to relay
>>> the actual transactions (after the first) but rather only
>>> propagate (once) some kind of double-spend alert?
>>>
>>>
>>> On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine
>>> wrote:
>>>> There was some discussion of having nodes relay
>>>> double-spends in order to alert the network about double
>>>> spend attempts.
>>>>
>>>> A lot more users will be using SPV wallets in the future,
>>>> and one of the techniques SPV clients use to judge how likely
>>>> a transaction is to be confirmed is if it propagates across
>>>> the network. I wonder if and when double-spend relaying is
>>>> introduced, if nodes should also send BIP61 reject messages
>>>> or something along those lines to indicate which
>>>> transactions those nodes believe to be invalid, but are
>>>> relaying anyway.
>>>>
>>>> This would be subject to sybil attacks, as is monitoring
>>>> propagation, however it does still increase the cost of
>>>> performing a 0 confirmation double spend attack on an SPV
>>>> client above just relaying double-spends without indicating
>>>> if a node believes the transaction to be valid.
>>>>
>>>> Aaron Voisine breadwallet.com
>>>
>
> ------------------------------------------------------------------------------
>
>
>
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
> EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUJZPVAAoJEIN/pSyBJlsRfgoIAI4x4qITdCDyYx/I1+z4eGz3
u7zDbVGQEPsUlrgEZLf503TNUIKmEgYQvgQDGEdOQk615XlkrTJeqt5oLh9DVJKj
TaXRqKgBp4iNd6BIIs1gKl0CzmH9sJ7U9ojhTS5aV7ZUhinO0WZlgISYaBZ3t9Kw
t//jb8QNLqISOeotiO9A2jb06UVRf9Gh0FUSBYTJ/st0UvLWt286zT+4XOaeVI/c
9I9nkTsd/jdw1Eorfcd5T8iHBORcdn9g+5+UpuXVq7d3KA5FA6oetzBVHgUfTMjF
q9LAe0W9IUVSiRj+wWvADzlxeUwWjsHnJDxdGihBg/g+k6SfPnOAxEC1UjCH+OU=
=kaIX
-----END PGP SIGNATURE-----

2023-06-07 15:24:32

- reply

📅 Original date posted:2014-07-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 7/28/2014 6:44 AM, Gregory Maxwell wrote:
> On Sun, Jul 27, 2014 at 7:54 PM, mbde at bitwatch.co
> <mbde at bitwatch.co> wrote:
>> These website list Tor nodes by bandwidth:
>>
>> http://torstatus.blutmagie.de/index.php
>> https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc
>>
>> And the details reveal it's a port 8333 only exit node:
>> http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124
>
>>
> As I pointed out above, — it isn't really. Without the exit flag,
> I believe no tor node will select it to exit 8333 unless manually
> configured. (someone following tor more closely than I could
> correct if I'm wrong here)
>
>
>> blockchain.info has some records about the related IP going back
>> to the end of this May:
>>
>> https://blockchain.info/ip-address/5.9.93.101?offset=300
>
> dsnrk and mr_burdell on freenode show that the bitnodes crawler
> showed it accepting _inbound_ bitcoin connections 2-3 weeks ago,
> though it doesn't now.
>
> Fits a pattern of someone running a bitcoin node widely connecting
> to everyone it can on IPv4 in order to try to deanonymize people,
> and also running a tor exit (and locally intercepting 8333 there),
> but I suspect the tor exit part is not actually working— though
> they're trying to get it working by accepting huge amounts of relay
> bandwidth.
>
> I'm trying to manually exit through it so I can see if its
> intercepting the connections, but I seem to not be able.
>
> Some other data from the hosts its connecting out to proves that
> its lying about what software its running (I'm hesitant to just say
> how I can be sure of that, since doing so just tells someone how to
> do a more faithful emulation; so that that for whatever its
> worth).
>
> ------------------------------------------------------------------------------
>
>
Infragistics Professional
> Build stunning WinForms apps today! Reboot your WinForms
> applications with our WinForms controls. Build a bridge from your
> legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>
_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
The thing is, if it doesn't have the exit flag it cannot generate lots
of traffic from real good-intended clients, because it's quite hard
for clients to choose this Node as ËXIT in their path if it doesn't
have the exit flag. So the traffic comes from clients who specifically
added "ExitNode <fingerprint>" in their torrc and only use that Tor
instance for Bitcoin. So, someone build this custom Tor node for
themselves only, for plausible den. A pool could be the cause as it
was earlier discussed here...
The thing is I cannot find this node on atlas, globe or blutmagie can
you please provide fingerprint and IP address again? So I may ignore
it on my relays and talk to some people about it?
- --
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJT1jXjAAoJEIN/pSyBJlsRjqgIAIFxHcypU6KUaNdSvESADilM
kFiitf00f4Uy9tBwSLVPQw+I2L1EmMiCNvqG4RRjV2+/PS696HCz0Jt0gVaGlMPl
DHQSHsozx3BaXi5PpGeLl7uSNLHlEdytytZ8xb08I4IuqcNNHzvxnou7gXapeezC
PuSABsxVLpDn+OP7QLRy/PlL948Yfgbxwb9dcn+lUdgDlByxxhMmOrk+o/VdGfnh
cL/C+qgpuJiI/wrQridtBmxU8h7Z6TKKua7eWONyg6MrnjwWuZTumhAGO2H4X1Na
IZiCmhEwtxb97TMG0EvgcZTeRzfzoddTnOe6ZEsiqOZ7qPNjFJ2i8RoSOI3gUCQ=
=t3Mb
-----END PGP SIGNATURE-----

2023-06-07 15:24:32

- reply

📅 Original date posted:2014-07-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 7/28/2014 5:08 PM, Gregory Maxwell wrote:
> On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay <robert at mckay.com>
> wrote:
>> I don't think Sybil attack is the right term for this.. there is
>> only one IP address.. one "identity".
>
> The bitcoin protocol is more or less identityless. It's using up
> lots of network capacity, "number of sockets" is as pretty close as
> you get.
>
>> I'm not even sure that this behaviour can be considered abuse..
>> it's pretty much following the rules and maybe even improving the
>> transaction and block propagation.
>
> It isn't relaying transactions or blocks as far as anyone with a
> connection to it can tell.
>
> and sure, probably not much to worry about— people have been
> running spy nodes for a long time, at least that much is not new.
>
> ------------------------------------------------------------------------------
>
>
Infragistics Professional
> Build stunning WinForms apps today! Reboot your WinForms
> applications with our WinForms controls. Build a bridge from your
> legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>
_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
gmaxwell - I wanted to ask you a non-expert question. Let's say I use
my bitcoin-qt on my laptop with Tor, and send some BTC or receive
some, what can my Tor exit node see / do / harm? He can alter the
content, by modifying and transmitting invalid transactions to the
network but this will have no effect on me, e.g. can't steal coins or
send them on my behalf or intercept my payments, right? It's not clear
for me what data would such a node see? Why would you spend money to
setup a spy node for this what relevant data can it give you?
- --
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJT1nafAAoJEIN/pSyBJlsR8GYIAL9LkZvPbKjJ6cUxlC4yRKay
YUumAafCKYMvp8Ywvz3CWpC4Gncn+v29hhJu/Nc0wSItAnf4suwrAFtBAwAYlUx8
a1J6S1hgGXCBWDZcGHDc1Xt2lLzvijDcilSZfQWXnAdoEaZyln/7Kn+o/fFcXG6h
DUkSCSe9M3tN/tZBcZrhBXTENhoJ6MZldcgey6Ky0qLkmI3GCd0MhM+D15xl1LkT
6IS2r2y0RUOxkbg/SuSzFS8vnNTTWmZpbECo3Qq98W41X0M3ZtjOlaByPZXFX5K9
+HUeiptV9zukSdIRcuGH1PUQvU9nk+G1rFKr0dXu4oPvAUxqyw9uCTFgHXczuQY=
=gw3W
-----END PGP SIGNATURE-----