Allen Piscitello [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-10-23 to 2016-05-12
💬 Posted a total of 34 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP proposal, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:50:33

- 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 17:46:59

- 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 15:39:57

- reply

📅 Original date posted:2015-06-24
📝 Original message:This is no different than any other soft fork. Proper communication can
coordinate soft forks easily.
On Wed, Jun 24, 2015 at 12:23 PM, Raystonn <raystonn at hotmail.com> wrote:
> You really believe they would risk getting orphaned by skipping the longer
> chain, just to attempt to reduce average block size? No, that doesn't
> happen today. Laziness in leaving the default size is common. But that is
> not collusion, nor an attempt to manipulate the block sizes of other miners.
> On 24 Jun 2015 10:05 am, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> They do so by not building on larger blocks
> On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn at hotmail.com> wrote:
>
> No, they can lower their own block sizes. But they cannot currently lower
> the sizes of blocks mined by others. That is not the same thing by any
> stretch of the imagination.
> On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik at gmail.com> wrote:
>
> Miners can collude today to lower the block size limit.
>
> In fact, this largely happens already out of laziness - miners often
> follow the "soft" default limit set by Bitcoin Core, to the point where you
> can chart when miners upgrade to new software:
> http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
>
>
>
> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden at novauri.com>
> wrote:
>
> Here are refutations of the approach in BIP-100 here:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> To recap BIP-100:
>
> 1) Hard form to remove static 1MB block size limit
> 2) Add new floating block size limit set to 1MB
> 3) Historical 32MB message limit remains
> 4) Hard form on testnet 9/1/2015
> 5) Hard form on main 1/11/2016
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> threshold by 90% of blocks
> 7) Limit increase or decrease may not exceed 2x in any one step
> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> scriptSig, e.g. "/BV8000000/" to vote for 8M.
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> most common floor (minimum) is chosen.
>
> 8MB limits doubling just under every 2 years makes a static value grow
> in a predictable manner.
>
> BIP-100 makes a static value grow (or more importantly potentially
> shrink) in an unpredictable manner based on voting mechanics that are
> untested in this capacity in the bitcoin network. Introducing a highly
> variable and untested dynamic into an already complex system is
> unnecessarily risky.
>
> For example, the largely arbitrary voting rules listed in 9 above can be
> gamed. If I control pools or have affiliates involved in pools that
> mine slightly more than 20% of blocks, I could wait until block sizes
> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> "/BV5000001/" for the remaining 10%. If others don't consistently vote
> for the same "/BV#/" value, vote too consistently and have their value
> thrown out as the top 20%, I could win the resize to half capacity
> "/BV5000001/" because it was the lowest repeated value not in the bottom
> 20%.
>
> I could use this to force an exodus to my sidechain/alt coin, or to
> choke out the bitcoin network. A first improvement would be to only let
> BIP-100 raise the cap and not lower it, but if I can think of a
> vulnerability off the top of my head, there will be others on the other
> side of the equation that have not been thought of. Why bother
> introducing a rube goldberg machine like voting when a simple 8mb cap
> with predictable growth gets the job done, potentially permanently?
>
>
> On 6/23/2015 9:43 PM, odinn wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 1) Hard fork not (necessarily) needed
> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > your stuff," but rather simply to say, "Better you should work with
> > Garzik to implement BIP-100, that would be good")
> > 3) See points 1 and 2 above
> > 4) If still reading... changes should be (as you seem to have been
> > trying to lean towards)... lean towards gradual change; hence, changes
> > that would flow from this BIP would be better off oriented in a
> > process that dies not require the "way you have done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
> > However, in reading that, I didn't see any meaningful statements that
> > would refute the approach in Garzik's BIP-100.
> >
> > Maybe a better way to say this is,
> >
> > Work with Jeff Garzik (which I am sure you are already having such
> > discussions in private) as well as the list discussions,
> > Move forward on BIP-100 with Garzik and other developers (not such a
> > bad plan really) and don't get caught up in XT. (If you feel you can
> > develop XT further, that is your thing but it would perhaps make you
> > lose focus, work together with other developers.)
> >
> > Relax into the process. Things will be ok.
> >
> > Respectfully,
> >
> > - -O
> >
> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> >> I promised to write a BIP after I'd implemented
> >> increase-the-maximum-block-size code, so here it is. It also lives
> >> at:
> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> >>
> >> I don't expect any proposal to please everybody; there are
> >> unavoidable tradeoffs to increasing the maximum block size. I
> >> prioritize implementation simplicity -- it is hard to write
> >> consensus-critical code, so simpler is better.
> >>
> >>
> >>
> >>
> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> >> <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>> Status:
> >> Draft Type: Standards Track Created: 2015-06-22
> >>
> >> ==Abstract==
> >>
> >> This BIP proposes replacing the fixed one megabyte maximum block
> >> size with a maximum size that grows over time at a predictable
> >> rate.
> >>
> >> ==Motivation==
> >>
> >> Transaction volume on the Bitcoin network has been growing, and
> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> >> the one megabyte maximum block size. Increasing the maximum size
> >> reduces the impact of that limit on Bitcoin adoption and growth.
> >>
> >> ==Specification==
> >>
> >> After deployment on the network (see the Deployment section for
> >> details), the maximum allowed size of a block on the main network
> >> shall be calculated based on the timestamp in the block header.
> >>
> >> The maximum size shall be 8,000,000 bytes at a timestamp of
> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> >> every 63,072,000 seconds (two years, ignoring leap years), until
> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> >> blocks in between doublings will increase linearly based on the
> >> block's timestamp. The maximum size of blocks after 2036-01-06
> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> >>
> >> Expressed in pseudo-code, using integer math:
> >>
> >> function max_block_size(block_timestamp):
> >>
> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> >> 8000000 if block_timestamp >= time_start+time_double*10 return
> >> size_start * 2^10
> >>
> >> // Piecewise-linear-between-doublings growth: time_delta =
> >> block_timestamp - t_start doublings = time_delta / time_double
> >> remainder = time_delta % time_double interpolate = (size_start *
> >> 2^doublings * remainder) / time_double max_size = size_start *
> >> 2^doublings + interpolate
> >>
> >> return max_size
> >>
> >> ==Deployment==
> >>
> >> Deployment shall be controlled by hash-power supermajority vote
> >> (similar to the technique used in BIP34), but the earliest possible
> >> activation time is 2016-01-11 00:00:00 UTC.
> >>
> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> >> best chain have a version number with bits 3 and 14 set (0x20000004
> >> in hex). The activation time will be the timestamp of the 750'th
> >> block plus a two week (1,209,600 second) grace period to give any
> >> remaining miners or services time to upgrade to support larger
> >> blocks. If a supermajority is achieved more than two weeks before
> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> >> 00:00:00 UTC.
> >>
> >> Block version numbers are used only for activation; once activation
> >> is achieved, the maximum block size shall be as described in the
> >> specification section, regardless of the version number of the
> >> block.
> >>
> >>
> >> ==Rationale==
> >>
> >> The initial size of 8,000,000 bytes was chosen after testing the
> >> current reference implementation code with larger block sizes and
> >> receiving feedback from miners stuck behind bandwidth-constrained
> >> networks (in particular, Chinese miners behind the Great Firewall
> >> of China).
> >>
> >> The doubling interval was chosen based on long-term growth trends
> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> >> was chosen because exponential growth cannot continue forever.
> >>
> >> Calculations are based on timestamps and not blockchain height
> >> because a timestamp is part of every block's header. This allows
> >> implementations to know a block's maximum size after they have
> >> downloaded it's header, but before downloading any transactions.
> >>
> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> >> block size increase, and is designed to give miners, merchants,
> >> and full-node-running-end-users sufficient time to upgrade to
> >> software that supports bigger blocks. A 75% supermajority was
> >> chosen so that one large mining pool does not have effective veto
> >> power over a blocksize increase. The version number scheme is
> >> designed to be compatible with Pieter's Wuille's proposed "Version
> >> bits" BIP.
> >>
> >> TODO: summarize objections/arguments from
> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> >>
> >> TODO: describe other proposals and their advantages/disadvantages
> >> over this proposal.
> >>
> >>
> >> ==Compatibility==
> >>
> >> This is a hard-forking change to the Bitcoin protocol; anybody
> >> running code that fully validates blocks must upgrade before the
> >> activation time or they will risk rejecting a chain containing
> >> larger-than-one-megabyte blocks.
> >>
> >> Simplified Payment Verification software is not affected, unless
> >> it makes assumptions about the maximum depth of a transaction's
> >> merkle branch based on the minimum size of a transaction and the
> >> maximum block size.
> >>
> >> ==Implementation==
> >>
> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev mailing
> >> list bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > - --
> > http://abis.io ~
> > "a protocol concept to enable decentralization
> > and expansion of a giving economy, and a new social good"
> > https://keybase.io/odinn
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > =ft62
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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/20150624/cb6e3180/attachment-0001.html>

2023-06-07 15:30:18

- 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 15:16:18

- reply

📅 Original date posted:2014-03-27
📝 Original message:The idea was to use the magic number as the source for cointype. If it's
too big, as Tamas showed, perhaps a hash of it, and for coins without a
magic number, a hash of their name (or some unique identifier).
That being said, I agree with Andreas that something that is 90%
inter-operable seems very dangerous and will give people false expectations
when they miss the corner cases. If the structure isn't going to be shared
completely and have all support shared, having it completely incompatible
along with a mechanism for converting part of it to another wallet seems
superior. The worst types of losses will occur when someone tests out
something with a limited use case, sees that it appears to work, makes
dangerous assumptions, then gets burned when it's too late.
-Allen
On Thu, Mar 27, 2014 at 11:06 AM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/27/2014 04:57 PM, Allen Piscitello wrote:
> > 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?
>
> That magic number is something I find very unfortunate and superflous in
> BIP-32 design. Its only purpose is to distinguish BIP-32 trees for
> various altcoins, but it doesn't make sense at all once you start
> storing various altcoins in the same tree using the proposed
> /m/cointype/reserved'/account'/change/n scheme.
>
> I would love to see that removed from BIP-32 and use always
> 0x0488B21E/0x0488ADE4 (xpub/xpriv), but that is for different discussion
> I guess.
>
> --
> Best Regards / S pozdravom,
>
> Pavol Rusnak <stick at gk2.sk>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/e7aa5555/attachment.html>

2023-06-07 15:16:18

- 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 15:16:15

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

- 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 15:13:26

- 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 15:13:21

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

- reply

📅 Original date posted:2013-11-14
📝 Original message:Obviously the answer is to just display all fees and trading rates as BTC
or MBTC (.0000005 MBTC fee? how cheap!). On a more serious note, the
transition should definitely be thought out well as it could be very
damaging to have this confusion, but I would prefer to do it only once
rather than twice.
On Thu, Nov 14, 2013 at 4:00 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> Just keep in mind it will be a little awkward that 54.3 uBTC is the
> smallest unit that can be transferred [easily] and the standard fees are
> 500 uBTC. It's not a deal breaker, it's just something that needs to be
> taken into consideration when it comes to user perception (which is one of
> the reasons we would make such a change in the first place).
>
> "Holy crap these fees are huge! I thought Bitcoin didn't have fees!"
>
>
>
> On 11/14/2013 04:55 PM, Allen Piscitello wrote:
> > 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
> <mailto:mark at monetize.io> <mark at monetize.io>> wrote:
> >
>
> 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...
>
> >
>
> >
> ------------------------------------------------------------------------------
> > 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
> <mailto:Bitcoin-development at lists.sourceforge.net><Bitcoin-development at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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/cfa37763/attachment.html>