<unnamed>

Public Key

npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h

Profile Code

nprofile1qqsfg724xqdgspg9fjxk5ty6c24lq7n6rr62xwc22uazw7rgxq548vgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqdmsjtk

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-08 00:57:38 CEST

- 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 19:54:51 CEST

- 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 19:54:48 CEST

- 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 19:54:46 CEST

- 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 19:52:12 CEST

- 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 19:51:24 CEST

- 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 19:46:17 CEST

- 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 19:43:41 CEST

- 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 19:42:43 CEST

- 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 19:41:27 CEST

- 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 19:40:35 CEST

- 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 19:38:16 CEST

- 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 19:38:15 CEST

- 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 19:35:34 CEST

- 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 19:35:31 CEST

- 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 19:35:12 CEST

- 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 19:35:12 CEST

- 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:47:19 CEST

- reply

2023-06-07 17:47:17 CEST

- reply

2023-06-07 17:47:03 CEST

- reply

2023-06-07 17:47:03 CEST

- reply

2023-06-07 17:44:06 CEST

- 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 17:40:13 CEST

- 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 17:40:12 CEST

- 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 17:39:32 CEST

- 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 17:39:29 CEST

- 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 17:34:34 CEST

- 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 17:32:32 CEST

- 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 17:32:30 CEST

- 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 17:32:30 CEST

- 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 17:32:15 CEST

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