<unnamed>

Public Key

npub13f3qkf0gj3zwnypll339zsjsjsw2xxxnm5m3xzyzrdxtuvxafq4qmv7cz5

Profile Code

nprofile1qqsg5cstyh5fg38fjqllccj3gfgfg89rrrfa6dcnpzppkn97xrw5s2spzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvz5dwn7

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:44:18 UTC

- reply

📅 Original date posted:2015-11-10
📝 Original message:OP_0 gives a zero length byte array because OP_0 == 0x00 which is equivalent to pushdata with zero length.
OP_EQUAL compares byte strings as-is. So it will push "false" because empty string is not the same as a single-byte string with 0x00 byte in it. Value "false" in turn is encoded as empty string, just like result of OP_0.
> On 06 Nov 2015, at 10:37, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I meant not to use the OP_PUSH opcodes to do the push.
>
> Does OP_0 give a zero length byte array?
>
> Would this script return true?
>
> OP_0
> OP_PUSHDATA1 (length = 1, data = 0)
> OP_EQUAL
>
> The easiest definition is that OP_0 and OP_1 must be used to push the data and not any other push opcodes.
>
>
> On Fri, Nov 6, 2015 at 9:32 AM, Oleg Andreev <oleganza at gmail.com <mailto:oleganza at gmail.com>> wrote:
>
> > One and zero should be defined as arrays of length one. Otherwise, it is still possible to mutate the transaction by changing the length of the array.
> >
> > They should also be minimally encoded but that is covered by previous rules.
>
> These two lines contradict each other. Minimally-encoded "zero" is an array of length zero, not one. I'd suggest defining this explicitly here as "IF/NOTIF argument must be either zero-length array or a single byte 0x01".
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/8c16a920/attachment.html>

2023-06-07 17:44:17 UTC

- reply

📅 Original date posted:2015-11-06
📝 Original message:> One and zero should be defined as arrays of length one. Otherwise, it is still possible to mutate the transaction by changing the length of the array.
>
> They should also be minimally encoded but that is covered by previous rules.
These two lines contradict each other. Minimally-encoded "zero" is an array of length zero, not one. I'd suggest defining this explicitly here as "IF/NOTIF argument must be either zero-length array or a single byte 0x01".

2023-06-07 15:44:11 UTC

- reply

📅 Original date posted:2015-07-31
📝 Original message:> On 31 Jul 2015, at 11:56, Thomas Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Friday 31. July 2015 03.21.07 Jorge Timón via bitcoin-dev wrote:
>> If I was a miner and you want me to include your transaction for free,
>> you're asking me to give you money
>
> What?
>
> Ask yourself; why do miners include transactions at all? What it the incentive
> if there really is only less than 0.8% of income to be derived from fees?
>
> Miners don't get payed by fees. They won't need to get payed by fees for
> decades to come. Maybe you want to re-do your math, it seems off.
Fees should be compared not with the total revenue, but with the profit margin. If a miner invested/spends 24 BTC per block and earns 0.25 in fees, then his total profit is 1.25 BTC per block and fees comprise a whopping 20% of the profit.
Today I think profit margins are quite high, so fees do not matter much. But it's not hard to imagine that in just a couple of years BTC may appreciate a lot more, attract more investors and even bigger foundries to, say, print chips and mine right at the foundry, thus driving profit margins lower. Fees will begin to matter regardless of the total subsidy.
Just some hypothetical calculation.
Lets say in 2015 one block costs 5 BTC and fees bring 0.25 BTC. Profit is thus 20.25 BTC and fees comprise 1.2% of that amount.
Lets say in late 2016 halving happens, BTC appreciates and resulting competition drives up the cost to 6 BTC (yes, BTC itself is more expensive, but so is the profit too, so increased competition must drive down the profit margin). Now the block brings 6.75 BTC in profit. Fees, if unchanged now make 4% of the total profit.
If all goes well, in mid 2020 another halving happens (6.25 BTC/block) and even if the BTC-denominated cost stays the same miner now will earn 0.25 BTC profit from subsidy and fees now can account for 100% of that amount.
Of course it's a very rough estimate and most likely to be far from reality, but it shows how fees can begin to matter rather quickly under pressure of separate factors: halving and growing valuation and mining competition.

2023-06-07 15:30:14 UTC

- reply

📅 Original date posted:2015-02-12
📝 Original message:> I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can "get away" with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients.
>
> Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer.
Here's value-free assessment of the issue here:
1. Zero-conf txs are unsafe.
2. We'd all want to have a safer instant payments solution if possible.
3. As a social artifact, today zeroconf txs happen to work for some people in some situations.
4. Replace-by-fee will break #3 and probably hasten development of #2.
The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner.
I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons).
TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/6fddaefd/attachment.html>

2023-06-07 15:30:11 UTC

- reply

📅 Original date posted:2015-02-12
📝 Original message:> On 12 Feb 2015, at 13:49, Mike Hearn <mike at plan99.net> wrote:
> If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks.
How about a Ripple-like IOU-based payment network that is 100% decentralized, for "dumb and daily" payments only? IOUs will propagate from node to node and will trusted because of a "joint escrow" transaction between each pair of nodes (locking up certain amount on both ends in 2-of-2 multisig). Total amount of debt from one node to another will be limited to 50% of the locked amount (e.g. if both nodes lock up $20 each, they allow debt up to $10 in each direction). When debt is reaching its limit, it's being "cleared" by debtor via a real BTC transaction or simply by "closing" the contract transaction with correct proportion on outputs to pay off the debt.
Every node may require an arbitrary fee for a service of providing his funds to back IOUs, when making a payment, merchant/customer may find several possible "paths" and choose the quickest/cheapest one to use. Centralization is possible at a proportional capital expense. If some node wants to be Visa-scale with millions of contracts and a lot of fees to earn, they'll have to lock up huge amount of money. This puts natural limit on centralization or associated risk.
Example:
I pay $10. The following path is discovered and signed off by the Merchant who accepts an ad-hoc 0.3% fee:
Me: $10 -> $9.99 (Alice) -> $9.98 (Bob) -> $9.97 (Merchant).
Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. Clearing of debts happens independently between each participant based on their debt-to-capital ratio and whether any party wishes to exit. Of course, if several paths are discovered within a reasonable timeframe, Merchant will choose the cheapest one. And maybe abort transaction if the proposed path is too expensive (e.g. total fee is >1%).
Pros:
- Decentralized.
- Mere seconds to settle a payment.
- Infinite scalability (no global consensus). Each payment involves 5-7 nodes only.
- No trusted parties or federation (trust is "purchased" using "joint escrow" txs on blockchain)
- No funny currency, IOUs denominated in BTC.
- No global consensus or protocol. Nodes can be semi-compatible, upgrade independently. All risks are local.
Political problems solved:
- No need to debate zeroconf transactions. We don't *need* them anymore to buy a coffee.
- No need to debate block size limit. It'd still be nice to raise it when needed, but for 99% of transactions we'll have a good decentralized solution off-chain, so the issue is less pressing.
Cons:
- Some amount of cash needs to be locked up with random nodes most of the time. If one of the nodes is offline, payments can't be cleared through that node. Although, it could not be a big problem as the network is useful for small-ish payments and every node will have 10-15 contracts, so it will tolerate occasional unavailability of some of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/4105f17b/attachment.html>

2023-06-07 15:30:01 UTC

- reply

📅 Original date posted:2015-02-10
📝 Original message:> Let's say you're visiting an international webshop. But they don't ship to your country. Wouldn't you want to know that before your start filling the cart? With this, your wallet / browser extension could tell you right away that you can't shop there. No time wasted!
Why my wallet has to do anything with me being in some country? The webshop may detect my location and tell me if they ship to where I'm currently in. Why should I associate more private information (my location) with my wallet than strictly necessary? Why should I automatically advertise my shipping address to every webshop without my explicit consent?
The wallet must be convenient only as much as it allows for better security and privacy, but not trading off security and privacy for some unrelated convenience.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/ef9b1d00/attachment.html>