npub1xv…c5rqg

Last Notes

2023-06-07 19:50:33 CEST

- reply

📅 Original date posted:2016-05-11
📝 Original message:And anyone who would have discovered it independently would have been free
to implement it. That's the issue, not that there's an optimization.
On Wed, May 11, 2016 at 9:27 PM, Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> >
> > If we change the protocol then the message to the ecosystem is that
> > ASIC optimizations should be kept secret.
>
> Further to that point, if THIS optimization had been kept secret, nobody
> would be talking about doing anything, as with countless other
> optimizations.
>
> _______________________________________________
> 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/20160511/e364cf71/attachment.html>

2023-06-07 19:46:59 CEST

- reply

📅 Original date posted:2015-12-29
📝 Original message:How could this possibly be enforced?
On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been no decent objections to altering the block-selection
> mechanism (when two block solutions appear at nearly the same time) as
> described at
>
> http://bitcoin.stackexchange.com/questions/39226
>
> Key components are:
>
> - Compute BitcoinDaysDestroyed using only transactions that have been
> in your mempool for some time as oBTCDD ("old BTCDD").
> - Use "nearly the same time" to mean separated in time by your guess
> of the average duration of block propagation times.
> - When two block solutions come in at nearly the same time, build on
> the one that has the most oBTCDD, rather than the one that came in first.
>
> The goal of this change is to reduce the profitability of withholding
> block solutions by severely reducing the chances that a block solved a
> while ago can orphan one solved recently. "Came in first" seems more
> easily gamed than "most oBTCDD". As I wrote there, "*old coins* is
> always a dwindling resource and *global nodes willing to help cheat* is
> probably a growing one."
>
> I will write a BIP if anyone agrees it's a good idea.
>
> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Far more concerning is network propagation effects between large and
>>> small miners. For that class of issues, if you are in an environemnt
>>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>>> attacked network topology - the profitability difference between small
>>> and large miners even *without* attacks going on is a hugely worrying
>>> problem. OTOH, if you're blocksize is small enough that propagation time
>>> is negligable to profitability, then selfish mining attacks with <30%
>>> hashing power aren't much of a concern - they'll be naturally defeated
>>> by anti-DoS/anti-sybil measures.
>>>
>>
>> Let's agree that one factor in mining profitability is bandwidth/network
>> reliability/stability. Why focus on that vs electricity contracts or
>> vertically integrated chip manufacturers? Surely, sufficient network
>> bandwidth is a more broadly available commodity than <$0.02/kwh
>> electricity, for example. I'm not sure that your stranded hydroelectric
>> miner is any more desirable than thousands of dorm room miners with access
>> to 10gbit university connections and free electricity.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> 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/20151229/01725358/attachment.html>

2023-06-07 17:34:31 CEST

- reply

📅 Original date posted:2015-05-26
📝 Original message:What prevents you from writing a bad check using today's systems?
On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe <danny.thorpe at gmail.com>
wrote:
> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd <pete at petertodd.org> 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
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/a7fd8020/attachment.html>

2023-06-07 17:30:18 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:You keep making moral judgements. Reality is, if you live in a world with
arsonists, you need to have a building that won't catch on fire, or has
fire extinguishers in place. Do not depend on arsonists ignoring you
forever as your security model. Penetration testing to know what
weaknesses exist, what limitations exist, and what can be improved is
essential. Keeping your head in the sand and hoping people choose to do
the right thing only ends one way.
On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier <justusranvier at riseup.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:47 PM, Allen Piscitello wrote:
> > Nothing will stop that. Bitcoin needs to deal with those issues,
> > not stick our heads in the sand and pretend they don't exist out of
> > benevolence. This isn't a pet solution, but the rules of the
> > protocol and what is realistically possible given the nature of
> > distributed consensus. Relying on altruism is a recipe for
> > failure.
>
> If there's a risk of fire burning down wooden buildings, pass out fire
> extinguishers and smoke detectors, not matches.
>
> The latter makes one an arsonist.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ
> tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+
> OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc
> p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT
> vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt
> z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU
> KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S
> J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N
> otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i
> Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y
> l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d
> cE68utrIaurfJsDA/L/+
> =pTe/
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/e021b0de/attachment.html>

2023-06-07 17:30:17 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:Nothing will stop that. Bitcoin needs to deal with those issues, not stick
our heads in the sand and pretend they don't exist out of benevolence.
This isn't a pet solution, but the rules of the protocol and what is
realistically possible given the nature of distributed consensus. Relying
on altruism is a recipe for failure.
On Thu, Feb 12, 2015 at 1:34 PM, Justus Ranvier <justusranvier at riseup.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:15 PM, Alan Reiner wrote:
> > I'll add fuel to the fire here, and express that I believe that
> > replace-by-fee is good in the long-term. Peter is not breaking
> > the zero-conf, it was already broken, and not admitting it creates
> > a false sense of security. I don't want to see systems that are
> > built on the assumption that zero-conf tx are safe solely because
> > it has always appeared safe. You can argue about rational miner
> > behaviors all day, but in a decentralized system you have no idea
> > what miners consider rational, or speculate about their incentives.
> >
> As noted elsewhere in the thread, there are two problems with this
> analysis:
>
> 1. It asserts that zero-confirmation transactions are in a binary
> state of safe/broken instead of recognizing that relying on them is a
> non-binary risk analysis on the part of a merchant.
>
> 2. Assumptions about what is profitable for miners are based on all
> miners having short time horizons for calculating profits.
>
> In addition, I'll add that there is an assumption that honest actors
> can not alter their behavior in response to changing conditions.
>
> Since scorched-earth solutions to problems are apparently acceptable
> now, what would stop more honest node operators from patching their
> nodes to blacklist any peer that relays replace-by-fee transactions,
> and maybe even publish an IP address list of those peers?
>
> Punishing Bitcoin users for not adopting somebody's pet solution to a
> problem neither responsible nor ethical.
>
> Child-pays-for-parent allows for stuck transactions to be cleared from
> the mempool, and allows recipients of zero-conf transactions to adjust
> their risk exposure as much or as little as they like.
>
> It's a solution that gives Bitcoin users more freedom, instead of
> trying to coerce them into pre-determined directions.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
> vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
> hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
> kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
> F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
> P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
> pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
> sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
> b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
> j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
> LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
> F9dKdL5zCGofvU/U5BVq
> =kEMr
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/62c08a8e/attachment.html>

2023-06-07 17:30:15 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:You cannot close Pandora's box. Whether or not this type of patch should
exist is irrelevant. It does, and there are incentives to use it by
miners. These are the bounds we have to deal with and the world we must
adapt to.
On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier <justusranvier at riseup.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 05:24 PM, Oleg Andreev wrote:
> >
> >> 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.
>
> You've left out of the discussion that many (or all) proposed
> solutions for 2 either reduce privacy, or security, or both.
>
> That fact should not be ignored or swept under the rug.
>
> There's also no mention of the degree to which child-pays-for-parent
> achieves the stated aims of the original proposal (clearing mempool of
> stuck transactions, increasing payee assurance of conformation)
> without introducing incentives to double spend or forcing people into
> privacy/security sacrifices.
>
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
> 6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
> HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
> bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
> 2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
> RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
> V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
> FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
> G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
> n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
> 7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
> XjbkwrkFIuKfUJyfIuR+
> =ony0
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/ef23fede/attachment.html>

2023-06-07 17:16:20 CEST

- reply

📅 Original date posted:2014-03-27
📝 Original message:The benefit I see is avoiding reuse of keys between coins while not having
each wallet implementation have to know about each coin in order to scan
for transactions. Wallet X supports Doge and Bitcoin. If both used a
shared sequence of keys, say the first two end up Bitcoin, then 10 Doge,
then some more Bitcoin. If you took this seed to Wallet Y, which only
supports Bitcoin (either the wallet's support or what is installed on the
system it's being used), it will see a gap of 10 addresses, and presume no
more scanning with a 5 gap limit. The alternative is to reuse keys for
each coin.
It also seems like a solution might be to only expect interoperability on a
single sequence, and provide backups of each final sequence to use between
different wallet implementations. This allows flexibility in hierarchies
depending on needs and support of wallet, but allows sharing. The short
seed would only be useful for the same wallet, but sharing between wallets
would use the longer keys. That will give predictable behavior for users
(although less friendly) and lead to less errors.
-Allen
On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/0e05360a/attachment.html>

2023-06-07 17:16:18 CEST

- reply

📅 Original date posted:2014-03-27
📝 Original message:Don't most of these coins have a magic number already assigned that is
unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
Litecoin, etc...). This seems like a good candidate for identifying coins,
and also supports Testnet cases well. Maybe there are some alts without
such a magic number that might prevent that?
-Allen
On Thu, Mar 27, 2014 at 10:43 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer <tamas at bitsofproof.com>
> wrote:
> > A notable suggestion was to instead of building a directory of magic
> numbers
> > (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word
> "Bitcoin",
> > "Litecoin", "Dogecoin", so collosion is unlikely and
> > cetral directory is not needed.
>
> +1 good idea
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/acb6e25e/attachment.html>

2023-06-07 17:16:15 CEST

- reply

📅 Original date posted:2014-03-26
📝 Original message:For every branch (say multiple accounts), how would a new wallet be able to
know how many sequence items to scan? It seems like not only do you need
to have standard rules for the hierarchy, but how the usage can be
detected. The other scanning seems pretty straightforward. For accounts,
it seems like you could have a situation where you want to initially set up
10 different accounts, but only account #10 gets any transactions. If a
new wallet was trying to scan with this seed, it would have to know to keep
scanning each account until it found the account. The user would have to
be responsible for knowing how many accounts there are, or some rules would
need to be in place to not allow creating accounts until earlier accounts
can be proven to have existed in the blockchain. Or I am missing something.
-Allen
On Wed, Mar 26, 2014 at 3:49 PM, Mike Hearn <mike at plan99.net> wrote:
> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we brainstormed
> to find a structure acceptable to everyone and ended up with:
>
> /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
> - cointype: This is zero for Bitcoin. This is here to support two
> things, one is supporting alt coins based off the same root seed. Right now
> nobody seemed very bothered about alt coins but sometimes feature requests
> do come in for this. Arguably there is no need and alt coins could just use
> the same keys as Bitcoin, but it may help avoid confusion if they don't.
>
> More usefully, cointype can distinguish between keys intended for
> things like multisig outputs, e.g. for watchdog services. This means if
> your wallet does not know about the extra protocol layers involved in this,
> it can still import the "raw" money and it will just ignore/not see the
> keys used in more complex transactions.
>
> - reserved is for "other stuff". I actually don't recall why we ended
> up with this. It may have been intended to split out multisig outputs etc
> from cointype. Marek, Thomas?
>
> - account is for keeping essentially wallets-within-a-wallet to avoid
> mixing of coins. If you want that.
>
> - change is 0 for receiving addresses, 1 for change addresses.
>
> - n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw v1
> so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet all
> the users needs, whilst still allowing some drift between what wallets
> support.
>
> Pieter made the I think valid point that you can't really encode how keys
> are meant to be used into just an HDW hierarchy and normally you'd need
> some metadata as well. However, I feel interop between wallets is more
> important than arriving at the most perfect possible arrangement, which
> feels a little like bikeshedding, so I'm happy to just go with the flow on
> this one.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/48a94563/attachment.html>

2023-06-07 17:15:35 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:It certainly is not subjective, in that people are far more used to dealing
with whole numbers than decimals. Try reading the first one, then reading
the second one. Tell those numbers to someone else, have them write it
down, and see how many people screw up the first vs. the second. This has
nothing to do with whether it "looks expensive". There are reasons for
wanting the numbers to be higher as well, as evidenced by the number of
Dogecoin enthusiasts who like "having more", even if it doesn't matter.
That part gets more subjective, but still favors micros in most cases.
Sure, 3000 may sound like a lot, but if you have a lot more, it's all a
different scale.
If the argument is for keeping things based on what is already done, why
even switch to millis? After all, everyone is used to full Bitcoins, why
even change to millis? Whatever your arguments are there, for switching
base bitcoins to millis, try to see why they fail at micros (other than the
subjective argument that I'm used to decimal units of currency being worth
a cup of coffee, even though numerous people all over the world don't have
that conditioning).
On Thu, Mar 13, 2014 at 12:13 PM, Mike Hearn <mike at plan99.net> wrote:
> Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
>> than 3123.45 uBTC.
>>
>
> This is subjective though. To me the first price looks like the price of a
> cup of coffee (or I just mentally double it). The second looks like the
> price of an expensive holiday.
>
> If users really find this so terrible, merchants have a simple solution:
> do the rounding before presenting the price. Then the price looks like
> "3.12 mBTC" which is sort of what I'd expect it to look like. But some
> wallets already make digits >2dp smaller so visually you can get precision
> whilst still looking similar to what you might expect (this is what Bitcoin
> Wallet does).
>
>
>> I haven't seen a single good argument for keeping it in mBTC (other than
>> some people already did it).
>>
>
> That's the good argument!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/447f16cf/attachment.html>

2023-06-07 17:15:34 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:Mike is making an assumption that is not necessary, which is the price of
the most commonly used unit should be between is $.50 and $1000. The issue
to revisit or not shouldn't require $1,000,000 Bitcoin price. Typing a ton
of decimals is incredibly annoying. Doing the mental math in my head is
annoying. Even if a cup of coffee costs 3.12345 mBTC, that's a lot more
annoying than 3123.45 uBTC.
The points that people liked mBTC better than BTC doesn't mean anything
when comparing uBTC to mBTC. Many people just stopped thinking at the mBTC
level, do not understand the implications involved in switching to uBTC, or
even considered uBTC. The idea that we can just poll what people want to
give them the ideal experience is also flawed, in that users often don't
know what they want until they have it in front of them.
There is basically no downside to uBTC, except a few places already
switched to mBTC. For exchanges, which are dealing with decimals since
they will do BTC/USD rather than the opposite, it might make sense for them
to continue to use mBTC or BTC. For wallets and prices for users,
especially when there are large decimals since the price is still based on
more stable currencies, then converted to Bitcoin, let's switch to what is
easiest.
I haven't seen a single good argument for keeping it in mBTC (other than
some people already did it). On the other hand, I've seen numerous great
reasons for switching to uBTC.
My two cents.
On Thu, Mar 13, 2014 at 11:39 AM, Melvin Carvalho
<melvincarvalho at gmail.com>wrote:
>
>
>
> On 13 March 2014 16:50, Mike Hearn <mike at plan99.net> wrote:
>
>> On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>>
>>> Such hand-wavy, data-free logic is precisely why community
>>> coordination is preferred to random apps making random decisions in
>>> this manner.
>>>
>>
>> That ship sailed months ago. If you wanted a big push for uBTC, then
>> would have been the time. Though given that it'd have made lots of normal
>> balances incredibly huge, perhaps it's a good thing that didn't happen.
>> Also "milli" is a unit people encounter in daily life whereas micro isn't.
>> Is it milli / micro / nano or milli / nano / micro? I bet a lot of people
>> would get that wrong.
>>
>> If you have to export to financial packages that can't handle fractional
>> pennies, then by all means represent prices in whatever units you like for
>> that purpose, but in software designed for ordinary people in everyday life
>> mBTC is a pretty good fit.
>>
>> Besides, fractional pennies crop up in existing currencies too (the
>> famous Verizon Math episode showed this), so if a financial package insists
>> on rounding to 2dp then I guess it may sometimes do the wrong thing in some
>> business cases already.
>>
>> Fundamentally, more than two decimal places tends to violate the
>>> Principle Of Least Astonishment with many humans, and as a result,
>>> popular software systems have been written with that assumption.
>>
>>
>> Lots of people use currencies that don't have any fractional components
>> at all ! So perhaps all prices should be denominated in satoshis to ensure
>> that they're not surprised :)
>>
>> The (number) line has to be drawn somewhere. Wallets are free to suppress
>> more than 2dp of precision and actually Andreas' app lets you choose your
>> preferred precision. So I think in the end it won't matter a whole lot, if
>> the defaults end up being wrong people can change them until wallet authors
>> catch up.
>>
>
> +1 agree with Mike on everything
>
> A couple of points:
>
> 1. bitcoinity already switched to mbtc aka millitbits (
> https://en.bitcoin.it/wiki/MilliBit ) and it was positively recieved,
> they got quite a few donations
>
> 2. If you watch Gavin's talk at the CFR he suggests the community comes to
> a consensus through implementations rather than top down decision making
> (If I understood correctly)
>
> I think it's up to wallet maintainers whether to switch the default.
>
>
>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/81bbaea1/attachment.html>

2023-06-07 17:15:30 CEST

- reply

📅 Original date posted:2014-03-14
📝 Original message:Fairly useless experiment, since the vast majority of users will almost
always stay at the default. The winner will always be whatever was
selected as the default initially. This might work if the default was
randomly chosen, and you see what actually annoyed users enough to switch
off of it most often.
On Fri, Mar 14, 2014 at 11:51 AM, Ricardo Filipe
<ricardojdfilipe at gmail.com>wrote:
> so much discussion for a visual update...
>
> make this a user experiment:
> -give the user the possibility to use BTC/mBTC/uMTC
> -retrieve the results after some time
> -make the default the most used option
>
>
> 2014-03-14 16:15 GMT+00:00 Alex Morcos <morcos at gmail.com>:
> > I think Mark makes some good arguments.
> > I realize this would only add to the confusion, but...
> > What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
> > whatever else), with a proper 3 letter code, and then from a user
> > standpoint, where people are using mBTC, they could switch to using Kbits
> > (ok thats obviously bad, but you get the idea) at the same nominal price.
> > But accounting backends and so forth would operate in the "bit" base unit
> > with 2 decimals of precision.
> >
> >
> >
> >
> > On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark at monetize.io>
> wrote:
> >>
> >> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
> >> numbers in both Chinas, Thailand, and other economically important East
> >> Asian countries. Expect to pay hundreds of rupees in India, or thousands
> >> of rupees in Indonesia.
> >>
> >> This concept that money should have low, single digits for everyday
> >> prices is not just Western-centric, it's English-centric. An expresso in
> >> Rome would have cost you a few (tens of?) thousand lira in recent
> >> memory. It was pegging of the Euro to the U.S. dollar that brought
> >> European states in line with the English-speaking world (who themselves
> >> trace lineage to the pound sterling).
> >>
> >> No, there is no culturally-neutral common standards for currency and
> >> pricing. But there are ill-advised, ill-informed "standards" in
> >> accounting software that we nevertheless must live with. These software
> >> packages do not handle more than two decimal places gracefully. That
> >> gives technical justifications for moving to either uBTC or accounting
> >> in Satoshis directly. An argument for uBTC is that it retains alignment
> >> with the existing kBTC/BTC/mBTC/uBTC conventions.
> >>
> >> However another limitation of these accounting software practices is
> >> that they do not always handle SI notation very well, particularly
> >> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
> >> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
> >> compliant with any software accounting package out there.
> >>
> >> We are still very, very early in the adoption period. These are changes
> >> that could be made now simply by a few big players and/or the bitcoin
> >> foundation changing their practice and their users following suit.
> >>
> >> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> >> > How much do you pay for an Espresso in your local currency?
> >> >
> >> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> >> > people would expect. Certainly more familiar than µBTC 3558 or BTC
> >> > 0.003578.
> >> >
> >> > Anyway, I was just sharing real-world experience: nobody is confused.
> >> >
> >> >
> >> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >> >> You give them a hard to interpret thing like mBTC and then wonder
> >> >> why they rather look at local currency. Because the choices you
> >> >> gave them are bad.
> >> >>
> >> >> I think Bitcoin would have a better chance to be percieved as a
> >> >> currency of its own if it had prices and fractions like currencies
> >> >> do.
> >> >>
> >> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >> >> would be.
> >> >>
> >> >>
> >> >> Tamas Blummer Bits of Proof
> >> >>
> >> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de>
> >> >> wrote:
> >> >>
> >> >>> btw. None of Bitcoin Wallet's users complained about confusion
> >> >>> because of the mBTC switch. In contrast, I get many mails and
> >> >>> questions if exchange rates happen to differ by >10%.
> >> >>>
> >> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >> >>> local currency that matters to the users.
> >> >>>
> >> >>>
> >> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >> >>>> µBTC.
> >> >>>>
> >> >>>> I must admit I was not aware if this thread. I just watched
> >> >>>> other wallets and at some point decided its time to switch to
> >> >>>> mBTC.
> >> >>>>
> >> >>>>
> >> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >> >>>>> The standard has become mBTC and that's what was adopted.
> >> >>>>> It's too late to try and sway this on a mailing list thread
> >> >>>>> now.
> >> >>>>>
> >> >>>>>
> >> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >> >>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>> wrote:
> >> >>>>>
> >> >>>>> The MultiBit HD view is that this is a locale-sensitive
> >> >>>>> presentation issue. As a result we offer a simple
> >> >>>>> configuration panel giving pretty much every possible
> >> >>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
> >> >>>>> mXBT, μXBT, sat along with settings for leading/trailing
> >> >>>>> symbol, commas, spaces and points. This allows anyone to
> >> >>>>> customise to meet their own needs beyond the offered default.
> >> >>>>>
> >> >>>>>
> >> >>>>> We apply the NIST guidelines for representation of SI unit
> >> >>>>> symbols (i.e no conversion to native language, no RTL giving
> >> >>>>> icon+m etc).
> >> >>>>>
> >> >>>>> Right now MultiBit HD is configured to use m+icon taken from
> >> >>>>> the Font Awesome icon set. However reading earlier posts it
> >> >>>>> seems that μ+icon is more sensible.
> >> >>>>>
> >> >>>>> Let us know what you'd like.
> >> >>>>>
> >> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >> >>>>> Awesome icon:
> >> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >> >>>>>
> >> >>>>>
> >> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
> >> >>>>> <mailto:jgarzik at bitpay.com>> wrote:
> >> >>>>>
> >> >>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
> >> >>>>> several weeks ago, which was disappointing -- it sounded like
> >> >>>>> the consensus was uBTC, and moving to uBTC later --which will
> >> >>>>> happen-- may result in additional user confusion, thanks to
> >> >>>>> yet another decimal place transition.
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
> >> >>>>> <mailto:w at grabhive.com>> wrote:
> >> >>>>>> We're with uBTC too. Been waiting for the signal to do
> >> >>>>>> this,
> >> >>>>> let's do it right after the fee system is improved.
> >> >>>>>>
> >> >>>>>> -wendell
> >> >>>>>>
> >> >>>>>> grabhive.com <http://grabhive.com> |
> >> >>>>>> twitter.com/hivewallet
> >> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >> >>>>>>
> >> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >> >>>>>>
> >> >>>>>>> Go straight to uBTC. Humans and existing computer
> >> >>>>>>> systems
> >> >>>>> handle numbers to
> >> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
> >> >>>>>>> The
> >> >>>>> opposite is
> >> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
> >> >>>>>>> places).
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> -- Jeff Garzik Bitcoin core developer and open source
> >> >>>>> evangelist BitPay, Inc. https://bitpay.com/
> >> >>>>>
> >> >>>>>
> >> >>>>>
> ------------------------------------------------------------------------------
> >> >>>>>
> >> >>>>>
> >> > Learn Graph Databases - Download FREE O'Reilly Book
> >> >>>>> "Graph Databases" is the definitive new guide to graph
> >> >>>>> databases and their applications. Written by three acclaimed
> >> >>>>> leaders in the field, this first edition is now available.
> >> >>>>> Download your free book today!
> >> >>>>> http://p.sf.net/sfu/13534_NeoTech
> >> >>>>> _______________________________________________
> >> >>>>> 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
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >> >>>>> Databases" is the definitive new guide to graph databases
> >> >>>>> and their applications. Written by three acclaimed leaders in
> >> >>>>> the field, this first edition is now available. Download your
> >> >>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
> >> >>>>> _______________________________________________
> >> >>>>> 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
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >> >>>>> Databases" is the definitive new guide to graph databases and
> >> >>>>> their applications. Written by three acclaimed leaders in the
> >> >>>>> field, this first edition is now available. Download your
> >> >>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> Bitcoin-development mailing list
> >> >>>>> Bitcoin-development at lists.sourceforge.net
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >> >>>> Databases" is the definitive new guide to graph databases and
> >> >>>> their applications. Written by three acclaimed leaders in the
> >> >>>> field, this first edition is now available. Download your free
> >> >>>> book today! http://p.sf.net/sfu/13534_NeoTech
> >> >>>> _______________________________________________
> >> >>>> Bitcoin-development mailing list
> >> >>>> Bitcoin-development at lists.sourceforge.net
> >> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >> >>> Databases" is the definitive new guide to graph databases and
> >> >>> their applications. Written by three acclaimed leaders in the
> >> >>> field, this first edition is now available. Download your free
> >> >>> book today! http://p.sf.net/sfu/13534_NeoTech
> >> >>> _______________________________________________
> >> >>> Bitcoin-development mailing list
> >> >>> Bitcoin-development at lists.sourceforge.net
> >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >>
> >> >>
> >> > Learn Graph Databases - Download FREE O'Reilly Book
> >> >> "Graph Databases" is the definitive new guide to graph databases
> >> >> and their applications. Written by three acclaimed leaders in the
> >> >> field, this first edition is now available. Download your free book
> >> >> today! http://p.sf.net/sfu/13534_NeoTech
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________ Bitcoin-development
> >> >> mailing list Bitcoin-development at lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Learn Graph Databases - Download FREE O'Reilly Book
> >> > "Graph Databases" is the definitive new guide to graph databases and
> >> > their
> >> > applications. Written by three acclaimed leaders in the field,
> >> > this first edition is now available. Download your free book today!
> >> > http://p.sf.net/sfu/13534_NeoTech
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development at lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Learn Graph Databases - Download FREE O'Reilly Book
> >> "Graph Databases" is the definitive new guide to graph databases and
> their
> >> applications. Written by three acclaimed leaders in the field,
> >> this first edition is now available. Download your free book today!
> >> http://p.sf.net/sfu/13534_NeoTech
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140314/32c3a2d7/attachment.html>

2023-06-07 17:13:26 CEST

- reply

📅 Original date posted:2014-02-19
📝 Original message:This is somewhat problematic in my use case since some parts need to be in
the chain earlier than others and have the same ID as expected.
https://bitcointalk.org/index.php?topic=260898.10
I haven't gone back to see if there are any ways around it, but the main
problem here is I need the Contract TX to be in the chain much earlier than
redeeming, but I need the refund transaction to be in the chain much
earlier. Perhaps there are some tricks to pull off to get it to work, but
I haven't been working on this for a while so I'm a bit rusty in that area.
This might be helpful enough to help a lot of use cases, but shouldn't be
final.
-Allen
On Wed, Feb 19, 2014 at 6:22 PM, Natanael <natanael.l at gmail.com> wrote:
> Regarding chains of transactions intended to be published at once
> together, wouldn't it be easier to add a "only-mine-with-child flag"?
>
> That way the parent transactions aren't actually valid unless spent
> together with the transaction that depends on it, and only the original
> will have a child referencing it.
>
> Then malleability is not an issue at all for transaction chains if you
> only need to broadcast your full transaction chain once, and don't need to
> extend it in two or more occasions, *after* broadcasting subchains to the
> network, from the same set of pregenerated transactions.
>
> If you need to broadcast pregenerated subchains separately, then you need
> the last child in the chain to be non-malleable.
>
> This would require all miners to start to respect it at once in order to
> avoid forking the network.
>
> - Sent from my phone
> Den 19 feb 2014 22:13 skrev "Pieter Wuille" <pieter.wuille at gmail.com>:
>
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at mac.com>
>> wrote:
>> > I think that we could guarantee fewer incidents by making version 1
>> transactions unmalleable and then optionally introduce a version 3 that
>> supported the malleability feature. That way most existing problematic
>> implementations would be fixed and no doors were closed for people
>> experimenting with other stuff - tx v 3 would probably then be called
>> experimental transactions.
>>
>> Just to be clear: this change is not directly intended to avoid
>> "incidents". It will take way too long to deploy this. Software should
>> deal with malleability. This is a longer-term solution intended to
>> provide non-malleability guarantees for clients that a) are upgraded
>> to use them b) willing to restrict their functionality. As there are
>> several intended use cases for malleable transactions (the sighash
>> flags pretty directly are a way to signify what malleabilities are
>> *wanted*), this is not about outlawing malleability.
>>
>> While we could right now make all these rules non-standard, and
>> schedule a soft fork in a year or so to make them illegal, it would
>> mean removing potential functionality that can only be re-enabled
>> through a hard fork. This is significantly harder, so we should think
>> about it very well in advance.
>>
>> About new transaction and block versions: this allows implementing and
>> automatically scheduling a softfork without waiting for wallets to
>> upgrade. The non-DER signature change was discussed for over two
>> years, and implemented almost a year ago, and we still notice wallets
>> that don't support it. We can't expect every wallet to be instantly
>> modified (what about hardware wallets like the Trezor, for example?
>> they may not just be able to be upgraded). Nor is it necessary: if
>> your software only spends confirmed change, and tracks all debits
>> correctly, there is no need.
>>
>> --
>> Pieter
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/42627c75/attachment.html>

2023-06-07 17:13:21 CEST

- reply

📅 Original date posted:2014-02-12
📝 Original message:While that solution does work for many use cases, it does make it much
harder to do anything needing chained transactions. Granted, this is the
short term solution for current implementations, but having a transaction
identifier that does not change does open up other use cases.
For example, Alice wants to send coins to a multisignature address with
Bob, such that both parties are required to spend the coins. Alice also
requires for Bob to send coins to this address as well before they will
proceed. Alice cannot guarantee that Bob will cooperate (and vice versa),
so before she broadcasts the transaction to send to A+B, she sends Bob a
transaction that spends her incoming transaction back to herself, but has a
time lock of far into the future. Bob signs this, returns it to Alice, and
she broadcasts her funding transaction. At this point, Bob disappears,
loses his key, or just decides to spite Alice and her coins are locked.
Since she has a refund transaction, she can broadcast it in a month and
get her coins back. Except her funding transaction has been modified such
that the txhash is different, so her refund is now invalid. She would need
Bob to issue a new refund as soon as her funding transaction hits the
blockchain if it is modified, which defeats the point of the trustless
refund transaction.
Longer term it would be more ideal have a canonical identifier for the
transaction before it even gets to the chain to support these use cases,
even if wallets are able to properly identify the status of it's
transactions. Obviously this is a difficult problem to solve and cannot be
implemented without breaking changes, but it would be a nice goal to be
able to completely remove malleability. There are other important use
cases where having a unique identifier just for internal accounting is
insufficient.
-Allen
On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> I think the solution is simply to encourage Bitcoin software developers to
> design their software to use this static ID, instead of the full
> transaction hash. If MtGox had talked those IDs instead of the TX ID,
> their software would've correctly identified the mutated transactions and
> there would be no problem.
>
> Armory is slightly different, since it doesn't deal with the same stuff as
> exchanges do. But it didn't have any problems with malleability because it
> doesn't track anything by ID, it only pays attention to whether inputs and
> outputs are related to your wallets. It's not necessarily hard to do it
> this way, people just have to be aware of it.
>
> -Alan
>
> Sent from my overpriced smartphone
> On Feb 12, 2014 10:15 AM, "Rune Kjær Svendsen" <runesvend at gmail.com>
> wrote:
>
>> Instead of trying to remove the possibility of transaction
>> malleability, would it make sense to define a new, "canonical
>> transaction hash/ID" (cTxID), which would be a hash of the part of the
>> transaction data which we know is not malleable, and have clients use
>> this cTxID internally, thus making the traditional transaction hash
>> irrelevant for a client to function correctly?
>>
>> We already have a non-malleable transaction hash: the hash that is
>> signed, ie. the transaction with each scriptSig replaced by the
>> scriptPubKey it redeems. This could be the cTxID.
>>
>> Or is this simply a too fundamental change to the way bitcoin-qt (and
>> all other clients) work in order to be feasible?
>>
>> As far as I can see, it completely solves the issue of not having a
>> canonical ID for a transaction, but it also increases the
>> computational requirements for a node. For one, as far as I can see,
>> it requires the node to index all transactions, because in order to
>> calculate a cTxID, it would be necessary to fetch all transactions
>> referred to by the transaction in question, in order to pull in the
>> scriptPubKeys that are redeemed.
>>
>>
>> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
>> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>> >> Hello all,
>> >>
>> >> it was something I planned to do since a long time, but with the
>> >> recent related issues popping up, I finally got around to writing a
>> >> BIP about how we can get rid of transaction malleability over time.
>> >>
>> >> The proposed document is here: https://gist.github.com/sipa/8907691
>> >>
>> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>> >> they require modifications to wallet software (Bitcoin Core 0.9 and
>> >> BitcoinJ already implement it, though) and potentially invalidate some
>> >> script functionality. However, these new rules remain optional and
>> >> controlled by an nVersion increase.
>> >>
>> >> Comments please!
>> >
>> > You should probably add making CHECKMULTISIG require the dummy value to
>> > be exactly equal to OP_FALSE; verifying that in the transaction itself
>> is
>> > laborious. A more subtle example is we may want both CHECKSIG and
>> > CHECKMULTISIG to fail the transaction if the signature is invalid but
>> > not exactly equal to OP_FALSE; some transaction forms are significantly
>> > more compact if you can have failed signatures, but that's a source of
>> > malleability. (are there counter examples people can think of?)
>> >
>> >
>> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
>> > malleability when we have no solid idea if ECC signatures are or are not
>> > malleable on a fundemental level; if "whack-a-mole" anti-malleability is
>> > all we've got it could be ugly if a break is found. Similarly, we may
>> > find we missed something, or some needed change makes the malleability
>> > rules difficult to work with for some new script type that is required.
>> >
>> > I'd rather see a new CHECKSIG mode for the case where malleability
>> > absolutely must be eliminated - certain multi-party protocols - and fix
>> > wallet software instead. (the malleability problems people see are
>> > closely related to inability to handle double-spends and reorgs) But I
>> > can easily see that being an impossible goal engineering wise...
>> >
>> > --
>> > 'peter'[:-1]@petertodd.org
>> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/af6a7c54/attachment.html>

2023-06-07 17:09:32 CEST

- reply

📅 Original date posted:2013-11-14
📝 Original message:I also would prefer to go straight to uBTC as the "standard wallet unit".
It works out perfectly with Satoshi's being the decimal units. Something
that costs $10USD would be 25000uBTC. This isn't a problem for a place
like South Korea, where 10USD is about 10,000 Won, so we aren't even off on
a scale of usable currencies in major economies.
The downsides are obviously confusion (causing mistakes resulting in lost
coins), and possibly from a psychological perspective on price (uBTC are
worthless!). On the other hand, it also might help people feel like they
are getting in on the ground floor still (I own 100,000 uBTC!), and reduce
the perception the Bitcoins are not divisible (I have heard several people
worry that 21 million is not enough units).
Alan's ideas for compatibility with multiple fields will also be helpful to
solving the confusion issue.
On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach <mark at monetize.io> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For this reason I'm in favor of skipping mBTC and moving straight to
> uBTC. Having eight, or even five decimal places is not intuitive to
> the average user. Two decimal places is becoming standard for new
> national currencies, and we wouldn't be too far from human scale
> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
> many people on this list would consider bitcoin overvalued in the long
> term perspective.
>
> Better to go through a confusing renumbering only once.
>
> Mark
>
> On 11/14/13 12:01 PM, Alan Reiner wrote:
> > ... I'm also of the opinion that it's freakin' hard to change the
> > base unit in such an established system. There is no easy way to
> > do this that doesn't cause more heartache than it's worth...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20
> hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR
> HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89
> 4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i
> ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU
> 4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci
> g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8
> SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8
> fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw
> tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA
> XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz
> ccP053+6o5Rgpc7J1aa0
> =QW1i
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/c60e096d/attachment.html>

2023-06-07 17:08:29 CEST

- reply

📅 Original date posted:2013-11-02
📝 Original message:Required vs. strongly recommended is an important distinction. Satoshi
Dice reuses EC Keys for every single transaction. Exchanges will have the
same address you deposit in over and over, which gets reused. This is a
best practice argument rather than a protocol requirement.
On Sat, Nov 2, 2013 at 8:27 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
> > I actually had a use case in my case where it was possible, and that was
> > the check I used to get around it, just configured it so that I always
> > generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
> > It was either that or making sure I had no unspent outputs. The use
> case
> > of doing it was laziness in just creating a single key.
>
> Use cases mean an actual use, not mere laziness. Bitcoin as a system has
> always required a unique EC key (and address) for each transaction.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131102/7cd74af0/attachment.html>

2023-06-07 17:08:29 CEST

- reply

📅 Original date posted:2013-11-02
📝 Original message:I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
It was either that or making sure I had no unspent outputs. The use case
of doing it was laziness in just creating a single key.
On Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> > This was one of my concerns when implementing a scheme where you sign a
> > refund transaction before the original transaction is broadcast. I
> > originally tried to pass a hash and have the server sign it. However, I
> > had no way to know that what I was signing wasn't a transaction that was
> > spending my coins! So I changed the code to require sending the full
> > transaction, not just the hash. The other way to mitigate this is
> through
> > not having any unspent outputs from this key.
>
> Well, there's no use case to sign with an address that has already been
> sent
> coins. The main problem with enforcing this is that you can't exactly stop
> someone from sending to an "identity" address.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131102/8c7dc481/attachment.html>